New Conditional Access policy plans in Microsoft Entra
Add a rule for each requirement, like phishing-resistant MFA or compliant devices, and keep the shared scope in one place. Build a plan around a user group, like headquarters staff, or a shared condition, like high agent risk, and start from templates. Merge existing policies into a plan with the migration tool. It pulls shared conditions up to the plan and turns each policy into a rule. Your current policies stay enforced until you cut over. Etan Basseri, Principal Product Manager, Microsoft Entra, shares how plans and rules fit together in the Microsoft Entra admin center. Define your access controls once. Enforce it consistently across every rule with Conditional Access policy plans. See how it works. Add a rule, keep your scope. Set HQ users and break-glass exclusions once in a Conditional Access policy plan, then add rules for phishing-resistant MFA and compliant devices. Watch here. Simplify existing Conditional Access policies. Bring those with a shared naming prefix into one policy plan. Migration automatically identifies shared conditions and converts each policy into a rule. Try it now. 👥 Who it’s for: Identity and security admins who manage Conditional Access in Microsoft Entra, and architects planning how to organize or migrate large policy sets, including access controls for AI agents. ⏱️ Chapters: 00:00 Conditional Access policy plans in Microsoft Entra 00:48 Track policies beyond naming prefixes 01:29 How shared conditions and rules work 02:41 Create a policy plan for HQ users 03:43 Add a phishing-resistant MFA rule 04:43 Add a compliant device rule 05:51 Block high-risk AI agents in one plan 06:56 Migrate existing policies into a plan 08:11 Keep policies enforced until cutover What are Conditional Access policy plans? They organize access controls around an objective, either a persona like employees, external guests or administrators, or a security goal like requiring compliant devices or securing agent activity. Plan-level attributes cover identities, resources and applications, user actions and authentication context, plus shared conditions like risk levels, devices, network locations and client app types. Each rule layers its own conditions and grant or session controls on top. Plans live in a new Policy plans view, next to your existing policy list under Conditional Access. The headquarters plan in the demo includes the HQ All Users group and excludes a break-glass group to prevent lockouts. Its first rule requires phishing-resistant MFA through authentication strength and starts in report-only mode. A second rule requires devices marked as compliant. Neither rule repeats the included or excluded groups. The agent plan, built from a template, sets high agent risk as its shared condition. Separate rules block high-risk agent users and high-risk autonomous agents acting with their own agent-specific permissions. How do you move existing policies over? Filter your policy list, for example by a branch office naming prefix, select the policies and merge them into one plan. The preview shows which resources become shared conditions and how each policy maps to a rule, with its identities, locations, grant and session settings. After you enforce the new plan, turn off or delete the original policies. 🔗 Related links: Check out https://aka.ms/ConditionalAccessPolicyPlans Unfamiliar with Microsoft Mechanics? Microsoft’s Official Video Series for IT — Subscribe https://www.youtube.com/c/MicrosoftMechanicsSeries — Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog — Podcast: https://microsoftmechanics.libsyn.com/podcast Join us on social: — https://twitter.com/MSFTMechanics — https://www.linkedin.com/company/microsoft-mechanics/ — https://www.instagram.com/msftmechanics/ — https://www.tiktok.com/@msftmechanics Video Transcript: -Conditional Access is Microsoft’s Zero Trust policy engine. What it protects has expanded, and now we’re evolving the management experience to match. Today, it continuously assesses real-time signals across users, AI agents, applications, endpoints, networks, and resources to enforce Zero Trust. Based on an identity and its context, it makes adaptive access decisions, determining whether to require additional controls in order to allow or restrict access, or block the request to specified resources altogether. And to help you manage those access controls more effectively at scale, we are introducing Conditional Access policy plans. I’ll show you what these are, how they expand what you can do, and how they work with your existing Conditional Access policies. -So, what are policy plans, and how do they help? Well, until now, you’ve probably been managing who gets access to what across your organization as one flat list of policies. What started off as a small list of controls, including multifactor authentication, device compliance requirements, along with the scoping and exclusions within policies to make everything work, has now expanded to fine-grained, risk-based policies, identity-driven network controls through Global Secure Access, dedicated conditions for agent identities, and much more. -Over time, it’s become harder to understand how policies relate to one another, who owns them, and how changes might affect access decisions. There’s no grouping and no structure in that list, so the only way to keep track of what covers what might be creative naming prefixes or other solutions. This is where Conditional Access policy plans come in. It’s a new policy framework for Conditional Access, where you organize access controls around an objective, instead of managing them one policy at a time. A policy plan objective might be based on a specific persona, like employees, external guests, or administrators, or a security goal, like securing agent activity or requiring compliant devices. -At the plan level, you can define the common attributes for that objective once. This includes identities, resources including applications, user actions, and authentication context, as well as shared conditions like risk levels, devices, network locations, and client app types. Each plan then holds one or more rules, and every rule inherits those shared attributes automatically. A rule adds the specifics needed to meet the objective, its own conditions, and its own grant or session controls. So, a variation of your objective becomes a rule, instead of another standalone policy to manage. It’s a new framework where each policy plan has its own name, description, owner, and tags. -So, it’s clear what each plan is for, who owns it, and what will change if you edit it later. That’s what keeps policy sprawl down as you scale. Importantly, your existing Conditional Access policies will continue to work, and won’t be affected as you roll out policy plans. Let me show you this in action, starting with a new policy plan, in this case, with the objective of securing access for people working from our company headquarters. In the Microsoft Entra admin center, under Conditional Access, there’s a new “Policy plans” view sitting alongside the list of policies you have today. I’ll create a new plan to manage headquarters users. -First, I’ll give it a name, type in a description that will be useful for anyone to know what this plan is about, then I’ll add a tag, “HQ,” for easier filtering, and you can see that my name is auto-filled as the owner of this plan. Below that is where, based on the policy plan security objective, you can select the appropriate shared identities, resources, or conditions. Because this plan’s objective is to specify requirements for people in the headquarters location, I’ll only need to use shared identities here. -I’ll go into users and groups for my inclusions, and by filtering to HQ, I’ll see the matching groups. I’ll select the “HQ All Users” group. I also want to add an exclusion here to avoid unexpected lockouts. So, following the same steps, I’ll pick a group to exclude and choose “Break Glass HQ.” That means these groups will be inherited as assignments by any rule within this policy plan. When you create a new plan, the process guides you through creation of its first rule. If you’ve ever written a Conditional Access policy, this will look familiar. I’ll create a rule to require phishing-resistant authentication for headquarters users. I just need to give my rule a name and optionally add a description that can be referred to later. -For the rule’s state, I’ll leave this as report-only for now, but I could toggle it to on from here. Notice that I don’t need to define the assignments and conditions again for the included and excluded groups. However, I do need to assign resources. So, I’ll do that here, in this case, by selecting “All resources,” and then confirm. Now, for under these conditions, I’ll leave “All client app types,” and I can go straight into Grant and session controls in this case. I’ll choose to grant, but require authentication strength, and choose “Phishing-resistant MFA,” and confirm that control. That way, all headquarters users are required to meet this authentication strength for all resources they are trying to access. Now, I just need to review and create my policy plan and initial rule. And from there, I can add more rules to this plan. So, I’ll create a rule to require compliant devices from our HQ users. -Previously, each rule would have meant creating a separate policy and reconfiguring the same shared identities and exclusions. Again, this would apply to shared resources and conditions based on your plan and its security objective. Now, I just need to enter a name. I’ll call this “Require Compliant Device,” and then in the description, I’ll write what this rule does. Again, under Accessing these resources, I want to assign all resources to this rule. So, I’ll change the resource assignment like last time, from “None” to “All resources,” and confirm. From under these conditions, I’ll leave all client apps. -For this rule, I’ll add a control to grant again, and in this case, require device to be marked as compliant. I can do the same to add risk-based rules or others to my plan. Now, I just need to save it, and that’s it. So, instead of managing multiple policies with the same scope, shared assignments are defined once, and individual access requirements are implemented as rules. From here, I can keep going to create other plans for specific objectives, and I’ve already created a few. And you can see we have some for different identities, specific resources like important ERP apps, or conditions like the policy plans listed based on risk. I just showed you how to create a plan based on a user group in our specific HQ location. -So, now let’s look at one based on a security objective, securing agent access, where it’s now a lot simpler to apply Conditional Access to agentic activity. You can see that this plan is using shared conditions for all client app types, and where agent risk is determined to be high. And below that, there are individual rules defined to block high-risk agent users and block high-risk autonomous agents. This will help ensure that access protections cover agents acting with their own agent-specific permissions. Without a policy plan, each of these scenarios would require its own standalone policy, repeating many of the same conditions. I’ll open this rule for the high-risk autonomous agents, and you’ll see that it includes the inherited conditions of the plan, and adds an assignment for all agent identities. And under controls, it’s set to block when those conditions are met. -So, now, instead of spreading agent access controls across multiple policies, they’re organized in a single plan, making them easier to understand, manage, and update as requirements evolve. The good news is that you don’t need to build these policy plans from scratch. In fact, the agent policy plan I just showed you was created by using a template. -Next, let’s move on to your existing Conditional Access policies, and I’ll show you how to quickly migrate what you already have in place into policy plans. The first plan we created for users at the company headquarters runs in parallel with existing policies for our various branch offices. Each have dedicated Global Secure Access security profiles. As you can see, this environment has dozens of Conditional Access policies already running, and I filtered my list down to branch office policies, because the only thing connecting these policies together was the naming prefix. I’ll use the “Migrate to Conditional Access Policy plans” option and get started. That will keep my filtered list of policies and allow me to select the ones I want to migrate. In this case, I’ll use the top “Select all” control to save a few clicks, then choose “Merge 5 policies into a plan.” And now I can see a preview of my plan before I create it. I’ll give this policy plan a name, “Branch Office Access.” -Under the covers, the process looks for anything that my selected policies have in common, and defines those as shared conditions, as you can see with the two resources here. Below that, each of my previous policies are translated into rules, where you can see identities, resources, locations, grant, and session configurations for each. Then, to confirm, I just need to click “Create policy plan.” And just like that, my five policies have been migrated into one plan, with a set of shared conditions and unique rules. My original policies are still there and untouched. Each are also still enforced based on their policy state. -Once you’re ready, you’re in control of managing the cutover to the new plan by enforcing it. From there, you turn off or delete the previous policies. And as you add new branch locations, those just become new rules in your plan. So, that’s how we’re evolving the framework for managing Conditional Access, moving from individual policies to security objectives that can be defined once and enforced consistently across your environment. -Check out aka.ms/conditionalaccesspolicyplans to learn more. Keep watching Microsoft Mechanics for the latest tech updates, and thanks for watching.
Unexpected Private Access rule after rebuilding Global Secure Access v2
Hello everyone, I'm rebuilding a Microsoft Entra Global Secure Access / Private Access POC after initially creating several configurations while learning the platform. I performed a clean functional rebuild: removed the previous application segments and assignments, reinstalled the Private Network Connector, created a new connector group, rebuilt Quick Access, and created a new custom Private Access traffic forwarding profile assigned only to my test account. My intended Quick Access configuration currently contains only three TCP destinations on the same private server: ports 80, 445 and 9000. However, the effective forwarding profile received by the Global Secure Access Client also contains an unexpected rule: 192.168.1.208 | All protocols | 54-65535 | Tunnel This rule existed in the original default Private Access profile and continues to appear even in a newly created custom profile. There is another unusual behavior in Acquisition Rules. An internal GUID reference is displayed in the profile, but the application selector shows Selected (0). The GUID cannot be removed through the UI, is not visible as a normal Enterprise Application, and I could not resolve it as either an Application or Service Principal through Microsoft Graph. I also found: ZTNA Network Access Client -- Private, which previously contained segments and assignments that I have since removed; two different objects named Carbomix - Rede Interna, with different identifiers; an error when attempting to remove an inherited link from the system-created profile: Only Profiles with IsCustomProfile set to true can be updated with bulk policy links. The connector itself appears healthy. I completely reinstalled it and the official Connector Diagnostics Tool passes certificate, TLS, CRL, Bootstrap, Trust Renewal, Service Bus, SLB and endpoint connectivity checks. Private Access also works for normal TCP traffic. TCP 445 and 9000 are successfully tunneled, including a sustained TCP session on port 9000. I'm mainly trying to understand: Where does the unexpected All protocols / 54-65535 rule come from? Why does it survive a clean custom Private Access profile? What are these internal application references that appear in Acquisition Rules but are not selectable/removable or resolvable through Graph? Could this be configuration inherited during migration to Traffic Forwarding Profiles v2? Is there a supported way to inspect and clean this inherited state? Has anyone working with Microsoft Entra Private Access v2 seen similar behavior? I have screenshots, effective forwarding-profile data, Connector Diagnostics results and Graph tests available and can share the relevant details as needed. Thanks!Entra ID - Federation or EAM for Passkey deployment
Question for the community: Looking to replace Entra to ADFS federation and also implement passkey. Have an existing deployment with a third party MFA provider. I want to limit the disruption for my end users as much as possible and am looking at 2 possible paths forward: Replace ADFS with third party, allowing Passkey and push from the third party, as well as first factor auth. Move to Entra staged rollout with EAM and have Entra deal with first factor. I know this wont include the ability to use third party first factor. Issues I am seeing is that the system browser setting needs to be enabled on the tenant and cant enforce external auth strengths in entra conditional access. All roads keep leading back to Entra which is fine with me but I do not currently have a P2 license for the advanced risk analytics. My third party currently has that capability. Would also love to know any rumblings of authentication strenght support for External MFA. What are some of the configurations out there that you all are doing and any pros/cons of each.
Trying to get support in reseting Authenticator MFA
Hello! We are locked out of our tenant's admin center as our authenticator installed device has been reset by mistake. I contacted our call MS service phone number (211 18 13 880) in Greece, but the AI bot is unable to record the case as it cannot vocally identify the admin user account and domain of our tenant, finally it terminates the call. There is no direct contact email or phone to human support from the data protection team. How are we supposed to handle this case further? .
Free, offline tool: see each user's real passkey policy in Entra ID and who SMS retirement blocks
Entra combines passkey profiles as a union (any profile that allows a passkey type wins), while Conditional Access works as an intersection. So a Global Admin in a strict "security keys only" profile who is also in an All Users profile can still register a synced iCloud or Google passkey, and the portal never shows you that per user. I built EffectivePasskey to answer three questions for every user and admin: 1. What passkey can this person actually register? 2. What can this admin actually sign in with after Conditional Access? 3. Who gets blocked when SMS and voice MFA retire (1 Feb 2027, and 1 Jul 2027 for Global Admins)? It runs entirely on your machine from read-only JSON exports. It never signs in to your tenant and never changes anything. No telemetry. MIT licensed and completely free. Try it with the included demo tenants: pip install effective-passkey GitHub: https://github.com/xsignon-secure/EffectivePasskey Feedback and issues are very welcome, especially from anyone mid-rollout.Microsoft Entra provisioning Agent Error
Hello, I have deployed the Microsoft Entra provisioning agent in my organization, with synchronization configured from AD to Microsoft Entra ID. I am encountering an issue on the server where the Cloud Sync agent is installed: when connecting to Microsoft endpoints via a Squid proxy, I receive the error shown in the screenshot. The synchronization itself works perfectly, and the configuration status in the cloud is "Healthy." I frequently see the error shown in the screenshot (error code 12015), and I also occasionally encounter error code 12011. Has anyone experienced a similar issue? Could you please advise on how to resolve it? Thanks.Bulk Enrollment suddently stopped working?
We've been generating BPRT tokens for Entra ID enrollment via provisioning package (WCD) for a long time. This started out of the blue, tried from three different tenants, these two error messages: AADSTS90202: A transient error has occurred. Please try again. AADSTS240001: User is not authorized to register devices in Azure AD I know its not authorization because the same user was working the day before and because I even tired removing the enrollment restriction from the tenant altogether.Entra-issued agent identities, verified offline by a party with no Microsoft credential
I am Toshikatsu Oga, representative director of The HORIZONs Co., Ltd. in Tokyo. We build NENRIN, an open record format and verifier for what AI agents authorize and execute, built so that a third party can recheck the records without trusting us and without access to the systems that produced them. On 2026-10-15 we ran this against a real Microsoft Entra ID tenant: Two agent app registrations obtained v2.0 access tokens with the client credentials flow (RS256). Each agent bound its own signing key to its token, inside the token's lifetime (record format idp-bind-v0). Agent A signed a grant authorizing one action. Agent B signed a receipt for executing exactly that action, committing to the grant by hash. A reader holding only four files (the two bindings, the tenant's JWKS pinned by SHA-256, and the grant and receipt), with no network access and no Microsoft credential, verified all four records in two independent runtimes (JavaScript and Python). It printed which Entra subject authorized what, and which one executed it. We ran the same thing with Google service-account ID tokens the same day, with the same reader. Since 2026-10-16 we also record the Entra and Google signing keys every day and anchor them to Bitcoin, so a reader can check later that a pinned JWKS is the one the issuer was serving at the time. Code and records (MIT): github.com/ogasurfproject-jpg/horizon-shield (folder workers/hs-ledger/nenrin/idp-bind-v0/real-issuers) (run node check.mjs). For the Entra run, the grant, receipt and JWKS are public. The two bindings are pinned by SHA-256 but withheld, because GitHub push protection treats Entra access tokens as secrets even after expiry. They are available to the Entra team on request. What this does not establish: that the action happened in the world (a signature proves who asserted it), or possession of the identity beyond holding a live token, because the tokens carry no cnf claim (RFC 7800). The verifier already supports a cnf claim naming the agent's key, which would upgrade the result from bearer_only to cnf_bound. Two questions for the Entra Agent ID team: Is there a supported way to obtain a proof-of-possession (cnf) token for an agent identity, so the binding can be possession-proven rather than bearer? Would an offline-verifiable record of what agent identities authorized and executed be useful to your customers? It is meant for auditors, counterparties or regulators who cannot sign in to the tenant. Toshikatsu Oga, The HORIZONs Co., Ltd. (email address removed for privacy reasons, ORCID 0009-0000-9180-903X)
Passkey/FIDO2 for users in mainland China – recommended approach?
Hi, We are currently evaluating the adoption of Passkey/FIDO2 in Microsoft Entra ID as part of our strategy to move users away from traditional authentication methods such as SMS and voice and towards phishing-resistant authentication. Our Microsoft Entra ID tenant is a global tenant (not Azure China operated by 21Vianet), but we have a group of users who are physically located in mainland China. For users in other regions, we are evaluating Passkeys in Microsoft Authenticator and FIDO2 security keys. However, before defining the approach for our users in China, we would like to better understand the supported and recommended architecture for this particular scenario. We have reviewed the Microsoft documentation and understand that: Passkeys are not available for Microsoft Azure operated by 21Vianet. On iOS, Microsoft Authenticator Passkeys can be used to sign in to global organizations while the user is in China. On Android, Passkey authentication has dependencies such as Google Play Services, which raises questions for devices operating in mainland China. Our main questions are: For users physically located in mainland China but authenticating against a global Microsoft Entra ID tenant, what is Microsoft's recommended approach for deploying phishing-resistant authentication with Passkey/FIDO2? Is Microsoft Authenticator Passkey on iOS considered a fully supported option for users permanently located in mainland China, rather than only users temporarily traveling there? For Android users in mainland China, what is the recommended approach considering the dependency on Google Play Services? Is Passkey in Microsoft Authenticator a realistic supported option in this scenario? Would physical FIDO2 security keys be the preferred or more consistent alternative for users in China when mobile Passkeys cannot be reliably used? Are there any other Microsoft-supported Passkey providers or authentication approaches that should be considered specifically for mainland China? From an enrollment perspective, what would be the recommended bootstrap process for these users? For example, would Temporary Access Pass (TAP) be the recommended method to allow users to register their Passkey/FIDO2 credential before SMS/Voice is removed? Are there any additional regional, connectivity, mobile OS, or application compatibility considerations that should be taken into account before enforcing a phishing-resistant Authentication Strength through Conditional Access? Our objective is not simply to enable Passkey in the tenant, but to define a supported and sustainable authentication model for users located in mainland China before starting a broader rollout. Any experience, Microsoft guidance, or recommended architecture for this type of scenario would be greatly appreciated. Thanks in advance.
Sole Global Administrator locked out — no working MFA method — need account recovery
I'm the sole Global Administrator of my Microsoft Entra ID tenant and I'm completely locked out due to losing access to my MFA device, with no other admin and no working alternate verification method. Account details: - User (UPN): email address removed for privacy reasons - Custom verified domain: apip.dk - Tenant ID: can be provided - Azure Subscription ID: can be provided What happened: My phone (with Microsoft Authenticator installed — my only registered MFA method) was destroyed. I know my password and secondary email, but: - Phone-call verification during sign-in does not connect. - I have a FIDO2 security key, but it is not currently enabled/registered as a sign-in method on this account. - There is no other Global Administrator in this tenant and no other active session I can use to self-recover. What I need: An MFA/authentication-method reset on my account so I can sign back in and register a new MFA method, or guidance on an alternative recovery path. Proof of ownership I can provide: - I own the custom domain apip.dk and can add/modify a DNS TXT (or CNAME) record to verify tenant ownership. - I can provide billing details for the subscription (card on file, recent invoice amounts, billing address) if needed for verification. Additional context: I recently updated the payment method on this subscription, so I'm concerned about a billing failure at the next payment date while this recovery is pending — I'd appreciate the account being flagged so it isn't suspended during this process. Please let me know what verification steps you need from me to proceed. Thank you, Andreas
