rss.livelink.threads-in-node

Graph API Endpoint for the Vulnerability Profile

scottholland — Tue, 28 Jul 2026 12:02:06 GMT

I can use this endpoint to get threat reports via the graph api

GET

https://graph.microsoft.com/beta/security/threatIntelligence/article

but threat Analytics reports that come in from defender that are category: vulnerability, aren't in there However they are written up in an article style. What endpoint do I need to hit to get these types of reports.

Verifying domain name issue

I-Leadership — Tue, 28 Jul 2026 11:34:53 GMT

We're trying to verify our custom domain in Entra ID, but it turns out the domain is already claimed on another tenant that we have no access to (unknown account, no admin credentials). Because of that, verification on our own tenant fails.

Normally the fix for a claimed-domain conflict is to open a support request so Microsoft can help release it. The problem: doing that requires a support plan, and purchasing one doesn't work for us. "payment" always succeeds and we dont get an error, but we don't get charged and the account status doesn't change, we have nothing more to go on.

So we're stuck in a loop: we need support to release the domain, but we can't buy the support plan needed to reach support.

Has anyone dealt with a domain claimed on an inaccessible tenant? And is there another route to Microsoft support when the support plan purchase itself fails?

Microsoft Fabric metadata in Microsoft Purview

sashakorniakUK — Tue, 28 Jul 2026 07:18:33 GMT

I’ve been mapping how Microsoft Fabric metadata is surfaced in Microsoft Purview through Data Map scanning, and I’ve created this visual to make the relationship easier to understand.

The diagram separates:

Documented mappings – such as Fabric items, Lakehouse tables, schema and item-level lineage.

Metadata known to be scanned, but where the exact Purview UI location needs confirmation.
? Areas still needing validation – particularly Lakehouse table/column descriptions and tags.

The principle I’m exploring is:

Microsoft Fabric → Purview Data Map Scan → Purview Data Asset → Purview governance enrichment

Importantly, a Fabric asset does not automatically become a Purview Data Product. It is first represented as a Data Asset, which can then be governed, enriched and associated with a Data Product.

I’d really appreciate feedback from anyone working hands-on with Microsoft Fabric and Microsoft Purview:

Does this mapping match what you are seeing in your environment?

I’m particularly interested in confirming:

Lakehouse table descriptions → Purview Asset Description?
Lakehouse column descriptions → Purview Schema → Column Description?
Lakehouse table/column tags → where exactly are these surfaced in Purview?

Corrections, screenshots or practical experience would be very welcome.

Rescheduled Webinar: What's New in Azure Firewall

emilyfalla — Mon, 27 Jul 2026 18:38:07 GMT

Hi everyone!

The webinar "What's New in Azure Firewall" that was originally scheduled for August 6th, has been rescheduled to August 26th. You can find more details on our Community Home.

We apologize for the inconvenience, and hope to see you there!

Securing AI Agents at Runtime: Real-Time Protection and Threat Detection for Microsoft Agent 365

llevy — Mon, 27 Jul 2026 17:37:49 GMT

Organizations are rapidly adopting AI agents to automate workflows, access enterprise data, invoke tools, and take actions on behalf of users. This autonomy creates a fundamentally new security challenge.

Unlike traditional AI applications, agents operate across dynamic execution flows, interacting with external content, calling tools, and accessing sensitive resources. These interactions create new attack paths that traditional security controls were not designed to address.

Today, we're announcing two major milestones for Security for AI in Microsoft Defender for Microsoft Agent 365:

Threat detection for Microsoft Agent 365 agents — now in public preview.

Real-time protection for Microsoft Agent 365 tooling servers — now generally available.

Together, these capabilities help security teams detect, investigate, and block attacks targeting AI agents, extending Microsoft Defender's threat protection capabilities into the agent runtime.

Threat detection for Microsoft Agent 365 Agents (Public Preview)

Threat detection provides SOC teams with detailed visibility into attacks and suspicious activity targeting AI agents. By analyzing runtime signals across agent interactions, tool usage, and execution patterns, Microsoft Defender identifies suspicious and malicious behavior throughout the agent execution lifecycle and surfaces actionable security alerts for SOC teams.

Threat detection supports cloud agent types that emit observability logs to Microsoft Agent 365, including:

Microsoft Copilot Studio

Microsoft Foundry

Microsoft 365 Copilot Agent Builder

Agents integrated through the Microsoft Agent 365 SDK

This provides consistent threat visibility across supported Microsoft Agent 365 agent experiences, regardless of how the agent was built.

Fig. 1. Microsoft Security for AI alerts in Microsoft Defender XDR (Preview)

Microsoft Defender identifies a broad range of AI-specific threats, including:

Indirect prompt injection (XPIA) — malicious instructions embedded in external content designed to manipulate agent behavior.

Evasion techniques — attempts to bypass agent instructions or security controls.

Malicious content propagation — attempts to use agents to generate or distribute malicious content.

Secret leakage — exposure of credentials, API keys, or other sensitive information through agent interactions.

LLM reconnaissance — attempts to probe agent capabilities, instructions, or security boundaries.

Suspicious IP access — agent access originating from anonymized or suspicious IP addresses.

Alerts are surfaced directly in Microsoft Defender, enabling SOC analysts to investigate and respond using familiar workflows, Advanced Hunting queries, and the Defender XDR investigation experience.

Real-time protection for WorkIQ and Custom MCP servers (General Availability)

Real-time protection moves beyond detection by blocking threats inline when AI agents interact with WorkIQ and custom MCP servers (see Microsoft Agent 365 tooling servers).

When an agent invokes a registered tool or receives a tool response, Defender evaluates the interaction against configured security policies and determines whether to allow or block it directly within the agent's execution flow.

This helps prevent malicious actions and data leakage in real time, without requiring agent developers to implement custom security logic.

Fig. 2. Microsoft Security for AI Real-Time Protection policy in Defender

Real-time protection currently guards against high-impact threats, including:

Evasion techniques — attempts to bypass agent guardrails or security controls.

Malicious content propagation — preventing agents from spreading malicious content through tool actions.

Secret leakage — blocking agents from inadvertently exposing credentials or sensitive data through tool calls.

Communication with untrusted domains — preventing agents from sending email or data to high-risk or untrusted email domains.

Better Together: Detection and Protection

Threat detection and real-time protection address complementary parts of the agent security lifecycle.

Real-time protection provides inline enforcement to block malicious interactions during execution, while threat detection gives SOC teams the visibility and investigation context needed to identify attack patterns, assess impact, and respond to suspicious activity.

Together, they provide a defense-in-depth approach that combines runtime enforcement with SOC-driven detection and investigation, purpose-built for AI agents.

Getting Started

Both capabilities are available through Microsoft Defender, using a dedicated Security for AI workload experience that brings together AI threat detections, investigations, and runtime protection policies.

To learn more:

Enable security for AI agents using Microsoft Defender

Detect and investigate threats to AI agents using Microsoft Defender (Preview)

Protect AI agents in real time using Microsoft Defender

As AI agents become more autonomous and gain access to enterprise data and tools, securing their runtime behavior becomes critical. With Threat Detection and Real-Time Protection, Microsoft Defender helps organizations adopt AI agents with security controls designed for how agents actually operate—detecting attacks, enabling SOC investigation, and blocking malicious interactions at runtime.

Level Up Your Security Skills This August with the Microsoft Defender Challenge and Learn Live

ShirleyseHaley — Mon, 27 Jul 2026 16:47:02 GMT

Security teams face an increasingly complex landscape. Threats span identities, endpoints, email, cloud workloads, and emerging AI environments. The best defenders aren't just reacting to threats—they're continuously building the skills needed to stay ahead.

That's why we're inviting security practitioners to build practical security operations expertise while working toward their next certification goal. Running from July 20 through August 21, 2026, and focused on skills across Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Defender for Cloud, this hands-on learning experience is the Microsoft Defender Challenge.

Build Skills That Matter to the Modern SOC

The Microsoft Defender Challenge isn't about memorizing content for an exam. It's designed to help you develop real-world security skills you can apply immediately in your organization. Through curated Microsoft Learn content, you'll strengthen your ability to:

Detect, investigate, and respond to threats across Microsoft Defender XDR

Manage incidents and automate workflows with Microsoft Sentinel

Triage and remediate security alerts in Microsoft Defender for Cloud

Secure cloud and AI workloads using modern security practices

Improve operational readiness for today's evolving threat landscape

Whether you're a SOC analyst, security engineer, cloud security practitioner, or IT professional looking to expand your security expertise, the challenge is an opportunity to sharpen skills that map directly to modern security operations.

Complete the Challenge and Enter the Sweepstakes

Learning is the real reward, but there's an added incentive. Participants who complete the Microsoft Defender Challenge and submit the official sweepstakes entry form by August 21, 2026 will have the opportunity to win one of 500 certification exam vouchers worth 50% off one of the following Microsoft Certifications:

SC-200: Microsoft Security Operations Analyst

SC-500: Microsoft Cloud and AI Security Engineer

How to Enter

Complete the Microsoft Defender Challenge on Microsoft Learn.

Before the entry period closes, submit the official sweepstakes entry form.

If selected, you'll receive instructions for redeeming your certification discount voucher.

Challenge window: July 20 – August 21, 2026. Sweepstakes entry deadline: August 21, 2026 at 11:59 PM UTC.

No purchase necessary. See official rules for eligibility and sweepstakes details.

Join Learn Live: Remediating Threats Using Microsoft Defender

Want a guided walkthrough of the skills featured in the challenge? Join a live, interactive event where you can learn directly from Microsoft experts, ask questions in real time, and explore security operations scenarios together. Save your spot for our August Learn Live session.

Date: Wednesday, August 19, 2026 | Time: 12:00 PM PT / 3:00 PM ET

You'll be guided by Scott Landry, Microsoft Security Customer Experience Engineering, as you explore practical approaches to investigating security incidents, managing and remediating threats across the Microsoft Defender ecosystem, automating investigations and response actions, strengthening security operations processes, and applying Microsoft Defender capabilities to real-world scenarios.

Start Building Your Skills Today

Ready to level up? Sign up today to take the Microsoft Defender Challenge, then join us for the Learn Live session on August 19. Your skilling journey doesn't end here—keep learning, keep growing, and keep building beyond August at the Security Hub on Microsoft Learn.

Prioritize exposure resolution with a new dashboard experience (public preview)

liorarviv — Mon, 27 Jul 2026 13:30:43 GMT

Cut Through the Noise and Focus on What Matters Most

Security teams face a constant challenge: too many findings, too many dashboards, and not enough clarity on where to act first.

Organizations today are managing vulnerabilities, internet-facing assets, misconfigurations, code weaknesses, exposed secrets and more across an increasingly complex environment. While each signal is valuable on its own, security teams often spend significant time switching between tools and reports to determine where risk is concentrated and what actions will have the greatest impact.

Today, we're excited to announce the public preview of the redesigned Exposure Management dashboard, helping analysts to quickly identify the risks that matter most, act with confidence, and follow a clear path toward zero critical issues.

From Visibility to Action

Exposure management is most effective when it helps security teams move beyond visibility and into remediation. Every insight is designed to support decision-making and accelerate remediation.

The redesigned dashboard consolidates critical signals across:

Validated internet-exposed assets
Business critical assets
Vulnerabilities
Security misconfigurations

The dashboard prioritizes findings based on risk and directly connects them to remediation workflows. Security analysts can immediately understand:

