Large OS Disk Encryption is now generally available for Azure Confidential VM migrations
Today, we are excited to announce the General Availability of Large OS Disk Encryption (LOSDE) for Azure Confidential VM migration scenarios. This capability removes a key adoption barrier for customers migrating sensitive workloads to Azure Confidential Virtual Machines by enabling encryption for operating system disks larger than 127 GB. With LOSDE, organizations can securely migrate larger, more complex workloads to Azure to enable the confidentiality protections provided by Azure Confidential Computing. Why this matters For many enterprises, migrating existing workloads to the cloud is not simply a matter of redeployment. Business-critical applications often rely on large operating system disks and established operational configurations that must be preserved during migration. Until now, customers migrating workloads with operating system disks larger than 127 GB faced limitations when attempting to bring those workloads into Azure Confidential VMs while preserving confidential computing guarantees. This created an adoption challenge for organizations operating highly regulated or security-sensitive environments. Large OS Disk Encryption addresses this gap by extending encryption support to larger operating system disks during migration workflows. With LOSDE, customers can: Enable upgrading virtual machines to Azure Confidential VMs through the migration process. Migrate workloads with OS disks larger than 127 GB to Azure Confidential VMs. Continue to use customer-managed keys (CMKs) aligned with their security and compliance requirements. Support migration scenarios for Windows, Ubuntu, Red Hat Enterprise Linux, and Rocky Linux. Check the Azure Migrate documentation for the support list. Accelerate adoption of Azure Confidential Computing for existing enterprise environments. Simplifying secure migration to Azure Confidential VMs The Large OS Disk Encryption feature integrates seamlessly into Azure migration workflows, enabling customers to move existing workloads into Azure Confidential VMs while continuing to benefit from hardware-backed protections and the trusted execution environment capabilities of Azure Confidential Computing. LOSDE helps close that gap by enabling customers to bring existing workloads into Azure Confidential Computing environments while preserving the confidentiality guarantees required for regulated, critical, and sensitive applications. The solution offers automation with Azure Migrate , enabling Windows, Ubuntu, RHEL, and Rocky Linux workloads to be encrypted while preserving the confidentiality guarantees of Azure Confidential Computing and supporting customer-managed keys (CMKs). The result is a simpler path to cloud modernization, stronger protection for data in use, and expanded adoption opportunities for Azure Confidential Virtual Machines . This work reflects Microsoft's ongoing commitment to making advanced security capabilities easier to adopt without increasing operational complexity.Strengthening Semiconductor Supply Chain Trust with Microsoft’s Artifact Signing and Transparency
As enterprises expand their use of Confidential Computing in the cloud and in AI infrastructure, the security of the underlying hardware is more critical than ever. Organizations and their customers need confidence not only in the software they deploy, but also in the silicon and firmware executing their most sensitive workloads. AMD and Microsoft are collaborating to demonstrate how signing and transparency can strengthen trust in the semiconductor supply chain. By combining AMD Device Provenance with Microsoft’s Artifact Signing and Signing Transparency, we are exploring how device provenance, signing, and transparency could work together to support independently verifiable hardware evidence. Why Hardware Provenance Needs Transparency Provenance evidence is most useful when it can be independently verified and evaluated alongside related supply chain evidence. Semiconductor manufacturers generate evidence across selected manufacturing and lifecycle stages, which may describe relevant device attributes, manufacturing events, and validation activities. A digitally signed record establishes who issued information and its integrity. Individual signatures alone do not provide a durable and independently verifiable record of the order in which they were issued, whether they were recorded consistently, or whether unexpected activity occurred in the interval. Transparency addresses this gap. Microsoft's Signing Transparency leverages confidential computing to create a verified, tamper-evident record of signing events, allowing customers and auditors to confirm that evidence was recorded and has not been silently changed or been removed. It applies the Zero Trust principle of “trust but Verify” by giving relying parties cryptographic proof they can evaluate directly. Extending Transparency from Software to Silicon Microsoft's Signing Transparency was designed to address software supply chain threats that traditional code signing alone cannot fully prevent. The same principles can be applied to firmware, hardware provenance, and other evidence generated across the physical supply chain. AMD Device Provenance is designed to provide visibility into the manufacturing and lifecycle of data center components. Through our collaboration, AMD and Microsoft are demonstrating how this evidence can be signed, made transparent, and independently validated. This approach provides several important benefits: Transparent provenance: Changes to signed hardware evidence can be detected rather than silently accepted. Independent validation: Customers can independently validate the integrity, signing history, and transparency records associated with provenance evidence while still applying their own trust requirements to the evidence issuer. Stronger accountability: Transparency creates a durable record of signing events, providing evidence that can help identify unexpected patterns or unauthorized signatures. Audit and compliance evidence: Verifiable records may help inform supplier assessments, regulatory inquiries, and internal due diligence. Standards-based portability: Evidence can be validated across organizational boundaries using interoperable IETF specifications, including RFC 9943, An Architecture for Trustworthy and Transparent Digital Supply Chains, RFC 9942, CBOR Object Signing and Encryption Receipts, and RFC 9995, CBOR Object Signing and Encryption Hash Envelope, rather than proprietary trust mechanisms. Together, these capabilities allow relying parties to verify the origin, integrity, registration, and device binding of manufacturer-issued provenance evidence. Learn More at OCP Global Summit At OCP Global Summit 2026, AMD and Microsoft will present a proof-of-concept demonstration that prototypes how these components could operate together. Visit the AMD (#C61) booth to see the demonstration and learn how AMD and Microsoft are advancing semiconductor supply chain security. To dive deeper into the demo details read AMD’s blog Advancing Semiconductor Supply Chain Assurance. Organizations interested in applying Artifact Signing and Signing Transparency to software, firmware, or hardware can also join the Artifact Signing with Signing Transparency preview community to learn more and help shape the future of the service.
One SOC, Many Tenants: Centralizing Microsoft Sentinel with Azure Lighthouse
Most large organizations don’t live in a single Microsoft Entra ID tenant. Acquisitions, regulatory separation, sovereignty mandates, and mission boundaries all multiply tenants over time. For a security operations team, that sprawl creates one hard question: how do you run a single security operations center (SOC) with one pane of glass, without copying every tenant’s logs into a central bucket and inheriting the compliance risk that comes with it? Azure Lighthouse provides delegated resource management for this scenario. It lets authorized operators in a central hub tenant work with scoped resources in spoke tenants from their own tenant. Paired with Microsoft Sentinel, it supports cross-tenant visibility while source logs remain stored in each spoke workspace. Group-based RBAC and Privileged Identity Management (PIM) can help govern privileged access. This practical blueprint applies least privilege to that pattern: one Sentinel deployment in the hub, delegated read access to the Log Analytics workspaces in each spoke, and RBAC and PIM controls that support auditability. The delegation is scoped to the workspaces the SOC needs. Before you begin: prerequisites Gather the identifiers and identity groups below before you touch any tenant. The consistency you establish here is what makes the per-spoke procedure repeatable across an entire estate. Collect tenant and workspace identifiers Hub CSOC tenant ID and hub Sentinel workspace resource ID. For each spoke: tenant ID, subscription ID, workspace resource group, and workspace resource ID. Create hub security groups in Microsoft Entra ID SOC-Readers, the required core query-access group. SOC-Responders, an optional group for response-specific actions. SOC-Admins, an optional and tightly controlled group. Define the minimum RBAC baseline Assign Log Analytics Reader to SOC-Readers at the spoke workspace or resource-group scope. Add elevated roles only when a documented use case requires them. Register the required resource providers Lighthouse and Sentinel both depend on resource providers being registered before delegation will work. In every spoke subscription, register Microsoft.ManagedServices so the delegation can be created. And because Sentinel lives only in the hub, register Microsoft.SecurityInsights and Microsoft.OperationalInsights on at least one subscription in the hub tenant. That last step is easy to overlook, and skipping it quietly blocks cross-tenant operations. What you’ll find here The architecture, and why data residency makes hub-and-spoke the right call. Prerequisites, including the resource providers teams most often forget to register. A repeatable, per-spoke delegation procedure. Validation queries that prove the access path actually works. A complete RBAC assignment matrix and PIM activation policy. Troubleshooting for the errors you’ll actually hit. Why hub-and-spoke for a cross-tenant SOC In this model, Microsoft Sentinel is deployed once, in the hub (CSOC) tenant. Each spoke tenant keeps its own Log Analytics workspace, where its logs are collected and retained. Azure Lighthouse connects the two: the spoke delegates scoped access to the hub, and authorized hub analysts query spoke workspaces from their own tenant. The source logs remain stored in the spoke workspace, while query results are returned across tenant boundaries to authorized users and services. Figure 1. The hub runs Sentinel and queries each spoke’s Log Analytics workspace through a scoped Azure Lighthouse delegation; logs never leave the spoke tenant. That separation is the entire point, and it lines up with the advantages Microsoft calls out for centralized cross-tenant management: Workspace ownership and source-log storage remain with each spoke tenant. Source telemetry remains stored in the configured spoke workspace and region, subject to the service configuration and authorized query access. Separate workspaces help maintain tenant isolation between spokes. Cross-tenant detection and hunting can query spoke workspaces without centralizing the underlying source logs; authorized query results are returned across tenant boundaries. Ingestion and retention costs are billed to the tenant that generates the data, not to the hub. What this runbook delivers The objective is a centralized CSOC with scoped, governed access across spoke tenants from a single Sentinel instance. Hub SOC teams query spoke Log Analytics workspaces through delegation, run cross-tenant analytics, and create and manage incidents centrally, while spoke logs stay in spoke workspaces and tenant isolation is preserved. Just as important is how that access is granted. The target state is least-privilege by construction: RBAC assignments carry only the permissions the SOC needs, privileged roles are PIM-governed rather than standing, and every delegation is scoped to the specific resources in play. When the build is complete, the operating model is both active and auditable. Configuring the delegation (per spoke tenant) Repeat the three steps below for each spoke. For fleets larger than a handful of tenants, capture the same authorization in an Azure Lighthouse ARM template and deploy it per spoke, so the scope and role assignments stay identical across the estate. Step 1: Register the provider in the spoke subscription Register Microsoft.ManagedServices in the spoke subscription. Confirm the provider registration state is Registered before continuing. Step 2: Create the Lighthouse delegation from spoke to hub Open Azure Lighthouse in the spoke tenant. Create a delegation, or offer, and set the managing tenant to the hub CSOC tenant ID. Add an authorization with the principal set to the hub SOC-Readers group and the role set to Log Analytics Reader. Set the scope to the workspace resource group (preferred) or to the individual workspace. Prefer group-based assignments and avoid direct user assignments. Step 3: Repeat across all spoke tenants Apply the same pattern and naming convention every time. Document any scope or role exceptions for security review. Validating the delegation Three checks confirm the delegation is wired correctly: visibility, query access, and incident generation. Run them in order, because each one depends on the check before it. Figure 2. The three validation checks run in sequence — visibility, then cross-tenant query, then incident generation — each building on the one before. Confirm delegated visibility From the hub context, verify that each spoke appears under Azure Lighthouse delegated resources. Confirm that the expected principals and scopes are listed. Run a cross-tenant query from hub Sentinel Run a simple take query to verify that the access path resolves. Run a data query against a known active table to confirm you can see ingestion. Confirm the access path resolves: workspace("/subscriptions/<spoke-sub-id>/resourceGroups/<spoke-rg>/providers/Microsoft.OperationalInsights/workspaces/<spoke-ws>") | take 1 Check that a known table is receiving data: workspace("/subscriptions/<spoke-sub-id>/resourceGroups/<spoke-rg>/providers/Microsoft.OperationalInsights/workspaces/<spoke-ws>").Heartbeat | where TimeGenerated > ago(24h) | summarize Events = count() Verify incident generation in hub Sentinel Create a temporary scheduled analytics rule that uses cross-tenant query logic. Trigger the test condition and confirm that the incident is created in the hub. Standardizing new-spoke onboarding Turn the procedure into a checklist so every new spoke is onboarded the same way and nothing slips. Resource provider registered. Delegation deployed with the hub as managing tenant. Roles assigned to hub SOC groups. Cross-tenant query test passed. Hub incident-generation test passed. Access-review owner assigned. Security and governance Delegation connects the hub to scoped spoke resources; governance helps control that access. Three controls do most of the work. Enforce privileged identity controls Make privileged groups PIM-eligible rather than permanently assigned. Require MFA, approval, justification, and time-bound activation. Maintain separation of duties Keep SOC monitoring, content engineering, and platform administration in separate roles. Review delegated access on a recurring governance cadence. Manage exceptions with formal controls Document every elevated-access and broad-scope delegation exception. Require security-architecture approval for any non-standard scope. Role and RBAC assignment matrix The tables below translate those principles into concrete assignments: first the hub-local roles, then the delegated spoke roles, and finally the PIM activation policy that governs both. Hub (CSOC) tenant: local assignments Spoke (service) tenant: delegated via Azure Lighthouse PIM activation requirements Key design rules Minimum privilege governs spoke delegation. Log Analytics Reader covers every cross-tenant detection and query operation, so Owner and broad Contributor at subscription scope have no place in a SOC delegation. Sentinel Responder in a spoke is rarely needed. It matters only when analysts must acknowledge, close, or act on spoke-level resources directly, and in a hub-only Sentinel model spoke incidents don’t exist, so the role usually isn’t required. Separation of duties is strict. Content engineers don’t get responder rights, responders don’t get content-deployment rights, and platform admins sit apart from both monitoring and detection engineering. Routine privileged roles are eligible and time-bound. SOC responders, hunters, content engineers, and platform admins use PIM rather than permanent assignment. Emergency-access accounts are the exception and should follow Microsoft Entra emergency-access guidance, including monitoring and regular validation. Troubleshooting common issues Most problems fall into three buckets, and each has a short diagnostic path. Design notes and what’s next By default, Sentinel stays enabled in the hub only, unless a spoke-specific requirement is approved. Spoke tenants remain data-source focused and don’t generate local Sentinel incidents; detection, incident management, and automation all live in hub Sentinel, giving you one place to build content and one place to respond. A centralized SOC does not require centralizing every source workspace. With scoped Azure Lighthouse delegation and PIM-governed access, a CSOC can query a multitenant estate while source logs remain stored in their spoke workspaces. Further reading Manage Microsoft Sentinel workspaces at scale (Azure Lighthouse) Manage multiple tenants in Microsoft Sentinel as an MSSP Extend Microsoft Sentinel across workspaces and tenantsUnderstanding Microsoft 365 Copilot Risk Surface and Mitigations
Microsoft 365 Copilot acts on the access users already have. It does not grant new permissions — it is a force multiplier that makes existing access faster and easier to discover, aggregate, and act on across Microsoft 365. That speed and accessibility can also amplify existing security and governance gaps. In environments with overshared content, excessive permissions, or inconsistent governance, users may gain faster access to sensitive information than organizations realize. It’s a shift that carries important security implications organizations should understand before scaling deployment. Customers with Microsoft 365 E5 licensing may already have access to many of the tools that can help identify and reduce Copilot-related risk, but licensing alone does not reduce exposure. What’s often missing during early Copilot deployments is a clear understanding of the risk surface itself: what data is exposed, who can access it, and through which vectors.Microsoft Entra Suite hands-on tour of identity and network access protections
Enforce least privilege access across every app and resource. Wire lifecycle workflows directly to your HR system to strip stale permissions on role changes, gate sensitive data behind biometric step-up verification, and replace your VPN with per-app, identity-scoped access that revokes tokens the moment risk spikes. Secure AI usage at every layer. Block confidential data from reaching public AI tools and stop adversarial prompt injections before your agents process them. John Damon, Microsoft Entra Suite Senior Product Manager, shares how to lock down identity, network access, and AI usage from a single control plane. Zero stale permissions after a role change. Entra Suite lifecycle workflows auto-assign the right access package and remove old entitlements. Check it out. Cut legacy VPN. Global Secure Access in Entra Suite scopes access per app, ties it to identity, and exposes no inbound ports or public IPs. See how it works. Expose adversarial instructions hidden in plain text. Prompt Injection Protection in Entra Suite matches the injection class and blocks the prompt before the model processes it. Check it out. QUICK LINKS: 00:00 — Identity and network controls 00:45 — Lifecycle Workflows 01:28 — Verified ID with Face Check 02:15 — Request access for direct reports 03:17 — Global Secure Access + Token Revocation 04:32 — Secure AI usage 06:20 — Network DLP / ChatGPT Block 07:12 — Prompt Injection Protection 08:31 — Wrap up Link References Check out our related deep dives at https://aka.ms/EntraSuitePlaylist For more information, go to https://aka.ms/EntraSuite Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -With AI, where action happens at machine speed and where access can be granted and inherited instantly, identity and network access has never been more important. Securing AI starts with securing people, and for that, your identity and network controls need to come together to close gaps that attackers can exploit, and that’s where Microsoft Entra Suite comes in. It combines best-in-class capabilities into a single solution to help you enforce least-privilege access to make sure users have access to what they need, and only as long as necessary. Apply unified access controls to any app and resource, and secure access to AI by discovering AI apps and agents, assessing risk, and enforcing policy. -Let’s bring this to life by following a user, Violet Martinez, throughout her day, I’ll start by showing how she gets access to exactly what she needs, with least-privilege access. In this scenario, our user has changed job roles. Her role change was signaled overnight by an HR system, Workday, and her permissions need to be adjusted for her new position in the IoT department. This is where a lifecycle workflow we set up in advance in Entra Suite comes into play. We’ve created a “Mover” workflow that automatically adjusts access when a user role changes, and I can click to see how it’s defined. Importantly, stale entitlements from her previous role are automatically removed, and a new access package bundling the right apps and permissions for her new IoT product marketing role is automatically assigned. -Now let’s switch to showing you our user Violet’s experience. When she signs in with a passkey for her new role, every app and permission from the baseline package is already set up, and she can request access to specific resources that she might be missing using the My Access page at myaccess.microsoft.com. For example, in order to start her work in competitive analysis, she needs access to Zava’s on-prem IoT Pricing Dashboard. So she makes the request. Because the package grants access to highly confidential on-prem pricing data, the workflow requires Verified ID step-up with Face Check. This requires Microsoft Authenticator, which prompts for Face Check, a verification process to match her real-time selfie to her government-issued ID on file, and once verified, she’s given access to the dashboard. -Now, as a manager, you can request access for your direct reports to make it easier for users to onboard with the access they need. In fact, let me show you the perspective from Violet’s manager. In the same My Access page, I can see the Pricing Dashboard access package we just saw, along with another access package that I can assign to my team. In this case, I want to extend the access to the Zava Assistant AI agent used by the team, and can initiate an access package request for the agent on Violet’s behalf. -From the dropdown, I see the directs on my team, I’ll choose Violet. Now I’ll choose a start date followed by an end date, and along with those, I’ll type in the business justification, which was set up by IT as mandatory properties for this access package. And because in this instance, as the manager, I am both the requester and approver, Entra ID Governance both provisions and grants just-in-time and time-bound access. Least-privilege access is enforced automatically, with stale permissions removed and updated baselines assigned, and sensitive access controlled using step-up verification. -From here, let’s move on to applying real-time context-aware access controls to apps and resources as our user goes about her day. She starts in the Edge browser and navigates to local IP to open on-prem Pricing Dashboard. We can see that she has the Global Secure Access client installed, so she doesn’t need to use a VPN. To access internal resources, our IT policy requires her to sign in using her work account with passkey, which uses Conditional Access to evaluate her risk and session context before allowing access to on-prem Pricing Dashboard. Importantly, Global Secure Access permissions are granted per app and scoped to identity, with no inbound firewall ports and no public IPs exposed. And by the way, Global Secure Access will also work with other on-prem apps and Active Directory that do not natively support modern authentication. -The good news is, even if her device is compromised because of a hardware-based token theft and a token replay attack, with dynamic policies in place, once the user risk is flagged as elevated, token access can be automatically revoked. This forces self-remediation for any user account with elevated risk. That way, privilege never accumulates and trust is continuously reevaluated without standing privilege to stop identity attacks. Next, we already saw that our user is expected to use AI as part of her job, but how does Entra Suite help with securing AI usage? -Let’s take a look. When our user leaves the office, she uses her personal laptop to work on an FY27 presentation from her team’s SharePoint site. She’s in Microsoft Edge, and using her personal browser profile. A SharePoint site is bookmarked, and she tries to access it. In order to get to the protected location on her laptop, she signs in with her work account, and Conditional Access requires an app protection policy, which then prompts her to switch the Edge profile to her work account. When she does, the device is now registered and the app protection policy is delivered to the browser. This automatically applies security settings and policies to the work browser profile. It enables explicit forward proxy settings and TLS inspection to add visibility into encrypted traffic, so that the company’s data protection policies can work with it. This includes Microsoft Edge data loss protection controls, as well as Microsoft Entra Internet Access, Secure AI and Web gateway policies. That way, she can access her work documents securely, like you’re seeing here with the internal FY27 planning presentation. -That said, when using her work profile in the browser, if she opens a new tab and she tries to access a social media site, we can see access is blocked based on the company policy. But once she switches back to her personal profile, access to Facebook works as expected. Policies are pushed automatically, even though she’s not using a managed device. -In fact, Entra Suite inspects and controls access to data. As she interacts with any website, her traffic routes through Entra Internet Access as a forward proxy. So every egress path is inspected in real time against the Purview sensitivity label applied at the source. Same label, same policy, whether she’s on a corporate laptop or a personal device. This time, our user returns to work with her managed work laptop, and she wants to analyze the data from the Pricing Dashboard using ChatGPT. She has a confidential internal product pricing schedule opened as a PDF and selects everything in the document, and she copies everything on the page. Then she moves over to ChatGPT and pastes the pricing info from her clipboard. -Here, Secure Web and AI Gateway in Entra Suite blocks the upload because there’s an organization-wide policy that prohibits sharing confidential data through a public AI tool. This adds an important layer of protection because a standalone web gateway or CASB can only see traffic, but not the data classification. This is made possible because network DLP parsed the chat text to spot sensitive information before ChatGPT saw the payload, and network DLP also will block the sharing of sensitive files over non-Microsoft email services like Gmail. Next, let’s look at the secure AI usage when the user leverages her company-sanctioned AI tool. Here’s the Zava Assistant that her manager approved. She starts opening a competitor blog and copies everything into her clipboard. Then she invokes the agent and starts to interact by pasting in the blog for summarization, but there’s a catch. Hidden inside the text is a human-invisible instruction telling the model to leak her query history. -Here, prompt injection protection inspects the outbound prompt against Microsoft’s adversarial pattern model, matches the known injection class, and blocks it before it’s processed. Additionally, new web filtering rules let you block agents from conducting risky operations on specified resources, by creating policies for browser-based and local apps communicating over web protocols. This time, our user remembers that she’s left a sensitive Zava partner memo in the shared Dropbox location. -So, using her locally installed Claude app, she requests another in-house developed Zava agent to remove that file from Dropbox. Immediately, she can see that this action was prevented based on the network policy from her company. And moving to the admin experience, these rules can differ whether it’s a user or agent session performing the operation. They can be configured to assess multiple HTTP methods, including POST, PATCH, PUT, and DELETE operations scoped to specific URLs or FQDNs. -Those were just a few examples of Microsoft Entra Suite and its unified approach to access. With Microsoft 365 E7, you can get Entra Suite protections and apply them to AI agents with Agent 365. -Check out our related deep dives at aka.ms/EntraSuitePlaylist, and to learn more, go to aka.ms/EntraSuite. Subscribe to Microsoft Mechanics for the latest tech updates, and thanks for watching.Zero Trust security for AI agents
Extend Conditional Access in Microsoft Entra to evaluate every agent authorization request in real time against the same risk signals as human users. Assign each agent its own managed identity with Entra Agent ID and scope permissions with Access Packages. Govern your MCP catalog as a software supply chain — unapproved tools don’t run, and approved servers lock behind Azure API Management. Log every agent tool call, API access, and data lookup into Microsoft Sentinel for continuous anomaly detection. Purview Insider Risk Management auto-assigns risk levels so you can investigate fast or revoke access entirely. DLP and sensitivity labels in Microsoft Purview restrict what agents can reach and auto-inherit to everything they generate, and Data Access Governance maps exactly what each agent can access before a prompt fires. Jeremy Chapman, Microsoft 365 Director, shares how to put these controls into practice across every managed, self-hosted, and shadow agent in your estate. Agent identities. Real-time risk evaluation. Conditional Access in Microsoft Entra evaluates every agent authorization request and enforces policy before agents connect. See how. Every tool call. Every API hit. Every data lookup. Microsoft Sentinel captures each one. Purview Insider Risk Management auto-assigns risk scores the moment anomalies surface. Start here. Govern your MCP catalog like a software supply chain. Block unapproved tools by default and scope approved MCP servers per agent behind Azure API Management. Check it out. QUICK LINKS: 00:00 — How AI changes Zero Trust 01:20 — Zero Trust principles 02:27 — How to apply Zero Trust principles 03:40 — Conditional Access for Agent Identities 04:59 — Entra Agent ID + Access Packages 06:07 — Runtime Observability 06:58 — DLP, Sensitivity Labels + Data Access Governance 07:47 — MCP catalog 08:36 — AI apps & experiences 09:24 — Wrap up Link References Watch the rest of this series at https://aka.ms/ZTMechanics For additional resources, check out https://aka.ms/GoZeroTrust Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -AI changes the Zero Trust and cybersecurity landscape. It’s reshaping how vulnerabilities in your environment are discovered and how they’re exploited at machine speed. And the question is whether your defenses can keep up. Now, as we’ve seen, new models are optimized to discover security gaps and zero days that have existed for decades undetected, finding exponentially more issues than humans can review in time before public models accessible via bad actors find the same exploits. -And that’s why Zero Trust is more important than ever to stop malicious access attempts as early as possible. The approach needs to be layered across identities, endpoints, your entire network layer, data, AI resources, and your apps and infrastructure because each introduce unique risks and act as a potential entry point. At every layer, real-time policy enforcement and protections are essential to ensure that every identity, every agent, and every endpoint that connects to your resources is thoroughly assessed and verified before gaining access to requested resources. -Today we’ll focus on the access controls and additional layers important to AI and how to apply Zero Trust at every step. Zero Trust principles themselves haven’t changed, but with AI they have to be applied in new ways. First, verify explicitly means always confirm who in terms of a person or device or what in case of AI or other processes is requesting access to your environment, assessing every app being used, deployed or developed in your environment, and giving every agentic actor its own discrete identity separate from the user who invoked it and separate from the workload it runs on. -Next enforce least privilege access now means making sure that AI can only reach the data it needs for the purpose it was authorized for. And it means agents themselves should only have the permissions required to complete the task in front of them, nothing more. And assume breach takes on a new meaning because you now need to assume that any prompt can carry malicious intent. Any response can leak sensitive data and any AI component, whether it’s an SDK, an MCP server connection or an agent itself can have vulnerabilities waiting to be exploited. -So let’s walk through how to apply these as AI access controls. The biggest risk at the access layer is also the most familiar one, your human users and the access tokens they hold. People are still security’s weakest link. And as AI accelerates, unknown or unmanaged agents, especially those running as local AI, impersonating human users now represent some of the greatest risk. That’s because AI just needs a stolen credential an overpermissioned account or a compromised session to get in, it doesn’t need to break encryption or find a brand new zero day. -AI can now autonomously discover weaknesses, can chain multiple lower severity issues and package it into a working end-to-end exploit all in a fraction of the time it would take a human attacker. And alongside your human users, there’s also a new class of identity requesting access to resources, AI agent identities, where unlike a person, it works at machine speed and around the clock. And while it doesn’t fall for phishing or forget its password, it can be hijacked through prompt injection or by being handed a malicious tool. -And if it has broad standing access, a single misconfiguration can open the door to a major breach that could be executed in just seconds, which is why the starting point for Zero Trust with AI and agents is identity itself with identity and access controls, where Conditional Access in Microsoft Entra evaluates every request in real time against signals like user risk, sign in risk, device health and location. And then it pairs that with phishing resistant authentication like passkeys so that only verified users can reach the apps and AI experiences that they’re authorized to use. And Conditional Access can also evaluate agent risk in real time for every authorization request that the agent makes against a resource. AI experiences amplify whatever access a user already has. -For AI, Microsoft Purview’s Data Security Posture Management gives you visibility into how users are interacting with data and AI so that you can spot risky patterns like oversharing or anomalous prompts early and increase your security posture before they become incidents. Using Microsoft Execution Containers, Windows can identify local AI agents and require them to run within the container using their own Agent IDs, which gives you control over them using Conditional Access policies. So at the identity and access management layer, agents need the same Zero Trust treatment as people, but adapted to how they work. -Now, this leads to inventory because you can’t protect what you can’t see. It means that to gain access and become a known object, every agent must have a governed identity. No more borrowed credentials where agents can run under the user’s token. We’re also using Conditional Access policies. Everything unmanaged and unknown should be blocked by default. Now, the first step is discovering every agent in your estate using Agent 365, whether it’s managed or self-hosted or unmanaged shadow agents, then reconciling them with your directory and access controls. -Entra Agent ID gives each agent its own unique manageable identities so that you can apply the same visibility, governance and use Conditional Access policies like you do for human users, but now for non-human actors too, to tightly control exactly what agents can access and under which conditions. And you can scope resource access individually for each agent. Access Packages as part of Microsoft Entra ID Governance with human sponsor approval let you grant just-enough-access for just-enough-time that expire when work is done. But identity is only the first checkpoint. Once an agent is inside your perimeter, you need to see what it’s actually doing in real time and that’s for runtime observability comes in. -So for that, using sign-in and audit logs, you can see every tool call, every API access attempt and every data lookup and every request that an agent makes. It should also be logged against Microsoft Sentinel as your SIEM and continuously evaluated against anomaly detection so that it’s seamlessly integrated with your alerting incident management and investigation controls. And if an agent can’t be observed, well, it can’t be trusted. Insider Risk Management in Microsoft Purview now extends to agents automatically assigning risk levels based on their data activities. So you can prioritize investigations, apply targeted controls or revoke access entirely when something looks wrong. Then there’s the data and tools behind every agent, files that the agent grounds on, the backends it queries, the MCPs it can call, and the models it’s wired to, they’re all reachable and they all need a control with a name on it. -Let’s start with data because that’s ultimately what the agent is after. DLP and sensitivity labels can restrict AI access even when a user has permission to open a document directly. And if labeled content is used, the label is also automatically inherited by anything the agent generates from it. Data access governance shows you exactly which sites, items and sharing links every agent can reach, so you can tighten access at the source before a single prompt is sent. Policy protections also cover your structured data backends, including Fabric, OneLake and others. Moving on to the tools that an AI agent can call, here you should treat the MCP catalog like any third party software supply chain, where unapproved tools don’t run and approved tools run only for the agents that you’ve assigned them to. -In fact, every approved MCP server created by your organization can be protected behind Azure API Management. Likewise, AI agents built in Microsoft Foundry need guardrails to block risky behavior, including jailbreak attempts, prompt injection, and prevent protected material from being processed. Agents have a deep tool belt, and if you only close one door, they’ll quickly find another way to reach files, systems of record or sensitive data. Controls should be continuous at runtime across identity, data as well as the underlying tools and models. -And that brings us to the AI apps and experiences your users and agents are actually trying to reach and the related controls. Microsoft Defender for Cloud Apps gives you visibility into every AI app and use with risk-based controls to govern app behavior and data protection policies that prevent misuse and exfiltration. Microsoft Edge also has controls to prevent users signed into their work accounts from using consumer grade Shadow AI apps. Also for local AI, Microsoft Intune and Microsoft Defender provide agent discovery signals to detect unsanctioned local agents. You can see where these are being used on managed devices in your environment. And an Intune security baseline allows you to restrict common execution paths that local agents like OpenClaw may use. -AI doesn’t just create new risks, it amplifies existing ones, stale permissions, overshared data, ungoverned apps, and weak authentication. It exposes and exploits those gaps faster than any human attacker, but the same works in reverse. Zero Trust controls, strong identity, least privilege, real-time policy, and runtime observability can also operate at machine speed to reduce risk. Agent 365 unifies these AI controls across Microsoft Entra, Purview, Intune and Defender, while letting each domain expert work within their tool of choice. Whether that’s identity and access management, data security and compliance, endpoint management for local AI or security operations for incident and threat management. In the AI era, the principles remain the same. Verify explicitly, enforce least privilege and assume breach across every agent, user and app. -For additional resources, free workshops and hands-on implementation guidance with experts, check out aka.ms/GoZeroTrust. Subscribe to Microsoft Mechanics if you haven’t already. Thanks for watching.
Microsoft Leads a New Era of Software Supply Chain Transparency
Today, Microsoft announces the general availability of Microsoft’s Signing Transparency (MST) – a first-of-its-kind capability that brings unprecedented visibility and trust to our software supply chain. With this release, Microsoft is leading the industry by recording the build of critical cloud services into a publicly readable and verifiable SCITT standard (Supply Chain Integrity, Transparency, and Trust) compliant blockchain ledger. This means every production software build for in scope services like Azure Attestation and Azure Managed HSM (Hardware Security Module), Azure confidential ledger, Microsoft Signing Transparency itself (and others over time) – is now logged in an immutable, tamper-evident record. Only builds that are in the MST ledger are deployed to production; this gives customers confidence that the supply chain for these critical services can be audited at anytime. Notably, the MST ledger is fully open source and built to align with the emerging IETF SCITT standard. By embracing SCITT’s principles and open protocols, Microsoft ensures that MST not only secures our own ecosystem but also contributes to a broader industry movement toward standardized supply chain transparency. The open-source MST ledger serves as a verifiable trust anchor that any organization or researcher can inspect, audit, or even integrate with their own tooling. MST itself meets the highest levels of transparency, backed by a tamper-proof confidential ledger, open-source, and independently verified. Specifically, we are making the foundation of our trust model transparent and accessible to everyone – reinforcing that trust must be earned through proof, not just promises. This launch marks a major milestone in our commitment to Zero Trust principles, extending “never trust, always verify” all the way into the build itself. Building on a public preview introduced late last year, MST’s general availability delivers verifiable transparency at the software level. It transforms traditional code signing with an additive trust layer that is accessible via an open verification model. Every new software update is accompanied by a publicly auditable proof of integrity, enabling security teams to proactively confirm that each update is authentic and unaltered. To help organizations get the most out of this capability, we are also introducing a free tool to explore the contents – Ledger Explorer – an offline tool that allows security teams to examine MST ledger entries, verify cryptographic proofs, and even validate the ledger’s integrity independently. This tool, combined with MST’s open design, ensures that every Microsoft customer – and the broader community – can hold us accountable in real time for the software we run on their behalf. Key Benefits of Microsoft’s Signing Transparency (MST) Verified Code Integrity – Every software release is cryptographically logged in MST’s ledgers. This makes each build tamper-evident and traceable. If an attacker attempts to inject malicious code or sign an unauthorized update, it will be evident through the well-defined validation step built into the SCITT standard. Organizations gain the assurance that code integrity can be independently confirmed at any time. Independent Verification & Zero Trust – MST enables customers and auditors to verify software authenticity on their own, without having to solely rely on vendor attestations. For each update, Microsoft provides a transparency “receipt” (proof of logging) that you can use to prove the update was officially published and unaltered. This fosters a “don’t just trust, verify” approach, empowering security teams to double-check everything running in their environment aligns with what Microsoft intended. Audit-Trail & Compliance – The transparency ledger creates a permanent, auditable timeline of code deployments. Every entry is a record of what was released and when, backed by cryptographic proofs. This simplifies compliance reporting and accelerates forensic analysis. In the event of an incident, you can quickly audit the ledger to see if any unexpected code was introduced. For highly regulated industries, MST offers concrete evidence of software integrity and policy compliance over time. Leadership & Open Standards – We are delivering real transparency now, encouraging a future where all critical software is released with verifiable integrity. MST’s open source implementation and SCITT-compliant design exemplify our commitment to openness and collaboration. We believe widespread adoption of these standards will strengthen supply chain security for everyone, making trust verification a universal practice. Next Steps Microsoft’s Signing Transparency is more than a new security feature and shapes the advances in trust technology. As threats grow more sophisticated, we must evolve the way we assure our customers about the software they depend on. With MST now generally available, we are leading by example: proving that it is possible to open up the traditionally opaque process of software deployment and turn it into a source of strength and trust, i.e., empowering each person with verifiable transparency. We invite the industry to join us on this journey and get started by reading the documentation and exploring Ledger Explorer today! Together, by embracing transparency and open standards, we can turn “trust but verify” from a slogan into an everyday reality for digital infrastructure.Intent‑Aware Static Inspection for Agent and Skill Packages
Where AV helps—and what it may not cover Antivirus engines and traditional code scanners are highly effective at identifying known or suspicious executable content, such as binaries, scripts, or exploit patterns. For YAML‑based agent and skill packages, the situation can be different. These packages are often intentionally minimal to reduce distribution overhead and support faster inference. As a result, a configuration file may appear benign from a malware perspective, yet still introduce risk depending on how instructions are written and interpreted. For example, areas that may warrant closer review include: Instructions that influence how data is accessed, processed, or reused across requests Language that expands scope beyond an agent’s or skill’s stated purpose Requests for sensitive information outside expected or documented workflows Guidance that affects how untrusted or external inputs are handled during inference These scenarios do not necessarily indicate malicious intent, but they highlight cases where traditional scanning alone may not fully capture behavioral risk. What to look for when the “payload” is instructions When you review an agent or skill package, you’re effectively reviewing a compact behavior specification. In instruction‑driven designs—often chosen to keep inference paths fast and simple—the goal is not to analyze complex code, but to understand what behavior the instructions enable. A few practical signals include: Intent drift: the description is narrow, but the instructions encourage broader collection, retention, or escalation Overreach by default: language such as “always,” “for every user,” “across all workspaces,” “keep trying,” or “don’t stop until” Exfiltration pathways: instructions to send outputs to external endpoints, webhooks, or reporting channels not aligned with the stated purpose Credential‑related cues: asking users to provide secrets, tokens, recovery codes, or to authenticate outside expected flows Stealth language: “avoid logging,” “don’t mention this to the user,” “run quietly,” or “hide the reason” Injection susceptibility: treating untrusted text as commands (for example, “follow the user’s pasted script exactly” or “execute whatever is in the ticket”) A better model: intent-aware static inspection One practical way to approach review is to treat the instructions as a compact behavior specification. In many agent and skill designs, this specification is intentionally concise to support low latency, low inference cost, and efficient execution. The goal of inspection is not to second-guess that design choice, but to ensure the enabled behavior matches the stated purpose and expected boundaries. By applying intent-aware static inspection with explicit thresholds, review effort was focused on higher-risk packages. Over a one-month internal evaluation, approximately 400 agent and skill packages were reviewed with 1 observed false positive (< 0.0001%), reflecting high detection accuracy. At the same time, the approach preserves system efficiency, delivering low latency (under 10 seconds for most packages) and consistently low inference cost. A lightweight review workflow model Normalize the package: extract human‑readable fields (descriptions, system prompts, tool instructions, examples) and ignore structural YAML details Summarize intended behavior: describe what the agent or skill is expected to do in plain language, independent of implementation Check for higher‑risk actions: broad data access, external sharing, credential requests, persistence, or stealth behavior Decide with thresholds: route low‑risk, narrowly scoped packages differently from those with broader reach or reuse Keep an audit trail: retain a brief summary of extracted intent and review rationale to support iteration over time Final thoughts YAML‑based agent and skill packages are not inherently risky; they are often chosen precisely because they enable simpler distribution and faster inference. The key consideration is how instruction‑defined behavior aligns with expectations and boundaries as packages evolve and are reused. Combining traditional scanning with lightweight, intent‑aware inspection helps teams preserve the benefits of fast, instruction‑driven systems while improving confidence in how those systems behave in practice.Strengthen your security posture with Microsoft Entra Conditional Access
Learn how Microsoft Entra Conditional Access, our Microsoft Zero Trust policy engine, protects access for your workforce and for agents by enforcing real‑time adaptive access policies that continuously assess risk signals and use AI‑driven automation to dynamically allow, challenge, or block access for every identity. Join Microsoft experts as they walk through real‑world scenarios and share practical guidance to help your identity team address policy sprawl, enforce consistent Conditional Access policies, and strengthen security posture across your environment. How do I participate? Registration is not required. Add this event to your calendar, then sign in to the Tech Community and select Attend to receive reminders. Post your questions in advance, or any time during the live broadcast. Note: This session was originally scheduled for June 8, 2026 and will now take place on June 24, 2026.Migrate Sentinel to Defender - Why It Is a Security Architecture Decision, Not Just a Portal Change
Microsoft will retire the Sentinel experience in Azure on March 31, 2027. Most of the conversation around this transition focuses on cost optimization and portal consolidation. That framing undersells what is actually happening. The unified Defender portal is not a new interface for the same capabilities. It is the platform foundation for a fundamentally different SOC operating model — one built on a 2-tier data architecture, graph-based investigation, and AI agents that can hunt, enrich, and respond at machine speed. Partners who understand this will help customers build security programs that match how attackers actually operate. This document covers four things: What the unified experience delivers — the security capabilities that do not exist in standalone Sentinel and why they matter against today’s threats. What the transition really involves - is not data migration, but it is a data architecture project that changes how telemetry flows, where it lives, and who queries it. Where the partner opportunity lives — a structured progression from professional services (transactional, transition execution, and advisory) to ongoing managed security services. Why does the unified experience win competitively — factual capability advantages that give partners a defensible position against third-party SIEM alternatives. The Bigger Picture: Preparing for the Agentic SOC Before getting into transition mechanics, partners need to understand where the industry is headed — because the platform decisions made during this transition will determine whether a customer’s SOC is ready for what comes next. The security industry is moving from human-driven, alert-centric workflows to an operating model built on three pillars: Intellectual Property — the detection logic, hunting hypotheses, response playbooks, and domain expertise that differentiate one security team from another. Human Orchestration — the judgment, context, and decision-making that humans bring to complex incidents. Humans set strategy, validate findings, and make containment decisions. They do not manually triage every alert. AI Agents - built agents that execute repeatable work: enriching incidents, hunting across months of telemetry, validating security posture, drafting response actions, and flagging anomalies for human review. The SOC of 2027 will not be scaled by hiring more analysts. It will be scaled by deploying agents that encode institutional knowledge into automated workflows — orchestrated by humans who focus on the decisions that require judgment. This transformation requires a platform that provides three things: Deep telemetry — agents need months of queryable data to analyze behavioral patterns, build baselines, and detect slow-moving threats. The Sentinel data lake provides this at a cost point that makes long-retention feasible. Relationship context — agents need to understand how entities connect. Which accounts share credentials? What is the blast radius of a compromised service principle? What is the attack path from a phished user to domain admin? Sentinel Graph provides this. Extensibility — partners and customers need to build and deploy their own agents without waiting for Microsoft to ship them. The MCP framework and Copilot agent architecture provide this. None of these exist in Azure experience for Sentinel. All three ship with the Defender experience. The urgency goes beyond the March 2027 deadline. Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses — and every one of those creates a new attack surface. Prompt injection, data poisoning, agent hijacking, cross-plugin exploitation — these are not theoretical risks. They are in the wild today. Defending against AI-powered attacks requires a security platform that is itself AI Agent-ready. The new experience in Defender unlocks this experience. What Unified SIEM and XDR Actually Delivers The original framing — “single pane of glass for SIEM and XDR” — is accurate but insufficient. Here is what the unified platform delivers that standalone Sentinel does not. Cross-Domain Incident Correlation The Defender correlation engine does not just group alerts by time proximity. It builds multi-stage incident graphs that link identity compromise to lateral movement to data exfiltration across SIEM and XDR telemetry — automatically. Consider a token theft chain: an infostealer harvests browser session cookies (endpoint telemetry), the attacker replays the token from a foreign IP (Entra ID sign-in logs), creates a mailbox forwarding rule (Exchange audit logs), and begins exfiltrating data (DLP alerts). In standalone Sentinel, these are four separate alerts in four different tables. In the unified platform, they are one correlated incident with a visual attack timeline. 2-Tier Data Architecture The Sentinel data lake introduces a second storage tier that changes the economics and capabilities of security telemetry: Analytics Tier Data Lake Purpose Real-time detection rules, SOAR, alerting Hunting, forensics, behavioral analysis, AI agent queries Latency Sub-5-minute query and alerting Minutes to hours acceptable Cost ~$4.30/GB PAYG ingestion (~$2.96 at 100 GB/day commitment) ~$0.05/GB ingestion + $0.10/GB data processing (at least 20x cheaper) Retention 90 days default (expensive to extend) Up to 12 years at low cost Best for High-signal, low-volume sources High-volume, investigation-critical sources The architecture decision is not “which tier is cheaper.” It is “which tier gives me the right detection capability for each data source.” Analytics tier candidates: Entra ID sign-in logs, Azure activity, audit logs, EDR alerts, PAM events, Defender for Identity alerts, email threat detections. These need sub-5-minute alerting. Data lake candidates: Raw firewall session logs, full DNS query streams, proxy request logs, Sysmon process events, NSG flow logs. These drive hunting and forensic analysis over weeks or months. Dual-ingest sources: Some sources need both tiers. Entra ID sign-in logs are the canonical example — analytics tier for real-time password spray detection, Data Lake for graph-based blast radius analysis across months of authentication history. Implementation is straightforward: a single Data Collection Rule (DCR) transformation handles the split. One collection point, two routing destinations. The right framing: “Right data in the right tier = better detections AND lower cost.” Cost savings are a side effect of good security architecture, not the goal. Sentinel Graph Sentinel graph enables SOC teams and AI agents to answer questions that flat log queries cannot: What is the blast radius of this compromised account? Which service principals share credentials with the breached identity? What is the attack path from this phished user to domain admin? Which entities are connected to this suspicious IP across all telemetry sources? Graph-based investigation turns isolated alerts into context-rich intelligence. It is the difference between knowing “this account was compromised” and understanding “this account has access to 47 service principals, 3 of which have written access to production Key Vault.” Security Copilot Integration Security Copilot embedded in the defender portal helps analysts summarize incidents, generate hunting queries, explain attacker behavior, and draft response actions. For complex multi-stage incidents, it reduces the time from “I see an alert” to “I understand the full scope” from hours to minutes. With free SCUs available with Microsoft 365 E5, teams can apply AI to the highest-effort investigation work without adding incremental cost. MCP and the Agent Framework The Model Context Protocol (MCP) and Copilot agent architecture let partners and customers build purpose-built security agents. A concrete example: an MCP-enabled agent can automatically enrich a phishing incident by querying email metadata, checking the sender against threat intelligence, pulling the user’s recent sign-in patterns, correlating with Sentinel Graph for lateral risk, and drafting a containment recommendation — in under 60 seconds. This is where partner intellectual property becomes competitive advantage. The agent framework is the mechanism for encoding proprietary detection logic, response playbooks, and domain expertise into automated workflows that run at machine speed. Security Store Security Store allows partners to evolve from one‑time transition projects into repeatable, scalable offerings—supporting professional services, managed services, and agent‑based IP that align with the customer’s unified SecOps operating model As part of the transition, the Microsoft Security Store becomes the extension layer for the Defender —allowing partners to deliver differentiated agents, SaaS, and security services natively within Defender and Sentinel, instead of building and integrating in isolation The 4 Investigation Surfaces: A Customer Maturity Ladder The Sentinel Data Lake exposes four distinct investigation surfaces, each representing a step toward the Agentic SOC — and a partner service opportunity: Surface Capability Maturity Level Partner Opportunity KQL Query Ad-hoc hunting, forensic investigation Basic — “we can query” Hunting query libraries; KQL training Graph Analytics Blast radius, attack paths, entity relationships Intermediate — “we understand relationships” Graph investigation training; attack path workshops Notebooks (PySpark) Statistical analysis, behavioral baselines, ML models Advanced — “we predict behaviors” Custom notebook development; anomaly scoring Agent/MCP Access Autonomous hunting, triage, response at machine speed Agentic SOC — “we automate” Custom agent development; MCP integration The customer who starts with “help us hunt better” ends up at “build us agents that hunt autonomously.” That is the progression from professional services to managed services. What the Transition Actually Involves It is not a data migration — customers’ underlying log data and analytics remain in their existing Log Analytics workspaces. That is important for partners to communicate clearly. But partners should not set the expectation that nothing changes except the URL. Microsoft’s official transition guide documents significant operational changes — including automation rules and playbooks, analytics rule, RBAC restructuring to the new unified model (URBAC), API schema changes that break ServiceNow and Jira integrations, analytics rule transitions where the Fusion engine is replaced by the Defender XDR correlation engine, and data policy shifts for regulated industries. Most customers cannot navigate this complexity without professional help. Important: Transitioning to the Defender portal has no extra cost - estimate the billing with the new Sentinel Cost Estimator Optimizing the unified platform means making deliberate changes: Adding dual-ingest for critical sources that need both real-time detection and long-horizon hunting. Moving high-volume telemetry to the Data Lake — enabling hunting at scale that was previously cost-prohibitive. Retiring redundant data copies where Defender XDR already provides the investigation capability. Updating RBAC, automation, and integrations for the unified portal’s consolidated schema and permission structure. Training analysts on new investigation workflows, Sentinel Graph navigation, and Copilot-assisted triage. Threat Coverage: The Detection Gap Most Organizations Do Not Know They Have This transition is an opportunity to quantify detection maturity — and most organizations will not like what they find. Based on real-world breach analysis — infostealers, business email compromise, human-operated ransomware, cloud identity abuse, vulnerability exploitation, nation-state espionage, and other prevalent threat categories — organizations running standalone Sentinel with default configurations typically have significant detection gaps. Those gaps cluster in three areas: Cross-domain correlation gaps — attacks that span identity, endpoint, email, and cloud workloads. These require the Defender correlation engine because no single log source tells the complete story. Long-retention hunting gaps — threats like command-and-control beaconing and slow data exfiltration that unfold over weeks or months. Analytics-tier retention at 90 days is too expensive to extend and too short for historical pattern analysis. Graph-based analysis gaps — lateral movement, blast radius assessment, and attack path analysis that require understanding entity relationships rather than flat log queries. The unified platform with proper log source coverage across Microsoft-native sources can materially close these gaps — but only if the transition includes a detection coverage assessment, not just a portal cutover. Partners should use MITRE ATT&CK as the common framework for measuring detection maturity. Map existing detections to ATT&CK tactics and techniques before and after transition — a measurable, defensible improvement that justifies advisory fees and ongoing managed services. Partner Opportunity: Professional Services to Managed Services This transition creates a structured progression for all partner types — from professional services that build trust and surface findings, to managed security services that deliver ongoing value. The key insight most partners miss: do not jump from “transition assessment” to “managed services pitch.” Customers are not ready for that conversation until they have experienced the value of professional services. The bridge engagement — whether transactional, transition execution, or advisory — builds trust, demonstrates the expertise, and surfaces the findings that make the managed services conversation a logical next step. Professional Services (transactional + transition execution + advisory) → Managed Security Services (MSSP) The USX transition is the ideal professional services entry point because it combines a mandatory deadline (March 2027) with genuine technical complexity (analytics rule, automation behavioral changes, RBAC restructuring, API schema shifts) that most customers cannot navigate alone. Every engagement produces findings — detection gaps, automation fragility, staffing shortfalls — that are the most credible possible evidence for managed services. Professional Services Transactional Partners Offer Customer Value Key Deliverables Transition Readiness Assessment Risk-mitigated transition with clear scope Sentinel deployment inventory; Defender portal compatibility check; transition roadmap with timeline; MITRE ATT&CK detection coverage baseline Transition Execution and Enablement Accelerated time-to-value, minimal disruption Workspace onboarding; RBAC and automation updates; Dual-portal testing and validation; SOC team training on unified workflows Security Posture and Detection Optimization Better detections and lower cost Data ingestion and tiering strategy; Dual-ingest implementation for critical sources; Detection coverage gap analysis; Automation and Copilot/MCP recommendations Advisory Partners Offer Customer Value Key Deliverables Executive and Strategy Advisory Leadership alignment on why this transition matters Unified SecOps vision and business case; Zero Trust and SOC modernization alignment; Stakeholder alignment across security, IT, and leadership Architecture and Design Advisory Future-ready architecture optimized for the Agentic SOC Target-state 2-tier data architecture; Dual-ingest routing decisions mapped to MITRE tactics; RBAC, retention, and access model design Detection Coverage and Gap Analysis Measurable detection maturity improvement Current-state MITRE ATT&CK coverage mapping; Gap analysis against 24 threat patterns; Detection improvement roadmap with priority recommendations SOC Operating Model Advisory Smooth analyst adoption with clear ownership Redesigned SOC workflows for unified portal; Incident triage and investigation playbooks; RACI for detection engineering, hunting, and platform ops Agentic SOC Readiness Preparation for AI-driven security operations MCP and agent architecture assessment; Custom agent development roadmap; IP + Human Orchestration + Agent operating model design Cost, Licensing and Value Advisory Transparent cost impact with strong business case Current vs. future cost analysis; Data tiering optimization recommendations; TCO and ROI modeling for leadership The conversion to managed services is evidence-based. Every professional services engagement produces findings — detection gaps, automation fragility, staffing shortfalls. Those findings are the most credible possible case for ongoing managed services. Managed Security Services The unified platform changes the managed security conversation. Partners are no longer selling “we watch your alerts 24/7.” They are selling an operating model where proprietary AI agents handle the repeatable work — enrichment, hunting, posture validation, response drafting — and human experts focus on the decisions that require judgment. This is where the competitive moat forms. The formula: IP + Human Orchestration + AI Agents = differentiated managed security. The unified platform enables this through: Multi-tenancy — the built-in multitenant portal eliminates the need for third-party management layers. Sentinel Data Lake — agents can query months of customer telemetry for behavioral analysis without cost constraints. Sentinel Graph — agents can traverse entity relationships to assess blast radius and map attack paths. MCP extensibility — partners can build agents that integrate with proprietary tools and customer-specific systems. Partners who build proprietary agents encoding their detection logic into the MCP framework will differentiate from partners who rely on out-of-box capabilities. The Securing AI Opportunity Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses at an accelerating pace. Every AI deployment creates a new attack surface — prompt injection, data poisoning, agent hijacking, cross-plugin exploitation, unauthorized data access through agentic workflows. These are not theoretical risks. They are in the wild today. Partners who can help customers secure their AI deployments while also using AI to strengthen their SOC will command premium positioning. This requires a security platform that is itself AI Agent-ready — one that can deploy defensive agents at the same pace organizations deploy business AI. The unified Defender portal is that platform. Partners who position USX as “preparing your SOC for AI-driven security operations” will differentiate from partners who position it as “moving to a new portal.” Cost and Operational Benefits Better security architecture also costs less. This is not a contradiction — it is the natural result of putting the right data in the right tier. Benefit How It Works Eliminate low-value ingestion Identify and remove log sources that are never used for detections, investigations, or hunting. Immediately lowers analytics-tier costs without impacting security outcomes. Right-size analytics rules Disable unused rules, consolidate overlapping detections, and remove automation that does not reduce SOC effort. Pay only for processing that delivers measurable security value. Avoid SIEM/XDR duplication Many threats can be investigated directly in Defender XDR without duplicating telemetry into Sentinel. Stop re-ingesting data that Defender already provides. Tier data by detection need Store high-volume, hunt-oriented telemetry in the Data Lake at at least 20x lower cost. Promote only high-signal sources to the analytics tier. Full data fidelity preserved in both tiers. Reduce operational overhead Unified SIEM+XDR workflows in a single portal reduce tool switching, accelerate investigations, simplify analyst onboarding, and enable SOC teams to scale without proportional headcount increases. Improve detection quality The Defender correlation engine produces higher-fidelity incidents with fewer false positives. SOC teams spend less time triaging noise and more time on real threats. Competitive Positioning Partners need defensible talking points when customers evaluate third-party SIEM alternatives. The following advantages are factual, sourced from Microsoft’s transition documentation and platform capabilities — not marketing claims. No extra cost for transitioning — even for non-E5 customers. Third-party SIEM migrations involve licensing, data migration, detection rewrite, and integration rebuild costs. Native cross-domain correlation across Sentinel + Defender products into multi-stage incident graphs. Third-party SIEMs receive Microsoft logs as flat events — they lack the internal signal context, entity resolution, and product-specific intelligence that powers cross-domain correlation. Custom detections across SIEM + XDR — query both Sentinel and Defender XDR tables without ingesting Defender data into Sentinel. Eliminates redundant ingestion cost. Alert tuning extends to Sentinel — previously Defender-only capability, now applicable to Sentinel analytics rules. Net-new noise reduction. Unified entity pages — consolidated user, device, and IP address pages with data from both Sentinel and Defender XDR, plus global search across SIEM and XDR. Third-party SIEMs provide entity views from ingested data only. Built-in multi-tenancy for MSSPs — multitenant portal manages incidents, alerts, and hunting across tenants without third-party management layers. Try out the new GDAP capabilities in Defender portal. Industry validation: Microsoft’s SIEM+XDR platform has been recognized as a Leader by both Forrester (Security Analytics Platforms, 2025) and Gartner (SIEM Magic Quadrant, 2025). Summary: What Partners Should Take Away Topic Key Message Framing USX is a security architecture transformation, not a portal transition. Lead with detection capability, not cost savings. Platform foundation Sentinel Data Lake + Sentinel Graph + MCP/Agent Framework = the platform for the Agentic SOC. 4 investigation surfaces KQL → Graph → Notebooks → Agent/MCP. A maturity ladder from “we can query” to “we automate at machine speed.” Architecture 2-tier data model (analytics + Data Lake) with dual-ingest for critical sources. Cost savings are a side effect of good architecture. Transition complexity Analytics rules and automation rules. API schema changes. RBAC restructuring. Most customers need professional help. Partner engagement model Professional Services (transactional + transition execution + advisory) → Managed Services (MSSP). Competitive positioning No extra cost. Native correlation. Cross-domain detections. Built-in multi-tenancy. Capabilities third-party SIEMs cannot replicate. Partner differentiation IP + Human Orchestration + AI Agents. Partners who build proprietary agents on MCP have competitive advantage. Timeline March 31, 2027. Start now — phased transition with one telemetry domain first, then scale.