Where exposure is highest
Which risks require immediate attention
What actions will reduce risk fastest

Resolve Risk Faster with Resolve Now

At the center of the new experience is Resolve Now, a focused set of prioritized recommendations designed to help reduce exposure on internet-exposed and business-critical assets. Resolve Now organizes work into three action categories, with items within each category prioritized based on the remediation approach:

Patch: Identify software updates that address known vulnerabilities, with prioritization based on exploitability and internet exposure.
Mitigate: Address risks that cannot be immediately patched, including zero-day vulnerabilities, through compensating controls and mitigation guidance.
Fix: Reduce attack surface risk by addressing security misconfigurations and code weaknesses, particularly those affecting internet-exposed cloud assets.

This approach helps teams focus on meaningful risk reduction instead of chasing long lists of findings.

Understand Your External Attack Surface

Internet-exposed assets remain one of the most common paths attackers use to gain access to environments. The new dashboard provides a consolidated view of internet-facing resources across:

Cloud assets
Devices
Shadow resources

Security teams can quickly understand where exposure exists across the environment and prioritize remediation efforts based on risk.

Measure Progress Across Critical Security Domains

Exposure management isn't only about fixing today's risks. It's also about driving continuous improvement. The redesigned dashboard introduces visibility into security initiatives across five key domains:

Code
Endpoint
Cloud
Identity
SaaS apps

Domain initiative scores help organizations measure progress toward target security outcomes, identify gaps, and track improvements over time. Teams gain a clearer path toward reducing organizational exposure by combining tactical remediation with strategic posture improvement,

Get Started Today

The redesigned Exposure Management dashboard is now available in public preview through the Microsoft Defender portal. Navigate to: Exposure Management → Overview to explore the new experience and begin prioritizing risk across your environment.

Learn more about using the new dashboard here

How Nationwide stays ahead of attackers with Project Perception

julievanloef — Mon, 27 Jul 2026 12:30:00 GMT

Nationwide, the world’s largest building society, is among the first organizations to put Microsoft’s new agentic security system to work. Facing adversaries who now regularly weaponize AI, the society is using Project Perception’s coordinated multi-agent defense—red, blue, and green agents working alongside its analysts—to find and remediate threats faster, while its security experts stay firmly in command. Their team has already seen work that once took weeks compressed into hours.

Defending against AI-driven threats

Nationwide Building Society is a member-owned mutual serving 19 million members across the UK, and that responsibility is becoming increasingly complex as AI reshapes the threat landscape. Attackers can now scale campaigns faster and automate more of their operations. "AI is giving attackers a real advantage over defenders in terms of pace and scale," says David Boda, Chief Security and Resilience Officer.

For its security teams, the mission is clear: protect the customers who trust the organization with some of the most important aspects of their lives. "The things that matter most are protecting their money, protecting their livelihoods." says Tim Russell, Cybersecurity Director.

For Nationwide Building Society, keeping pace means human-led, agent-driven defense that helps its team act faster, together and stay ahead.

Coordinated multi-agent defense, built on Microsoft Security

Nationwide Building Society’s response is to get ahead of the change in the threat landscape—identifying potential risks faster and accelerating response across its environment. Building on Microsoft Defender, which its teams have run for years, the society adopted Project Perception to bring coordinated multi-agent defense into its existing operations. "This solution for multi-agent defense allows us to move to a more proactive way of working," says Boda.

The system puts specialized agents to work as a team. "Red agents are offensive cyber agents used to explore the vulnerabilities and the attack paths in our environment. Blue agents are the defensive agents and reflect the work that a security operation center analyst might do," Boda explains, while green agents remediate and harden—with people in command throughout. "The power of the solution is it brings those agents together to achieve a better cybersecurity posture."

For analysts, that coordination removes long-standing friction. "We're able to use agentic workflows to identify threats and then track them through into remediation, which previously we would've had to have engaged with a number of different tools to achieve," says Russell.

Human-led, agent-driven defense

The impact is already tangible. "My team came to me and said, look, we've just taken four weeks of threat intelligence analysis and collapsed that down into four hours—and for me, that was the moment that really brought this to life," Boda recalls. Just as important to Nationwide Building Society is what the technology does for its people. "This technology helps to amplify their skill sets, not to replace them," says Russell.

For Nationwide Building Society, the future is humans and agents working as one. "Agents can work twenty-four-seven, but as humans, we can't do that. So, by harnessing humans and agents operating together, we can achieve so much more collectively," says Boda. And the ambition reaches further than the society itself: "Being able to develop this solution together with Microsoft allows us not just to protect Nationwide Building Society, but also to protect wider society—and that feels really positive."

Does this Unity Catalog → Purview guidance make sense?

sashakorniakUK — Mon, 27 Jul 2026 08:25:08 GMT

I’ve been working through how Azure Databricks Unity Catalog metadata surfaces in Microsoft Purview after a scan, and I’ve created the attached visual to make the relationship easier to understand.

The principle I’m trying to communicate is simple:

Maintain Databricks-native technical metadata in Unity Catalog → scan supported metadata into Microsoft Purview → use Purview for the wider enterprise governance, discovery and business context.

The short guidance accompanying the visual would be:

In Azure Databricks:

Navigate to Catalog Explorer → Catalogue → Schema → Table/View. From here, maintain metadata such as table comments, column comments and Unity Catalog tags. Some comments can also be AI-generated as a starting point and reviewed before saving.

After the Microsoft Purview scan:

Find the corresponding Data Asset in Purview and review the surfaced metadata:

Table Comment → Data Asset → Description

Column Comment → Data Asset → Schema → Column Description

Table Tag → Data Asset → Properties → Tags

Column Tag → Data Asset → Schema → Tags

Column Name / Data Type → Data Asset → Schema

Table/View and Column Lineage → Data Asset → Lineage, subject to the relevant prerequisites.

The distinction I’m trying to reinforce is that this is not Purview vs Unity Catalog, and it is not about manually duplicating technical metadata.

Unity Catalog remains the Databricks-native governance and technical metadata layer, while Purview can consume supported metadata through scanning and place it into the wider enterprise governance context.

I’d be interested in feedback from people implementing Purview + Azure Databricks Unity Catalog:

Does the visual and navigation guidance make the relationship clear?

In particular, are the field mappings and terminology intuitive enough for Data Engineers, Data Stewards and Data Owners, or is there anything you would simplify, rename or clarify?

Microsoft Purview, Databricks Unity Catalog and Medallion Architecture

sashakorniakUK — Mon, 27 Jul 2026 08:14:09 GMT

Microsoft Purview, Databricks Unity Catalog and Medallion Architecture three different responsibilities, one governed data ecosystem.

I created this visual because these concepts are often mixed together.

🔵 Microsoft Purview = Enterprise Data Governance & Discovery

Purview provides the enterprise-wide governance layer across Databricks and other platforms — Governance Domains, Data Products, glossary, Critical Data Elements, ownership, stewardship, metadata, data quality and discovery.

🔴 Databricks Unity Catalog = Databricks Data & AI Governance + Access Control

Unity Catalog is not simply an access-management tool. It governs Databricks data and AI assets, including catalogs, schemas, tables, permissions, technical metadata, lineage, auditing and discovery.

🥉🥈🥇 Medallion = Data Engineering

Bronze → Silver → Gold describes how data is progressively refined.

It is not a governance hierarchy.

That distinction is important:

Governance Domains answer:

👉 Who owns and governs the data?

Bronze / Silver / Gold answer:

👉 What stage of engineering and refinement is the data in?

And Gold does not automatically equal Data Product.

My preferred enterprise model is therefore:

Purview → Enterprise Governance & Discovery

Unity Catalog → Databricks Governance & Access

Medallion → Data Engineering & Refinement

The goal isn't Purview vs Unity Catalog.

It is clearly defining which platform is authoritative for which responsibility and connecting the metadata and lineage into a coherent governance model.

The distinction between governance domains (who owns the data) and Medallion layers (what stage of refinement) is one that trips up many implementation teams. In practice, when Microsoft Fabric is the analytics platform, Purview becomes the authoritative governance layer across both Fabric OneLake and Databricks, with Unity Catalog handling Databricks-internal access. Connecting lineage metadata across both is what creates a truly coherent governance model.

Device Code Flow: The Gift That Keeps on Giving — To Attackers

akyamaza — Mon, 27 Jul 2026 00:46:16 GMT

Tags: Microsoft Entra ID, Conditional Access, Device Code Flow, OAuth, Azure Arc, Azure Migrate, Identity Security, Zero Trust

Introduction

Device Code Flow was built for a good reason: helping users sign in on devices that cannot easily show a browser or accept a password. Smart TVs, consoles, kiosks, command-line tools, and headless systems all benefit from that design.

But the same design that makes it convenient also creates a serious enterprise risk. Attackers can initiate the flow themselves, send the user a legitimate Microsoft sign-in URL and code, and receive valid tokens once the user completes authentication. No password theft. No fake login page. MFA may still succeed. From the identity platform’s point of view, the protocol worked exactly as designed.

This post explains how Device Code Flow works, how it is abused in real attacks, why some Azure workflows still depend on it, and how administrators can reduce risk without treating it as a recommended authentication pattern for Azure services and tools.

Allow Device Code Flow only for documented constrained scenarios. Everything else should move to Managed Identity, brokered interactive sign-in, or certificate-based Service Principal authentication.

Let’s start with the version of Device Code Flow most people have already used, even if they did not know its name.

You may have experienced this. At night, you’re in a hotel room after surviving back-to-back meetings, and you just want to relax and watch something mindless on Netflix.

You grab the remote and navigate to the Netflix app on the room’s smart TV.

Now you need to log in.

You stare at the on-screen keyboard. It’s one of those alphabetical grids — not even QWERTY, which would be bad enough — and your password is something like C0llH0rs3@tt3ry&! because you read the right security blogs and you take this stuff seriously. You’re going to be clicking that remote for the next 10 minutes, and almost certainly making at least two typos.

But then the TV does something clever. It shows you a short alphanumeric code — let’s say ABCD-1234 — and tells you: Go to netflix.com/activate on your phone or laptop, type in this code, and you’re done.

So you do. You grab your phone, navigate to the URL, enter the code, authenticate normally (biometrics, password, MFA, whatever your setup requires), and within seconds — without touching that remote again — the TV lights up with your profile.

This is defined in RFC 8628 — the OAuth 2.0 Device Authorization Grant, colloquially known as Device Code Flow.

What’s Actually Happening Under the Hood

Device Code Flow exists to solve a genuinely hard problem: some devices don’t have a practical way to run a full browser-based authentication experience. Smart TVs. Streaming sticks. Gaming consoles. IoT devices. CLI tools. Printers. The kind of hardware that has a network connection and a purpose, but whose input methods were clearly designed by someone who has never had to type an email address using a D-pad.

Here’s the flow:

The TV (the “device”) contacts the authorization server — in this case, the identity provider — and says, “Hey, I’d like to get an access token on behalf of a user, but I can’t do a full browser login. Help me out.”
The authorization server responds with two things: a device code (a long, opaque string used internally) and a user code (that short, human-readable ABCD-1234 you saw on screen). It also provides a verification URI — the URL you go to on your other device.
The TV starts polling. It repeatedly asks the authorization server, “Has the user authenticated yet? What about now? Now?” — at a defined interval, patiently waiting.
You, on your trusted device, navigate to the verification URI, enter the user code, and complete a full, normal authentication flow — browser, password, MFA, the works.
The authorization server connects the dots. It sees that the user code has been satisfied by an authenticated session, and the next time the TV polls, it gets back a shiny access token.
The TV is now logged in. You watch your show. Everyone is happy.

The authentication burden is shifted entirely to a device that can handle it — your phone, your laptop, something with a proper browser and a keyboard. The TV never sees your password. The TV never needs to. It just waits, politely, for the authorization server to say “yes, that user is who they say they are, and they consented to this.”

Device Code Flow solves a real usability problem. It lets a constrained device complete sign-in through a second device that has a proper browser and keyboard.

And it is being weaponized against your users right now.

But What Happens When You’re the TV?

Here’s where I need you to shift your mental model — because this is the pivot that makes Device Code Flow so dangerously exploitable.

In the legitimate hotel TV scenario, you initiated the flow. You sat down in front of the TV. You opened Netflix. You decided you wanted to authenticate. The device code appeared because you asked for it, and the verification URI was presented in context, on a screen in a room you were physically occupying.

Now imagine this instead:

You receive a Teams message, or an email, or a LinkedIn DM from someone claiming to be from IT, or a vendor, or a colleague. They say they need you to help verify something, or access a shared resource, or complete an onboarding step. They send you a URL and a code. They ask you to go to — and here’s the thing — a completely legitimate Microsoft URL, enter the code, and sign in.

The URL is real. The sign-in page is real. Your MFA prompt fires and you approve it, because you’re authenticating to a genuine Microsoft identity endpoint. Everything looks exactly like a normal authentication flow.

Except you didn’t initiate it. An attacker did.

The attacker has the same role as the TV in the legitimate scenario: it starts the device authorization request and waits for the authorization server to return tokens. When the victim completes the sign-in, those tokens go to the attacker-controlled session.

No malware. No credential theft. No password phishing. Your MFA fired and you approved it. From the identity provider’s perspective, everything went exactly according to spec.

You just authenticated someone else’s session. You were the TV.

Welcome to Device Code Phishing.

The Attackers Who Love Your TV (How Device Code Flow Was Weaponized)

Remember that elegant, user-friendly device code flow we just finished praising? Turns out, the same properties that make it perfect for your Xbox also make it a gift-wrapped attack vector for threat actors. The absence of a browser on the authenticating device. The deliberate separation of code generation from authentication. The real Microsoft sign-in page that victims visit. Every single one of these “features” is a weapon in the right — or rather, wrong — hands.

Let’s walk through exactly how this works, because the mechanics are genuinely diabolical in their simplicity.

The Anatomy of a Device Code Phish

Step one: The attacker initiates a device code flow. Not on some sketchy custom app — on a legitimate, trusted client application like Azure CLI, Microsoft Graph PowerShell, or even the Microsoft Teams client. They call the device authorization endpoint and receive back two things: a device_code (which stays server-side) and an user_code — that friendly eight-character alphanumeric string like FPQR7WXT.

Step two: The attacker packages that user code into a phishing lure. An email. A Teams message. A LinkedIn DM. The lure is engineered to look like a legitimate IT notification, an MFA re-enrollment prompt, a SharePoint access request — anything that provides plausible context for why the recipient should navigate to microsoft.com/devicelogin and type in a code.

Step three: The victim visits microsoft.com/devicelogin. This is the actual, legitimate Microsoft authentication endpoint. The victim enters the code, authenticates with their credentials, satisfies MFA, clicks Approve, and goes about their day feeling completely fine about what just happened.

Step four: The attacker’s polling loop — which has been calling the token endpoint at the interval returned by the authorization server since step one — suddenly gets a 200 OK response. It receives a fully formed OAuth access token and may also receive a refresh token, depending on the client, scopes, tenant policy, and session controls. The attacker now has authenticated access to whatever Microsoft 365 services that token covers. No credentials were stolen. The user-facing authentication step may appear to originate from the victim’s normal device and location, while later token use may show different infrastructure depending on how the attacker operates.

Microsoft Entra guidance treats Device Code Flow as a high-risk flow that should be blocked unless users have a documented need to sign in to shared or input-constrained devices.

Storm-2372: When Nation-States Discovered the Phish

This isn’t theoretical. A threat actor tracked as Storm-2372 operationalized device code phishing at scale against high-value targets.

The Storm-2372 campaign followed the playbook described above — crafting contextually relevant lures delivered via email and messaging platforms, directing targets to the legitimate Microsoft device code authentication page, and harvesting the resulting tokens. Once armed with valid access tokens, and in some cases refresh tokens, the actors conducted reconnaissance across Microsoft 365 environments, accessed email, Teams conversations, SharePoint documents, and pivoted laterally through organizational infrastructure. Refresh tokens are particularly valuable when issued because they can be used to obtain new access tokens, subject to token lifetime, tenant policy, Conditional Access, Continuous Access Evaluation, revocation, sign-in risk, and downstream access patterns.

AI in the Loop: Dynamic Code Generation and the 15-Minute Problem

Device code flow has a natural defense built in: the user code expires after fifteen minutes. For manual phishing operations, this creates operational pressure — the attacker needs the victim to act quickly. The campaign solved this problem elegantly and unsettlingly.

Using automation and AI-assisted tooling, the campaign deployed phishing pages capable of dynamic code generation. Rather than embedding a static user code in the phishing lure, the infrastructure generated fresh device codes on demand as victims interacted with the page. A victim who hesitated, navigated away, or took longer than expected to authenticate would receive a freshly generated, fully valid code — the fifteen-minute clock reset transparently in the background. The victim experienced a seamless interaction. The attacker maintained a continuously valid polling session.

The campaign also employed role-aligned phishing lures — AI-generated pretexts tailored to the apparent role or organization of the target. An IT administrator received a message consistent with a service health alert. A finance employee received something that looked like an approval workflow notification. This contextual alignment dramatically increased conversion rates and reduced the likelihood of targets pausing to question the request.

The result was compromise of organizational accounts at scale, with the automation layer removing the human operational bottleneck that had previously limited the throughput of device code phishing campaigns.

Device Code Flow is not a new problem, but the risk has changed. Automation now makes these attacks easier to run at scale, and Conditional Access policies that ignore the flow leave a clean path for token theft.

The Azure Reality: Security Guidance and Operational Constraints

The Microsoft Entra guidance is clear: organizations should get as close as possible to a unilateral block on Device Code Flow, allowing it only in well-documented and secured use cases. In practical terms, Microsoft does not recommend Device Code Flow as the standard authentication pattern for Azure services, administration, automation, or onboarding workflows.

The nuance is that some Azure tools still expose or require Device Code Flow in constrained situations: Server Core, Linux terminals, headless appliances, remote shells, and migration or onboarding workflows where a local browser is not available. That is a compatibility reality, not a security recommendation. The presence of a Device Code Flow path in a tool should be read as an exception mechanism, not as guidance to prefer it over Managed Identity, brokered interactive sign-in, or certificate-based Service Principal authentication.

This is the Azure reality. Security guidance pushes administrators to block or tightly restrict Device Code Flow; some product workflows still need it in edge cases. The operational answer is not to normalize Device Code Flow across Azure, but to document the few cases that truly require it and move everything else to stronger identity primitives.

Azure Arc-Enabled Servers: DCF in Constrained Onboarding Scenarios

Let’s start with azcmagent connect, the command you run to onboard a server to Azure Arc-enabled servers. This is a core hybrid infrastructure workflow — the kind of thing organizations run at scale across hundreds or thousands of servers.

The official CLI reference documentation notes that Device Code Flow is the authentication method for azcmagent connect on Windows Server Core editions and on Linux distributions.

The reasoning is understandable: Server Core has no browser. Linux servers in an automated pipeline may have no interactive session at all. The arc agent needs some way to authenticate a human operator (or a service) during the initial onboarding handshake, and Device Code Flow conveniently sidesteps the need for a graphical environment. But “understandable” and “consistent with your Conditional Access policy” are two very different things.

When a Conditional Access policy blocks the Device Code Flow grant type — which aligns with the recommended security posture for most tenants — infrastructure teams may see onboarding failures for Linux servers or Windows Server Core nodes unless they have planned an alternate authentication path. This creates a real operational tension between strong tenant-level controls and some constrained onboarding workflows.

Azure Migrate: Known Registration Constraints

Azure Migrate’s standard appliance-registration experience still depends on Device Code Flow. The appliance Configuration Manager requires an operator to copy a device code, open a browser-based Azure sign-in prompt, and authenticate with an Azure user account. As a result, a Conditional Access policy that blocks Device Code Flow for the registering user and relevant resources prevents the default registration path.

Azure Migrate documentation identifies Device Code Flow restrictions as a common sign-in challenge and states that disabling DCF can block appliance registration. This is notable because our Entra guidance also recommends blocking Device Code Flow wherever possible, except for well-documented and secured use cases.

The alternative is not simply a Conditional Access exclusion or an additional user permission. It is a separate, certificate-based authentication model: an organization preconfigures a Microsoft Entra application and service principal, grants that principal Contributor access to the Azure Migrate project’s resource group, installs a certificate on the appliance, and completes registration using the application identity rather than an interactive user sign-in.

This removes the user-context Device Code Flow dependency, but it does not remove the appliance-registration process itself. It also introduces operational overhead: the application is effectively dedicated to one appliance, its certificate must be protected and rotated, and the approach does not apply to the Azure Site Recovery replication appliance.

Azure CLI and PowerShell: When DCF Appears as a Fallback

The Azure CLI and Azure PowerShell modules are more nuanced cases because they support multiple authentication paths. Both tools prefer modern, platform-integrated authentication flows — browser-based interactive login, Integrated Windows Authentication, managed identity — when those options are available. The operative phrase is “when those options are available.”

In headless environments, restricted execution contexts, containerized build agents with no browser dependency, or remote SSH sessions on machines that are not domain-joined, the preferred authentication hierarchy can become harder to use. In those cases, Device Code Flow may appear as a fallback when stronger approaches are not available or have not yet been implemented.

For individual developers this may be a minor inconvenience. For enterprise teams running automated pipelines in tightly controlled environments, it can become a recurring source of breakage that traces back to the gap between DCF-blocking Conditional Access policies and workflows that still rely on DCF as an exception path.

The Real-World Fallout: Exception Requests and Operational Friction

Security-mature enterprises that implement tenant-level blocks on Device Code Flow can discover this tension through production failures. An infrastructure engineer attempts to onboard a batch of Azure Arc servers. The azcmagent connect command fails. A ticket is raised. The security team investigates. The root cause is identified: DCF is blocked, as intended, by policy.

Now the organization has a decision to make: create a tightly scoped policy exception for the onboarding workflow, pre-provision service principal credentials and reconfigure the process, or pause the rollout while the right risk decision is made. None of those options is free. Each has security, operational, and ownership implications.

This is where guidance, product behavior, and customer operations need clearer alignment. Until that alignment is complete, customers need a practical operating model: block DCF by default, document the constrained cases, and move repeatable workflows to stronger identity primitives wherever possible.

The Clean Path Forward — A Five-Tier Authentication Hierarchy

The Azure authentication model has a clear order of preference: use platform-managed identity where possible, use certificate-based service principals where you need external automation, and reserve Device Code Flow for cases where no stronger option is available.

Here’s a five-tier decision framework for authenticating to Azure — ordered from preferred and durable to “only if you absolutely must.” This is also the practical interpretation of the guidance: Device Code Flow may exist in the toolbox, but it should sit at the bottom of the toolbox, not on the workbench.

Tier 1: Managed Identity — The Gold Standard

If your workload runs inside Azure — a virtual machine, an App Service, a Function App, an AKS workload using Microsoft Entra Workload ID, or an Azure Arc-enabled server — use the platform identity model wherever possible. There is no serious debate here.

Managed Identity works by giving the Azure platform itself the responsibility of credential issuance and rotation. The workload requests a token from the Instance Metadata Service (IMDS) endpoint (http://169.254.169.254/metadata/identity/oauth2/token), and Azure handles everything behind the scenes: certificate lifecycle, token signing, rotation. You never see a secret. You never store a secret. There is no secret to leak, rotate, audit, or accidentally commit to a GitHub repository.

System-assigned Managed Identities are scoped to the lifecycle of the resource itself — they live and die with the VM or service. User-assigned Managed Identities give you reuse across multiple resources and more fine-grained RBAC control. For Azure Arc-connected machines, the Arc agent provisions a Managed Identity backed by a locally managed certificate in a protected directory, giving even on-premises and multi-cloud workloads access to this same zero-secret model.

The operational rule: if your code or process runs on a platform that supports Managed Identity, using anything else is a conscious downgrade that requires justification.

Tier 2: Service Principal with Certificate — The Right Tool for Scale

ManagedIdentity isn’t available for every scenario. If you’re building a CI/CD pipeline in GitHub Actions, running an onboarding script from an on-premises orchestration platform, or automating Azure Arc server registration at scale across thousands of machines, you need a Service Principal — and you should be using certificate-based authentication.

Here’s why certificates are usually stronger than secrets in the Service Principal world: certificates are easier to govern through a managed issuance and rotation process, and they avoid long-lived shared strings being copied across scripts, repositories, and build systems. Microsoft Entra Conditional Access for workload identities can also apply to selected service principals, subject to licensing and feature scope, with controls such as location-based restrictions and risk-based blocking. That is not the same policy surface as user Conditional Access, and managed identities are not covered by those workload identity policies.

For Azure Arc onboarding specifically, scope your Service Principal to the minimum viable role: Azure Connected Machine Onboarding. This built-in role grants exactly what the azcmagent connect process needs — nothing more. It cannot read your Key Vault secrets, enumerate your subscriptions, or touch your production workloads. Least privilege isn’t just a best practice checkbox here; it’s your blast radius control.

Certificates should be issued from a managed PKI, stored in protected certificate stores (never in flat files on shared drives), and rotated on a defined schedule. Integrate certificate lifecycle management with your existing PKI or use Azure Key Vault-backed certificates where possible.

Tier 3: Service Principal with Secret — The Acceptable Compromise

Sometimes certificates are genuinely impractical. Legacy tooling, third-party integrations, or constrained environments may force your hand toward client secrets. This tier isn’t forbidden — but it carries an explicit operational contract.

Client secrets must be treated with the same discipline as passwords: stored in secrets management systems (Azure Key Vault, HashiCorp Vault, your CI/CD platform’s native secrets store), never hard-coded, never logged, and rotated on a defined cadence. Microsoft Entra ID lets you set expiration periods — use them. Ninety-day rotation is a reasonable baseline; shorter is better for high-sensitivity workloads.

Client secrets remain bearer credentials. If a secret is copied, an attacker can use it until it expires or is revoked, subject to workload identity controls and any other enforcement points in the environment.

Tier 4: Interactive Browser / Brokered Authentication — For Human Admins

When a human being is sitting at a keyboard performing administrative tasks — deploying resources, running az CLI commands, executing PowerShell modules against Azure Resource Manager — the right authentication pattern is interactive browser or brokered authentication.

The Azure CLI (az login), Azure PowerShell (Connect-AzAccount), and the Azure Portal all support this flow. On modern Windows workstations with the Web Account Manager (WAM) broker enabled, authentication is handled through the broker, which integrates directly with Windows Hello, device compliance state, and Primary Refresh Token (PRT) infrastructure. This means your Conditional Access policies — require compliant device, require MFA, require specific named locations — all apply and are enforced at login time.

This is authentication that knows who the user is, what device they’re on, and whether that device meets your security baseline. It’s the complete picture. Never suppress this flow with automation flags when a human is the actor.

Tier 5: Device Code Flow — The Last Resort

Device code flow (az login --use-device-code, Connect-AzAccount -UseDeviceAuthentication) should be treated as the last resort for Azure services and tools. It exists for a specific, narrow set of scenarios: headless Linux terminals, Windows Server Core deployments without a GUI, SSH sessions into remote systems where a browser genuinely cannot be launched, or constrained appliance and migration workflows where the product has no stronger supported option yet.

In these cases, the operator signs in on a separate device and the initiating workload receives the token after authorization completes. That separation creates a control gap: Conditional Access evaluates the sign-in context of the device used for authentication, not necessarily the posture of the headless server, appliance, or remote shell that initiated the request.

If you permit device code flow in your environment, do it deliberately: create a scoped Conditional Access exception, document the justification, and treat each use as a compliance event worth auditing. And ask yourself seriously whether Managed Identity or a Service Principal could solve the problem instead.

Put plainly: if a workflow can use Managed Identity, brokered interactive authentication, or a certificate-based Service Principal, that is the route Microsoft customers should prefer. Device Code Flow is the exception path for constrained environments, not the recommended operating model for Azure.

Quick Decision Table

When in doubt, consult this table before typing a single auth flag:

Scenario	Recommended Pattern	Avoid
Azure VM / App Service	System-assigned or user-assigned Managed Identity	Service Principal with secret; Device Code Flow
Azure Arc server process	Managed Identity via the Azure Arc agent identity model	Interactive login; hardcoded credentials
Azure Arc onboarding at scale	Service Principal with certificate and the `Azure Connected Machine Onboarding` role	Service Principal with secret; Global Administrator credentials
Azure Migrate registration	Preconfigured Microsoft Entra application with certificate-based authentication	Device Code Flow as the default path; over-privileged roles
Human admin task	Interactive browser or WAM brokered authentication with Conditional Access	Shared service accounts; suppressed MFA
Linux / Server Core / headless CLI	Managed Identity where available, or Device Code Flow with a scoped Conditional Access exception	Persistent CLI sessions with cached tokens and no expiry

The hierarchy is deliberate. Every tier down represents a trade-off — more operational burden, less platform-enforced security, more human discipline required to compensate. The goal is to push as many of your workloads as possible to Tier 1, use Tier 2 for what Managed Identity can’t reach, and treat everything below that as a documented exception rather than a default pattern.

Authentication choices are architectural decisions. Make them intentionally.

Hardening Your Tenant — What Administrators Must Do Today (And Why Your Cloud Is Not a Hotel TV)

The hardening work starts with visibility. Before blocking or allowing Device Code Flow, administrators need to know where it is already being used, which workflows depend on it, and which of those workflows can move to stronger authentication.

Action 1: Inventory Current Usage — Find Where DCF Is Active Right Now

You cannot harden what you cannot see. Start in Entra ID Sign-In Logs and filter for authentication protocol equals deviceCode. This will surface every user, application, and IP address currently relying on Device Code Flow across your tenant. Pay close attention to service accounts, unattended scripts, and any sign-ins originating from datacenter IP ranges — those are your highest-risk signals.

If you haven’t already, flip your Conditional Access policies targeting DCF clients into report-only mode first. This gives you a real-world blast radius assessment before you enforce a block. Surprises in production are exciting exactly once.

Action 2: Classify Every Use Case — Automation or Genuine Terminal Fallback?

Not every Device Code Flow invocation is malicious, or even wrong. Walk through what you find in the logs and ask one honest question for each entry: Is this a human logging into a device with no keyboard, or is this a script pretending it has no other option?

Genuine headless terminal scenarios — a shared kiosk, a network appliance with a PIN pad, a restricted industrial device — are legitimate. Everything else, especially recurring automated sign-ins from servers or pipelines, is a Service Principal waiting to be born.

Action 3: Replace Repeatable Workflows With the Right Identity Primitive

This is the most impactful action on the list. Every server onboarding script, appliance registration routine, and CI/CD pipeline that currently uses Device Code Flow should be migrated to one of two things:

Managed Identities — for anything running inside Azure. Zero credentials. No rotation. No excuses.
Certificate-based Service Principals — for workloads running outside Azure where Managed Identity isn’t available. Certificates are auditable, rotatable, and are not susceptible to this specific device-code phishing pattern.

If a team finds that migration difficult, treat it as an implementation gap to close, not as a reason to keep a weaker authentication pattern in place.

Action 4: Scoped Exceptions Only — No Tenant-Wide Free Passes

If you must allow Device Code Flow for a specific use case after completing Actions 1 through 3, then scope it surgically. Target specific named users, restrict to compliant or named network locations, and limit to the exact application that requires it. Attach strict sign-in monitoring alerts so that any deviation from the expected pattern pages someone immediately.

Granting tenant-wide exceptions because one team has a legacy appliance is the organizational equivalent of leaving the front door of your office building unlocked because the mailroom needs early access. Scope it. Monitor it. Review it quarterly.

Action 5: Improve Error Clarity — Make Failures Actionable

When Device Code Flow is blocked by a Conditional Access policy, the error experience can be difficult for operators to act on. If the message is opaque, teams either open a ticket without enough context or look for a workaround. Neither outcome helps the customer.

Internal scripts and tooling should catch Conditional Access block errors and surface clear, prescriptive guidance. Suggested runtime error wording:

“Device Code Flow authentication was blocked by your organization’s security policy. This workflow requires an identity with delegated permissions in an interactive session. For automated workloads, use a Managed Identity or a Service Principal with certificate-based authentication. Contact your identity platform team for migration assistance.”

For product and documentation improvements, language like the following would help customers make safer choices:

“Device Code Flow (RFC 8628) is designed for input-constrained devices such as smart TVs and kiosks. It is not recommended for automated scripts, CI/CD pipelines, or server-side processes. For unattended authentication scenarios, use Managed Identities for Azure-hosted workloads or certificate-based Service Principals for external workloads. Enabling Device Code Flow in enterprise environments without Conditional Access restrictions significantly increases phishing risk.”

Clear documentation prevents the next engineer from making the same mistake and helps customers choose the right authentication pattern earlier.

The Hotel TV — A Final Word

Let’s go back to where we started: you, in a hotel room, staring at a television that doesn’t have a keyboard, trying to log into Netflix. You pull out your phone, navigate to a short URL, type an eight-character code, and thirty seconds later you’re watching something you’ll regret staying up for. It is, genuinely, a delightful piece of user experience engineering. RFC 8628 solved a real problem elegantly, and for that use case — a constrained device, a human present in the room, a low-stakes personal account — Device Code Flow is perfectly appropriate.

The problem is not Device Code Flow. The problem is transplanting a mechanism designed for hotel televisions into environments where a compromised token can exfiltrate production databases, pivot across subscriptions, and trigger regulatory breach notifications at three in the morning.

Your enterprise Azure tenant is not a hotel TV. The stakes are not whether someone watches an extra episode before sleep. The stakes are your customers’ data, your company’s reputation, and in regulated industries, your legal exposure. Authentication mechanisms must be matched to the environment they protect — and an environment with that much at risk deserves better than a flow designed for leisure viewing.

Block Device Code Flow by default. Do not recommend it as the normal way to use Azure services or tools. Migrate automation to proper identity primitives. Grant exceptions only where the use case genuinely demands it, and monitor them relentlessly. The elegance of the original protocol is not a reason to leave the door open. It is simply a reason to appreciate it on the television where it belongs — while you protect everything else with something far more serious.

Windows Forwarded Events connector with Windows Security Events NRT rules

enescalban — Sun, 26 Jul 2026 00:07:11 GMT

Hello,

We are testing Microsoft Sentinel using the official Windows Forwarded Events connector.

Environment

- Windows Server WEC

- Windows Event Forwarding

- Azure Arc

- Azure Monitor Agent

- Windows Forwarded Events connector

Everything works correctly.

Forwarded security events are successfully ingested into the WindowsEvent table.

For example:

- Event ID 1102

- Event ID 4732

However, the built-in Windows Security Events NRT Analytics Rules (Content Hub version 1.0.1) query only the SecurityEvent table.

Example:

NRT Security Event log cleared

SecurityEvent

| where EventID == 1102

As a result, forwarded events received through the Windows Forwarded Events connector never trigger these NRT rules.

Question:

Is this expected behavior?

Should Windows Forwarded Events customers use a different set of analytics rules (ASIM or other templates), or should these built-in NRT rules also support WindowsEvent?

Thank you.

What's New in Microsoft Entra: July 2026

Martin_Coetzer — Fri, 24 Jul 2026 17:47:47 GMT

Welcome to the July edition of our monthly newsletter, summarizing the latest news and developments in the exciting, ever-evolving world of Microsoft Entra.

What went into General Availability (GA) since June 2026?

Microsoft Entra Backup and Recovery - A capability that helps organizations restore a tenant after accidental or malicious changes. On by default, it automatically backs up critical directory objects, including users, groups, applications, Service Principals, managed identities, Conditional Access policies, named locations, agent IDs, and authentication and authorization policies, so admins can return to a known good state. The service takes daily backups of supported objects and retains them for 7 days with Microsoft Entra ID P1 or P2 licenses. Admins can view snapshots, compare changes, and run recovery jobs. This feature is a reliable safety net to minimize downtime and strengthen protection against misconfigurations and security incidents.

Direct admin assignment to external users using email address - Entitlement management admins can assign external users, not in the directory, to an access package with the user's email. Users are invited into the tenant as Guest users and are governed when Microsoft Entra ID Governance is configured.

Bring your own device (BYOD) support for the Global Secure Access Windows client using Microsoft Entra‑registered devices - Enable users and partners to access corporate resources from their own devices. Administrators can assign the Private Application traffic profile to users with internal accounts, including internal guest users. This removes the previous requirement for Windows devices to be domain‑joined.

Microsoft Entra Kerberos key rotation - Improves reliability for environments by using incoming trust referral flows. The update enhances authentication resiliency during key rollover by validating referral tickets with primary and secondary Kerberos keys. This combination reduces the likelihood of authentication failures and minimizes disruption during rotation events.

Domainless SAML federation with a SAML identity provider - Enable external users to sign in to applications or workforce resources using their Identity Provider (IdP)-managed credentials, regardless of their email domain. With no need to match user email domains with preconfigured identity provider domains, this capability simplifies onboarding and access for external users, streamlines invitation redemption, and improves flexibility for cross-organization collaboration in Microsoft Entra.

New in Public Preview

Strengthen AI agent security with Conditional Access - Microsoft Entra Conditional Access has broader controls to secure AI agents that leverage user accounts. Administrators can target agent user accounts more precisely by including, or excluding, agents, or by using custom security attributes for dynamic grouping. Organizations can apply Conditional Access policies, based on agent risk, require compliant devices for agents running on managed endpoints, including Windows 365 for Agents, and enforce device, network, and platform-based access conditions. These enhancements extend Zero Trust protections to agent user accounts while using the familiar Conditional Access policy experience.

Restrict AD group changes to Microsoft Entra provisioning - Designate specific Active Directory (AD) groups so all modifications are managed through the Microsoft Entra provisioning service. This capability helps maintain consistency between Microsoft Entra ID and AD by ensuring group changes are centrally controlled. Reduce configuration drift and improve alignment across identity systems.

Generate unique aliases with custom call-outs - Use custom call-outs with Azure Logic Apps during user provisioning to perform advanced attribute transformations that meet your organization's requirements. Custom call-outs can generate values such as unique employee aliases and are supported for create events in HR inbound, SaaS outbound, and cross-tenant synchronization provisioning flows in Microsoft Entra.

Announcements

Jailbreak/root detection in Microsoft Authenticator - This feature strengthens security by preventing Microsoft Entra credentials from being added or used on jailbroken or rooted devices. Users move to compliant devices to continue using work or school accounts in Authenticator. It is secure by default, requires no admin configuration, and applies to iOS and Android. Personal and third-party accounts are not affected.

Starting August 2026, Microsoft Authenticator on iOS will offer an improved backup and restore experience - Users can back up account names securely by using iCloud and iCloud Keychain with end-to-end encryption. This experience includes work or school accounts, Microsoft personal accounts, and non-Microsoft accounts like Amazon or Google, also third-party time-based one-time password (TOTP). No other credentials are included in the backup. This update removes the need for a Microsoft personal account and simplifies device setup by automatically restoring account names on new iOS devices. Users manage the feature through iCloud settings

New guidance and information

SCIM APIs available in U.S. Government Cloud - Microsoft Entra SCIM 2.0 APIs, which went into GA, in the public cloud, earlier in 2026, are available in Microsoft U.S. Government Cloud. Organizations can use standards-based SCIM operations to provision and manage users and groups in Microsoft Entra ID from external SCIM-compatible identity sources. Enable scalable identity lifecycle management, while you reduce the need for custom integrations.

Tell us what you think!

If you have feedback on this newsletter, fill out the dedicated Microsoft Form.

Blogs

Check out the latest blog posts on our Microsoft Entra Blog and our Microsoft Entra Identity Developer Blog.

What's new in Microsoft Entra?

Learn what is new with Microsoft Entra, such as the latest release notes, known issues, bug fixes, deprecation functionality, and upcoming changes. You can find releases specific for Sovereign Clouds on a dedicated release notes page.

Become a certified Microsoft Identity and Access Administrator

Check out the certification and related training for the Microsoft Identity and Access Administrator available for customers and partners.

-Martin Coetzer

Principal Product Manager, Identity and Network Access, Customer Experience Engineering (CXE)

Microsoft Entra Community | LinkedIn

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

Data Product Lineage not automatic

davidfombella — Fri, 24 Jul 2026 09:29:46 GMT

Hi all i am new in Purview and I am trying to create a lineage with a Report--> Dataset--> Tables in Data Products however after adding report only dataset is shown, how can I view all tables of this dataset.

Only when I press open in fabric the Dataset the table list appears, how can I give permissions

RestrictedTrafficInstall.ps1 Fails on Windows 10 IoT Enterprise LTSC 2021 with SKU Detection Error

NiteshK — Fri, 24 Jul 2026 09:27:57 GMT

I am encountering an issue while deploying the Restricted Traffic Limited Functionality Baseline on a Windows 10 IoT Enterprise LTSC 2021 device and would like to confirm whether this OS edition is supported or if this is a known issue with the baseline script.

Operating System: Windows 10 IoT Enterprise LTSC 2021

EditionID: IoTEnterpriseS

DisplayVersion: 21H2

...\RestrictedTrafficInstall.ps1 : Could not get SKU of current running OS.

CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException

FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,RestrictedTrafficInstall.ps1

Modernize SAP Identity Management with Microsoft Entra

Mark_Wahl — Fri, 24 Jul 2026 17:54:07 GMT

Many organizations are rethinking how they manage identity across their SAP landscape as they move away from on-premises identity management systems and adopt a more unified cloud strategy. That shift often starts with a practical question: how do you connect SAP identity processes with the rest of your application estate without introducing more complexity?

That is where the ongoing work between Microsoft Entra and SAP can help. Over the past several years, we have continued to expand integration points that help organizations automate lifecycle changes, apply access policies more consistently, and strengthen governance across SAP and non-SAP applications.

If you are transitioning from SAP Identity Management (SAP IDM), modernizing an existing SAP identity architecture, or looking for better access governance across business-critical systems, the latest integrations in Microsoft Entra can help.

In this post, I’ll highlight what’s new, recap the key integration points, and explain how these capabilities can support your identity modernization journey.

What’s new in Microsoft Entra and SAP integrations

Over the past two years, Microsoft Entra and SAP have continued to deepen interoperability and support more deployment models. Key updates include:

More flexible provisioning patterns between Microsoft Entra and SAP Cloud Identity Services
Support for custom extension attributes on Microsoft Entra users for SAP-specific scenarios
Account discovery to identify accounts in SAP Cloud Identity Services that are not yet correlated with users in Microsoft Entra
OAuth 2.0 client credentials support to secure service-to-service communication between Microsoft Entra and SAP Cloud Identity Services
Integration between Microsoft Entra ID Governance and SAP Identity Access Governance (SAP Identity Access Governance), so organizations can request and govern SAP business roles alongside other access rights

Together, these capabilities help organizations create a more unified identity control plane across SAP and the rest of the enterprise.

“This partnership brings together the best of both worlds: Microsoft Entra’s identity-first foundation and SAP Access Governance’s (SAP Identity Access Governance and SAP Access Control) deep business and access risk context, enriched with AI to transform access governance into a continuous, intelligent trust model.”

Swetta Singh, Strategic Product Manager for Access Governance solutions, SAP

A centralized identity control plane for SAP and beyond

Microsoft Entra provides a centralized identity layer that integrates with SAP applications and platforms. With it, organizations can automate joiner, mover, and leaver processes, apply access policies more consistently, and strengthen governance across a broader set of systems.

That kind of consistency matters in complex environments. For example, Cenibra used Microsoft Entra ID Governance to modernize identity management across more than 80 systems, including SAP as a core platform. That approach helped reduce manual work, improve audit readiness, and create a more scalable foundation for managing access.

SAP Cloud Identity Services: More flexible provisioning

SAP Cloud Identity Services centralizes authentication and provisioning across SAP applications. It provides single sign-on and helps organizations provision users and groups more consistently to downstream SAP systems.

The latest integration improvements with Microsoft Entra give organizations more flexibility in synchronizing users and groups across both environments through standards-based approaches. This flexibility helps teams maintain consistent identity data between Microsoft Entra and SAP environments while using SAP Cloud Identity Services to distribute identities to downstream cloud-hosted and on-premises SAP applications.

Some of the recent updates include:

Custom extension attributes for SAP-specific scenarios

Many SAP environments depend on attributes tied to business processes, regions, or organizational structures. Microsoft Entra now supports provisioning custom extension attributes on users in those scenarios, making it easier to align identity data with the needs of SAP applications.

Account discovery for SAP Cloud Identity Services

Microsoft Entra account discovery retrieves accounts from SAP Cloud Identity Services so you can identify accounts that are not yet correlated with users in Microsoft Entra. This visibility can help teams reduce manual investigation and strengthen governance.

OAuth 2.0 client credentials for connector authentication

We have also updated connector authentication to use OAuth 2.0 client credentials. This change helps secure service-to-service communication between Microsoft Entra and SAP Cloud Identity Services and supports a more modern integration approach.

SAP Identity Access Governance integration

SAP Identity Access Governance is SAP’s cloud-based access governance solution. The integration between Microsoft Entra ID Governance and SAP Identity Access Governance connects SAP role governance to a broader access strategy, allowing users to request or receive SAP business roles through Microsoft Entra access packages alongside non-SAP access rights.

This integration matters because access governance often spans applications: employees, contractors, and partners may need coordinated access across SAP and non-SAP resources. Organizations can use the integration to manage those requests consistently across applications.

When a user requests assignment to an access package with an SAP business role through Microsoft Entra, the request is sent automatically to SAP Identity Access Governance. SAP Identity Access Governance then enforces approvals and additional checks within its own governance process. This approach helps organizations connect enterprise-wide access packages in Microsoft Entra with the business role and risk context available in SAP Identity Access Governance.

Microsoft Entra integrates with SAP Cloud Identity Services and SAP Identity Access Governance to support authentication, user provisioning, and identity governance across SAP applications.

Migration projects move faster with the right partner support

A successful transition from legacy IAM products such as SAP IDM often depends on practical experience across both SAP environments and enterprise identity platforms. Many organizations work with partners who can support SAP system integration, Microsoft Entra identity and governance capabilities, and identity strategies that connect SAP with the rest of the application estate.

If you are planning a migration and want to involve a partner, review the partner list in Migrate identity management scenarios from SAP IDM to Microsoft Entra.

Beyond identity: Microsoft Security for SAP

Identity establishes the foundation for securing SAP in your security environment. In addition to Microsoft Entra, Microsoft delivers SAP-aware capabilities aligned with the NIST Cybersecurity Framework:

Identify: Microsoft Purview discovers and classifies sensitive SAP data—including data mirrored into Microsoft Fabric through SAP Datasphere—helping organizations apply more consistent data security policies.
Protect: Microsoft Defender safeguards the endpoints, servers, and cloud resources surrounding SAP applications with continuous, adaptive controls.
Detect: Microsoft Sentinel connects SAP signals across your estate to detect incidents, with built-in analytics rules in an SAP-certified solution that cover known threats. Through strategic partnership with SAP, organizations can also incorporate security telemetry from SAP Enterprise Threat Detection (ETD) and SAP LogServ, providing broader visibility into SAP-specific threats and activities alongside the rest of the enterprise security estate.
Respond: Microsoft Security Copilot accelerates investigation and guides response, helping teams contain SAP incidents faster.

Together with the identity investments described above, these capabilities advance an identity-first Zero Trust strategy across the SAP environment. Microsoft uses these same capabilities across its global SAP estate.

Get started

If you are evaluating your SAP identity strategy, now is a good time to review how your current architecture maps to the latest integration options in Microsoft Entra.

Start with these resources:

As always, I would love to hear about your SAP identity modernization journey and the topics you would like us to cover next.

Thanks for reading,

Mark Wahl
Product Architect, Microsoft Entra
Mark Wahl | LinkedIn

Additional resources

Learn more about Microsoft Entra

Understanding Microsoft 365 Copilot Risk Surface and Mitigations

AtilGurcan — Thu, 23 Jul 2026 15:37:20 GMT

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.

Organizations beginning their Zero Trust journey can use the Zero Trust Workshop to assess their current posture, identify gaps, and better understand how existing permissions and governance impact Copilot readiness.

In this post, we take a broader look at the types of risks Copilot can amplify and how those risks align to key Zero Trust pillars.

Why Copilot changes the risk conversation

Before assessing specific risks, it's worth understanding why AI solutions like Copilot introduce a different risk conversation than traditional Microsoft 365 applications.

Most enterprise applications operate within a bounded context. A user opens a file, reads an email, or searches a SharePoint one item at a time. The time and effort required to manually locate, connect, and synthesize information across systems creates a natural friction layer.

While that friction was never designed as a formal security control, it did create a practical limit on how quickly users could surface and act on organizational data at scale.

Microsoft 365 Copilot removes much of that friction entirely. It operates at the speed of a prompt across the full scope of a user's access rights, synthesizing information from emails, files, meetings, chats, and other Microsoft 365 data sources into a single response.

The exposure is not the result of new permissions; it comes from how quickly and easily existing access can be discovered and aggregated. In short, Copilot makes data once hidden by volume discoverable by intent.

Use Zero Trust to assess Copilot risk

Zero Trust rests on three principles: verify explicitly, use least-privileged access, and assume breach. Rather than trusting users or devices by network location, it requires continuous validation of every user, endpoint, and request. This analysis focuses on the four pillars most directly involved in Copilot deployments.

Together, these pillars answer three questions: who can access Copilot; from which endpoints and applications; and what data Copilot can surface once access is granted.

The two-layer Copilot risk model

The foundation is simple: Copilot acts as a force multiplier for whatever access a user already has. If that access is governed well, Copilot improves productivity; if not, it amplifies exposure. Risk is therefore examined in two layers — access to the Copilot service itself, and access to the data Copilot can ground on and surface.

MICROSOFT 365 COPILOT · TWO-LAYER RISK MODEL

Layer-1 Access Risk
Identity	Device
Who can access copilot	From which devices
Under what conditions	Device compliance posture
Layer-2 Data & Governance Risk
Apps	Data
What copilot can access and surface	Sharing and permissions
Connected data sources	Labeling, classification, output context

Table-1: Two-layer model for Microsoft 365 Copilot risk

Risk Layer-1: Who can access Microsoft 365 Copilot?

The first layer of risk begins at the point of entry: the conditions that determine whether a user can access Copilot. Organizations don’t need to address every potential exposure point at once. Think of the following table as a map of where exposure can exist across identity and device controls. For details of how remediation works for this layer of risks; you may refer to the blog post: Mitigating Microsoft 365 Copilot access risk: Identity and device controls for Zero Trust.

The following risks are primarily governed by the Identity and Devices pillars of Zero Trust and define whether Copilot is being accessed by the right person, from a trusted device, under appropriate authentication and access conditions.

	Risk	Pillar	Description
R1	Unmanaged identity access	Identity	A compromised, shared, or former employee account can authenticate to Microsoft 365 and access Copilot. Because Copilot operates across the full scope of a user’s permissions, compromised accounts expose a much larger risk surface than before Copilot existed. Strong account hygiene and identity lifecycle management therefore directly reduce Copilot exposure.
R2	Weak or absent multi-factor authentication	Identity	If organizations do not enforce MFA, or if legacy authentication bypasses modern sign-in controls, users can start Copilot sessions using only a password. In environments with inconsistent MFA coverage, attackers may need only stolen credentials to gain access. Because Copilot synthesizes data across services, compromised accounts create significantly greater risk than access to a single application.
R3	Unmanaged or non-compliant devices	Devices	Users can access Copilot through browsers and native applications from any device where they can authenticate. Unmanaged devices without EDR coverage, disk encryption enforcement, or compliance posture evaluation can expose Copilot sessions and allow attackers or unauthorized users to store or exfiltrate outputs locally.
R4	License sprawl without role-based scoping	Identity & Apps	Enterprise Copilot pilots often start with broad license assignments across departments, floors, or business units instead of deliberate, security-reviewed pilot groups. When organizations assign licenses without reviewing each user’s access rights, permission posture, and role sensitivity, Copilot can amplify risk across both highly governed and minimally governed users. Broad pilot enrollment without access review is itself a risk factor.
R5	Missing real-time risk evaluation at sign-in	Identity & Devices	If Conditional Access does not evaluate sign-in and user risk signals—such as impossible travel, anomalous token activity, or identity protection alerts—high-risk sessions may still gain access to Copilot. Without real-time risk gating, controls respond only after access is granted, by which point Copilot may already have surfaced and synthesized sensitive content.
R6	App protection gap on mobile devices	Devices & Apps	Users can access Microsoft 365 Copilot mobile—and the broader Microsoft 365 mobile surface that exposes Copilot—from personal devices that are not enrolled in MDM or MAM. Without an application protection policy, organizations cannot prevent users from copying Copilot outputs into unmanaged apps, remotely wipe organizational data from lost devices, or restrict screenshots and screen recordings during Copilot sessions containing sensitive data.

Table - 2: Risks in Layer-1: Who can access Microsoft 365 Copilot

Key observations from Layer 1:

Identity appears most frequently across Layer 1 risks, reflecting how tightly Copilot access depends on authenticated user permissions and sign-in conditions. Device-related risks also play a major role because unmanaged or non-compliant endpoints can expose Copilot sessions and outputs beyond the organization’s trusted environment.

Together, these risks highlight a central theme: securing Copilot access is not just about controlling who can sign in, but also validating the devices, conditions, and access patterns associated with every session.

Risk layer 2: What data can Microsoft 365 Copilot reach?

The second layer of risk assumes that the user is already authenticated and actively using Copilot.

At this stage, the focus shifts from who can access Copilot to what data Copilot can surface on the user’s behalf.

These risks reflect the full scope of data exposure created by existing permissions, overshared content, connected systems, and governance gaps. Layer 2 risks are governed primarily by the Apps and Data pillar, with Identity playing a secondary role in defining the scope of data each user can access.

For mitigating risks in this layer, you may refer to the blog post: Limiting Microsoft 365 Copilot data exposure risk with Zero Trust apps and data controls.

	Risk	Pillar	Description
R7	Overshared SharePoint and OneDrive content	Apps & Identity	Content shared with "Everyone," "Everyone except external users," or broad groups becomes part of Copilot’s query able surface for any licensed user, even if that user would never have found those files manually. Years of SharePoint oversharing, combined with Copilot’s ability to traverse and synthesize content in a single prompt, can turn long-standing governance debt into immediate exposure. Copilot makes data once hidden by volume, discoverable by intent.
R8	Sensitivity label gaps	Apps & Data	Microsoft Purview sensitivity labels tell Copilot how to handle content, including whether it can summarize, cite, or include that content in responses. Leaving content unlabeled, mislabeling, or miss inheriting labels across containers such as SharePoint sites and Teams, Copilot treats the content as unclassified and may surface it freely. Many enterprise tenants still contain large volumes of unlabeled legacy content, and Copilot cannot infer classification on its own.
R9	Excessive user permissions	Identity & Apps	Like overshared content, Copilot follows each user’s existing Microsoft Graph permissions and does not surface content users cannot access. In many enterprise environments, however, users accumulate access far beyond their current role through leftover project permissions, broad temporary group memberships, and inherited rights from outdated organizational structures. Copilot does not create this overprovisioning, but it makes the full scope of that access immediately visible and usable.
R10	No DLP coverage on Copilot-generated outputs	Apps & Data	Copilot outputs—including summaries, drafts, and synthesized answers—are generated content, and traditional DLP policies do not always preserve links to original source data. Users may receive Copilot responses containing aggregated PII, financial data, or confidential project details and paste that information into emails, Teams messages, or external documents without triggering DLP policies designed to detect the original source files. As content shifts from source material to generated output, organizations often lose the underlying sensitivity context.
R11	Plugin and connector data surface expansion	Apps & Identity	Organizations can extend Microsoft 365 Copilot through plugins and Microsoft Graph connectors that pull external data from CRM systems, ITSM platforms, HR applications, and custom line-of-business tools. Each connector expands the data surface Copilot can query on a user’s behalf and often reaches into systems whose access control models do not align natively with Microsoft 365 permissions. As organizations add connectors, each connected source introduces governance and audit risk that expands alongside the broader Copilot data surface.
R12	Audit and visibility gap	Apps & Data	Organizations need visibility into what users asked Copilot, what data Copilot accessed, , and what responses it generated to maintain an effective security posture for both incident response and risk monitoring. Disabling Copilot interaction logging, retaining audit logs for too short a period, or failing to forward logs to a SIEM, obscures the organization’s visibility into how users interact with Copilot, whether Copilot surfaces unexpected content, and whether activity may indicate compromise. Without audit data, organizations cannot reliably detect misuse or investigate incidents.
R13	Privileged user data amplification	Identity, Apps & Data	Administrators, senior IT staff, and other privileged users often hold access that spans organizational boundaries, including mailboxes, site collections, security groups, and configuration data that most users never access. A compromised admin account with Copilot access gives adversaries an organization-wide view of data that far exceeds the exposure associated with a compromised end-user account. Organizations therefore need to apply the strictest Copilot access governance to privileged identities.

Table – 3: Layer-2 Risks: What data can Microsoft 365 Copilot reach?

Key observations from Layer 2:

Apps-related risks appear throughout Layer 2 because Microsoft 365 Copilot depends heavily on connected systems, accessible data sources, and governance over generated outputs. The Data pillar further emphasizes the need to protect not only sensitive source content but also AI-generated responses that aggregate and surface information across systems.

The table above maps each identified risk to its primary and secondary Zero Trust pillars. Primary pillars represent control areas that most directly govern a given risk, while secondary pillars represent contributing dimensions.

Conclusion & next steps

Copilot typically does not grant broader access than a user already has — it makes existing access easier to discover, connect, and use across Microsoft 365. Organizations that successfully scale Copilot are the ones that understand and govern that access first.

Reducing Copilot data exposure is not a one-time cleanup; it is a continuous governance posture. Oversharing accumulates, labels drift, permissions grow, and connectors are added. Together, the Layer 1 and Layer 2 controls in this guide create the feedback loops that keep the risk surface governed as the organization and its use of Copilot evolve — governing not only who can access the service, but what it can reach on their behalf.

WHERE TO GO NEXT

Assess your current posture: Zero Trust Workshop — http://zerotrust.microsoft.com
Understand the framework: Zero Trust Overview on Microsoft Learn (http://learn.microsoft.com/security/zero-trust)

Best practices: Open OneDrive/SharePoint sharing but restrict Teams guest access by domain

Bejhan — Fri, 24 Jul 2026 05:49:11 GMT

Hi all,

Since SharePoint Online and OneDrive moved fully to Microsoft Entra B2B for external sharing, we've run into a policy conflict and would like to hear how others are handling it.

Our requirements

Enable OneDrive and SharePoint file sharing with external users, regardless of their email domain.
Restrict Microsoft Teams guest access to a predefined list of approved partner domains.
Continue allowing Teams external access (federated chat and meetings) for all domains.

The problem:

Teams guests, SharePoint guests, and OneDrive guests are now governed by the same Microsoft Entra B2B invitation framework and the single Collaboration restrictions allow/deny list under:
External Identities → External collaboration settings
As a result, restricting guest invitations by domain also restricts OneDrive and SharePoint sharing for domains not on the allowlist.
According to Microsoft's response in the following Q&A, this behavior is currently by design: OneDrive external sharing no longer working with "Allow invitations only to the specified domains" - Microsoft Q&A

Questions to the community

Has anyone implemented a solution where OneDrive/SharePoint sharing remains open to all domains while Teams guest access is restricted to approved domains only?
Are there recommended approaches using Entitlement Management, Access Packages, Connected Organizations, or other Entra capabilities?
Is there any roadmap item for workload-specific collaboration restrictions (e.g., separate policies for Teams guest invitations and SharePoint/OneDrive sharing)?

Any real-world experience or best practices would be greatly appreciated.

Thanks,

Bejhan

Should You Use the New Microsoft Entra Tenant Governance or Azure Lighthouse? (part 3 of 3)

Preston_Romney — Thu, 23 Jul 2026 12:00:00 GMT

In Part 1 we built Azure Lighthouse the technical way. In Part 2, "Bring Your Partner In, Without Letting Their Identities In," we made the security case for it: let a service provider operate a customer's Azure resources without creating any identity in the customer's tenant.

This third part introduces another, newly available delegation model Microsoft Entra Tenant Governance and helps you to answer the question: which one do I use, and when?. If you already know Lighthouse, you have everything you need to follow along - If not, catch up on the previous two articles. While most of the focus will be on Microsoft Entra Tenant Governance, we will compare and contrast it with Azure Lighthouse.

There's one idea that makes the whole comparison click: the two models project access in opposite directions.

1. Azure Lighthouse, and its boundary

As a brief refresher, Azure Lighthouse lets a service provider manage a customer's Azure resources (subscriptions and resource groups) from the provider's own tenant. The provider's users never get an account in the customer's directory and never become guests there; instead, the customer's subscriptions and resource groups are delegated to the provider through Azure Resource Manager, and the provider operates them with their home credentials (Azure Lighthouse architecture). No identity sprawl, no extra license, no charge (Azure Lighthouse overview).

Lighthouse is scoped to the Azure Resource Manager control plane. It delegates resources from subscriptions or resource groups such as virtual machines, storage, networking, policy, and Sentinel workspaces. It does not grant Microsoft Entra directory roles, it does not reach resource data planes such as Storage blob data or Key Vault secrets, and it doesn't reach Microsoft 365 (cross-tenant management experience).

But it leaves a real question open. What happens when the partner (or an enterprise with multiple tenants) legitimately needs access to the directory, to read identity configuration, run security operations, administer users, or govern identities, and not just the resource estate? Lighthouse, by design, can't take you there. That's the gap the second model fills.

2. Two directions of projection

The easiest way to keep the two models straight is to consider the following:

Fig 1 - Access delegation direction of trust

Azure Lighthouse projects the customer's resources up into the provider's tenant. The provider manages those resources from its own context. The customer's subscription is, in effect, presented inside the provider's Azure portal.
Microsoft Entra Tenant Governance projects the provider's identity down into the customer's tenant. A principal from the provider tenant becomes usable inside the customer, and a provider user or service principal uses it there to do the work.

Each delegate cross-tenant access without local accounts, but the thing that moves is opposite. And who moves strongly shapes whose rules apply. When the customer's resources come up to the provider, the work happens in the provider's context. When the provider's identity goes down to the customer, the work happens in the customer's context.

Think of the word "projection" as a way to reason about trust direction, not a literal claim that objects are copied between tenants. Lighthouse is delegated management from the provider's context; Tenant Governance creates a governed principal in the customer's context that can hold directory roles and Azure RBAC.

3. What is Microsoft Entra Tenant Governance?

Microsoft Entra Tenant Governance is the capability that lets one tenant securely administer another. The connection between a specific pair of tenants is called a governance relationship: a directional link in which one tenant, the governing tenant (the provider), administers another, the governed tenant (the customer) (set up a governance relationship).

Throughout, this article is written from the provider's vantage point: when it says you, it means the provider (governing) side, and the other tenant is always referred to explicitly as the customer. The topics discussed here apply equally to Enterprises needing to manage many of their own tenants as well as Service Providers who manage many customer tenants.

You set it up in two steps:

A policy template in the provider tenant that declares which principal will be projected and which Entra roles it should receive. Note that RBAC assignments are not part of the governance relationship and must be completed by the customer in their tenant.
A handshake between the two tenants that establishes the trust boundary and provisions the access.

Now let’s dive into the details: what gets projected, and how it gets its powers.

4. What actually gets projected: one proxy principal

In the provider tenant you start with something completely ordinary, a security group (say, your "Cloud Operators" group), or a custom multitenant application. When you form the governance relationship, a proxy of that principal is created in the customer tenant:

A security group is projected in as a remote tenant group.
An application (a custom multitenant app) is projected in as a service principal, when the relationship is established, Tenant Governance automatically creates a service principal with the same permissions in the customer tenant (no manual step on the customer's side): "Tenant Governance creates a service principal with the same permissions in the governed tenant" (governance policy templates).

Using a multitenant app registration with Tenant Governance requires an Entra ID Governance license.

Fig 2 - Provider principal is projected into the customer tenant

It’s important to keep two things straight, neither is a local account or a guest:

The proxy, the remote tenant group (or, for an app, the service principal), is a new principal created in the customer tenant by the relationship. It is not a copy of the provider's group, not a local group created in the customer, and not a guest. It exists only because the relationship projects it, and it is what the provider grants roles to.
The people and apps that use it, the provider's users and service principals, stay in the provider tenant. They never receive a member account or a guest invitation in the customer; they reach the customer through the proxy.

Here is what that provider user or service principal is and isn't, from the customer's point of view:

The provider user or service principal is NOT…	…it IS…
A local member account created in the customer's directory	An identity that stays in the provider tenant and authenticates with provider credentials
A B2B guest invited into the customer	Reachable only through the projected proxy, a signed-in user shows in the customer's logs as the provider tenant's name + Technician (e.g. Contoso Technician)
A standing, permanent object listed among the customer's users	Present only as a governed session or principal, scoped by the relationship and revocable by the customer

To work in the customer tenant, a provider user opens a supported admin portal (Entra or Azure) and appends the customer's tenant ID, for example https://entra.microsoft.com/{customer-tenant-id}, then signs in with their provider-tenant credentials. The customer's logs then show them a directory display name of user_{object-id} (the provider object ID without dashes), and, in sign-in and audit logs, the provider tenant's name followed by Technician, so for a provider tenant named Contoso the entry reads Contoso Technician (use cross-tenant delegated administration). No local account, no guest object, the resource-plane property Lighthouse provides, now on the directory plane (cross-tenant delegated administration).

A note on the two projection mechanics, because they differ in a way worth understanding. A group projects as a remote tenant group, a cross-tenant reference back to the provider's group, with no new local membership stored in the customer. An application projects as a real service principal that is actually created in the customer with the consented permissions. Same idea, a governed proxy of a provider principal, but a group is a reference, while an app is an instantiated object.

5. How the proxy gets its powers: roles attach to the one principal

The proxy is one principal. You don't create separate identities for "directory access" and "resource access." Instead, you grant roles to that single proxy, and the roles can come from two different planes:

Directory roles govern the customer's Microsoft Entra directory. Think of well-known ones such as Global Reader (read-only across the directory), Global Administrator, or User Administrator, selected as built-in roles in the policy template (governance policy templates).
Azure RBAC roles govern the customer's Azure resources. Think of the familiar Reader, Contributor, or a service-specific roles like Virtual Machine Contributor, assigned to the remote tenant group at a subscription or resource-group scope. This is not done as part of the governance relationship as the Entra directory role is. This must be assigned after the relationship is established likely by a privileged customer admin.

The bridge from directory to resources is the remote tenant group itself: because the projected group can be referenced by Azure RBAC, the same proxy that holds Global Reader in the directory can also hold Reader or Contributor on a resource group. Critically, these are not separate identities, they are both roles held by the one remote tenant group, as the diagram above shows. And the directory role grants no Azure access on its own; the resource rights come entirely from the explicit RBAC assignment you choose.

That single design choice, roles branch off one proxy, is what lets one projected principal span both planes: the same remote tenant group can hold a directory role and a separate, explicit Azure RBAC grant, without ever issuing a local account.

What do these identities actually look like in the customer tenant? The only place you will see the security group is in the governance relationship. You will not find it among your other Entra groups.

Fig 3 - Governance relationship shows the projected principal in the customer tenant

Fig 4 - The projected principal does not appear in the customer tenant security groups

For RBAC purposes, you can find the proxy security group under resource Access Control (IAM) as a foreign group.

Fig 5 - The projected principal is available for RBAC assignments as a foreign group

6. The building blocks, and how they depend on each other

Now that the concept is in place, here's the assembly order. Each block depends on the one before it.

Fig 6 - Sequence of creating a governance relationship

A role-assignable security group in the provider tenant, the principal you intend to project.
A policy template that selects which directory roles that group should receive when projected (governance policy templates).
A governance relationship, established by a handshake. In the standard three-step flow the customer invites, the provider requests (carrying the template), and the customer accepts; a streamlined two-step flow (request → accept) applies when the two tenants already share a qualifying signal, such as a billing relationship or an existing governance relationship. At acceptance, the role assignments are provisioned in the customer (set up a governance relationship). The template's role set is projected onto the relationship, so later template edits require a fresh request and re-approval, the customer always gets to review what changes.
The projected proxy plus its role assignments in the customer, the remote tenant group (or service principal), now holding the directory and/or Azure RBAC roles you granted.

Under the hood: this cross-tenant delegation is powered by granular delegated admin privileges (GDAP), the same delegation technology behind Partner Center (cross-tenant delegated administration). You don't configure it directly; the relationship and the template do it for you. That's all you need to know about the plumbing.

The whole flow is also scriptable through the Microsoft Graph Tenant Governance APIs (API overview), and a default template can bring new add-on tenants under governance automatically at creation (deployment guide).

7. Key Features

Because the proxy can hold both directory roles and Azure RBAC, Tenant Governance unlocks delegated administration across the entire surface a partner might legitimately need:

Directory administration, read or manage the customer's Microsoft Entra directory with least-privileged built-in roles, using home credentials, no local accounts.
Identity governance, run access reviews, entitlement management, and lifecycle workflows across many customer tenants from one place.
Security operations, operate security and compliance tooling centrally. Microsoft Defender XDR and Microsoft Sentinel multitenant management for MSSPs is one prominent example built on this model (governance relationships for unified SecOps).
Azure resource management, the remote tenant group can carry Azure RBAC for any Azure service, exactly the way a local group would. That covers the management (control) plane only; neither model delegates the resource data plane (for example, blob data or Key Vault secrets), so those operations still require an identity native to the customer tenant.
Application management, project a custom multitenant app as a service principal with consistent, least-privileged permissions across tenants (governance policy templates).

The provider's users and service principals use their provider-tenant identities, and no local or B2B account is ever planted in the customer. The one object the customer does gain is in the application case, a governed service principal of the projected app, created and maintained through the relationship rather than as a standing local login.

8. Comparing Tenant Governance with Azure Lighthouse

Now that both models are understood, the comparison is straightforward. They operate on different planes and point in different directions.

Dimension	Azure Lighthouse	Microsoft Entra Tenant Governance
Direction of projection	Customer resources → provider	Provider identity → customer
Where the provider identity operates	From the provider tenant (customer resources projected up; no customer sign-in)	In the customer tenant, authenticated by the provider home tenant — as {Provider} Technician
Planes reached	Azure resource (ARM) plane only	*Directory plane and* Azure resource plane**
Data-plane access (e.g., blob data, Key Vault secrets)	Not supported (control/ARM plane only)	Not supported (the proxy can hold a DataActions role, but cannot obtain a data-plane token)
Identity footprint in customer	None	A projected proxy principal, no local or guest object
Conditional Access	Only the provider's policies apply (security practices)	The customer's policies apply, the customer is the resource tenant for the technician's sign-in (lab-verified; see below)
Where the privileged assignment lives	Provider tenant (JIT approvers in the provider) (eligible authorizations)	Customer tenant (the role assignment is owned customer-side)
Audit of provider actions	Customer Activity Log (view activity)	Customer audit log records the provider user’s actions; the authentication sign-in is recorded provider-side, it appears in the customer's sign-in log only when the customer's CA fires
Role types	Azure built-in roles only, no custom roles; Owner and roles with DataActions excluded, and Microsoft.Authorization/* writes excluded except User Access Administrator for managed-identity assignments (role rules)	Directory roles and Azure RBAC (including custom RBAC) on the proxy
Setup	ARM template / Marketplace offer (onboard)	Relationship handshake (invitation → request → acceptance)
Revocation	Remove the delegation, either party (remove)	Terminate the relationship, either party
Operational view	Single pane of glass, every delegated customer's resources surface in the provider's own portal	Per-customer, the admin signs in to each customer tenant individually
Best for	Scaled Azure resource operations	Directory / identity / security delegation plus resources

The sign-in, Conditional Access, footprint, and audit rows describe the human delegated-administration path (a projected group). In the application case the customer instead gets a governed service principal, so those rows read differently.

Direction of projection, the root cause. Everything else in the table is a consequence of this one row. Lighthouse brings the customer's resources up to the provider; Tenant Governance places a governed proxy of the provider's identity down in the customer. Decide which direction your scenario actually needs, and the rest mostly answers itself.
Conditional Access, the cleanest inverse. With Lighthouse, provider users authenticate in their own tenant, so the customer's Conditional Access never reaches them, "Only policies set on the managing tenant apply"(recommended security practices). With Tenant Governance the provider actually signs in to the customer tenant (use cross-tenant delegated administration), which makes the customer the resource tenant that evaluates Conditional Access, so the customer's policies govern the inbound provider login, not the provider's policies.

Two nuances to keep in mind: When the provider logs into the customer tenant, the authentication still happens with the provider’s tenant, but the conditional access policy applied to the login is in the customer tenant.

Where privileged access lives. Lighthouse offers just-in-time elevation through eligible authorizations, and the approvers sit in the provider (managing) tenant, "up to 10 users or user groups in the managing tenant who can approve"(create eligible authorizations). Tenant Governance inverts the ownership: the proxy's role assignment lives in the customer tenant, so privileged-access governance over that assignment is anchored customer-side. The useful contrast is simply where the assignment lives and who governs it, provider-side for Lighthouse, customer-side for Tenant Governance.
Audit and identity footprint. With Lighthouse, provider actions land in the customer's Azure Activity Log under a named user, with no customer sign-in and no directory object (view provider activity). Tenant Governance is more subtle. The provider user's authentication is handled and logged in the provider (home) tenant, so the bare sign-in appears there, not in the customer tenant. What does get logged in the customer directory is the provider user’s actions, in its audit log, where the actor shows as the <provider tenant's name + Technician> (e.g. Contoso Technician) (use cross-tenant delegated administration). A sign-in entry from the provider user only appears in the customer's logs when the customer's Conditional Access evaluates the session, for example, an MFA challenge. Without such a policy, that sign-in is only logged on the provider side. Either way, the customer keeps a full audit of what the technician does and gains no standing local or guest object (cross-tenant delegated administration).

Fig 7 - The providers activities on resources are logged in the customer's subscription activity log as "<provider name> Technician"

Fig 8 - When the provider logs into the customer tenant, their authentication is logged against the provider tenant while Conditional Access is logged against the customer tenant

One console vs. many: Operational reach. Because Lighthouse projects the customer's resources up, the provider works from a single pane of glass, every delegated customer's subscriptions appear in the provider's own Azure portal, and cross-tenant tooling, Azure Resource Graph, Microsoft Sentinel, Azure Policy, Azure Monitor, can span all of them at once. Tenant Governance points the other way: the provider's identity projects down into each customer, so day-to-day administration is per-customer, the admin signs in to each customer tenant in turn. (Service consoles such as Microsoft Defender XDR add their own aggregated multitenant views on top, but the underlying delegated-admin model is per-tenant.) When operating many customers' Azure estates from one console is the priority, that single-pane reach is a distinct Lighthouse strength.

9. Where the two models overlap

As is the case with other delegated access models, there is clear overlap between Azure Lighthouse and Tenant Governance:

Both eliminate local and B2B accounts in the customer. The partner's people stay in the provider tenant either way (Lighthouse architecture, cross-tenant delegated administration).
Both can ultimately place Azure RBAC on customer resources, Lighthouse directly through the delegation, Tenant Governance via the remote tenant group.
Both are limited to the control (management) plane, neither delegates resource data-plane access (for example, blob data or Key Vault secrets); that still requires an identity native to the customer tenant.
Both keep the customer in control of the audit record, provider actions are written to the customer's logs.
Both are revocable by either party, remove the delegation, or terminate the relationship.

10. What is complimentary with the two models?

Because they sit on different planes and point in opposite directions, you can use one or both.

Fig 9 - Azure Lighthouse and Entra Tenant Governance compared

Deciding between the two delegated access models:

Need only to operate the customer's Azure resources, especially across many customers? Choose Azure Lighthouse, no extra license or charge, a broad set of Azure built-in roles (Owner and custom roles excluded), just-in-time elevation with provider-side approval, zero directory footprint, and a single pane of glass: because customer resources project up into the provider's tenant, the provider manages every customer's estate from their own portal, with cross-tenant tooling spanning all of them at once.
Need directory, identity, or security reach, not just resources? Choose Microsoft Entra Tenant Governance, directory roles and Azure RBAC on one projected principal, with the customer's own sign-in controls in the loop. Because the provider's identity projects down into each customer, administration is per-customer: the admin signs in to each customer tenant in turn rather than from one aggregated console.
Need both on the same tenant? Use both. They coexist because they operate on different planes, Lighthouse for the resource estate, Tenant Governance for directory and security.

11. Key points to remember about Entra Tenant Governance

Least privilege. A directory role grants no Azure access, and an Azure RBAC role grants no directory access. Each plane is an explicit grant to the proxy, start with read-only (e.g., Global Reader in the directory, Reader on resources) and add only what's needed.
Directory ≠ resource. The two planes are independent. If the partner needs to operate Azure resources, that comes from an explicit RBAC assignment on the remote tenant group, not from any directory role. That RBAC is control-plane only; neither Tenant Governance nor Lighthouse delegates the resource data plane (for example, blob data or Key Vault secrets), which still requires an identity native to the customer tenant.
Tenant discovery is irreversible. Enabling related-tenant discovery is permanent (deployment guide). For a controlled pilot, run the handshake by tenant ID and skip discovery. Azure Lighthouse, by contrast, coexists with a governance relationship on the same customer, different mechanism, different plane.
Conditional Access is the customer's to enforce. Because the provider signs in to the customer tenant, the customer's Conditional Access governs that access.

12. Summary

Azure Lighthouse and Microsoft Entra Tenant Governance are two delegation models pointing in opposite directions. Lighthouse brings the customer's resources up to the provider and keeps the provider's Azure access clean and identity-free. Tenant Governance places a governed proxy of the provider down in the customer, extending the very philosophy from Parts 1–2, govern the relationship, not the people, from the resource plane all the way into the directory.

Choose by the direction the trust needs to flow: bring the resources to you (Azure Lighthouse), or place a governed proxy of yourself in the customer (Microsoft Entra Tenant Governance). When you need both, use both.

Windows defender is having a lot of problems.

LilNucleus — Wed, 22 Jul 2026 18:00:20 GMT

So I have a Microsoft 365 Family subscription, and Dark Web Monitoring shows 0 monitored items. SSN verification fails and advises you to contact support. I was also unable to delete the monitored information. I’m receive the error "Something went wrong, try again in a bit." The issue occurs in the Microsoft Defender app, web portal, and across devices. Is there anyway that I can get help with this?