The same administrators targeted, the same emergency accounts excluded, copied across ten policies: that is everyday life when Conditional Access is managed as a flat list. Microsoft Entra ID offers, in public preview announced at the end of October 2026, Conditional Access policy plans, which group these rules around a security objective. This tutorial shows you how to read your current policies, build a hardening plan and migrate in report-only mode, with no surprises in production.
What Conditional Access plans change, and what they leave untouched
A plan is a container tied to a security objective, for example protecting administrative accounts. It holds a shared configuration (identities, resources, conditions) and several rules, each of which adds its own control: phishing-resistant MFA (multifactor authentication), compliant device, session lifetime. Where you used to have three separate policies, you now have one plan and three rules that inherit the same foundation.
On the engine side, nothing changes. According to the Microsoft Learn documentation, plans do not replace existing policies: classic policies and plan rules are evaluated independently, with no priority between them, and all those that apply must be satisfied. Each rule appears separately in the sign-in logs.
An illustrative example: Alex signs in from a Windows workstation. A rule that blocks unsupported platforms does not affect Alex, but a second rule requires a compliant device. If the device is non-compliant, access is denied, exactly as with two classic policies.
Preview, P1 or P2 licence and dedicated role
The Microsoft Learn documentation (accessed on 8 November 2026) states that plans are still in public preview. The official announcement on Tech Community specifies the required licence (Microsoft Entra ID P1 or P2) and the minimum role (Conditional Access Administrator). The menu is under Entra ID > Conditional Access > Policy plans (Preview).
Shared conditions or rules: where to place each setting
The model is additive, not subtractive: the plan defines a foundation, and rules enrich it but cannot reduce it. This constraint shapes the entire design.
| Element | Plan level (shared conditions) | Rule level |
|---|---|---|
| Targeting | Foundation inherited by every rule, cannot be reduced | Adds to the plan foundation |
| All users | Not available | Available |
| Exclusions (emergency accounts) | Cumulative, cannot be removed from a rule | Additional exclusions possible, which accumulate |
| Grant and session controls | Not applicable | Defined here, rule by rule |
| Directory roles, applications, user actions, user risk | Possible as a common foundation | Possible as an additional refinement |
Three practical consequences. First, shared conditions are optional: a plan for “device and application access” can define none, with each rule then carrying its own target. Second, pool only what several rules truly share, such as “always the administrators, always without the emergency accounts”. Finally, saving a change to a plan's foundation applies it to all downstream rules.
The documentation also specifies that identity types (users, agents, workload identities) cannot be mixed in shared conditions. For that last case, see our article on Conditional Access for AI agents and governance of non-human identities.
Create the Privileged access plan step by step
This example builds a hardening plan for privileged accounts, with three rules. Rule names follow a CO101, CO102, CO103 convention: it serves as a reference when you read the logs.
Open the creation wizard
In the Microsoft Entra admin center, go to Entra ID > Conditional Access > Policy plans (Preview) and create a plan. Name it after its security objective (here Privileged access). Add owners and labels (identity, administrators): these are organisation and search markers, and they do not change your existing RBAC controls on editing or deleting the plan.
Define the shared foundation
In the shared identities, target the relevant directory roles (the original demonstration starts from the Global Administrator role, but a real foundation covers all of your privileged roles) and exclude the emergency access accounts group. This foundation will apply to every rule in the plan.
Create the first rule
The wizard accepts only a single rule at creation. Create CO101 (administrators, phishing-resistant MFA), leave the initial state as report-only, then in the grant controls choose to require an authentication strength. Built-in authentication strengths and your custom strengths are offered.
Add the following rules
From the plan page, add CO102 (administrators, device marked as compliant) then CO103 (administrators, sign-in frequency of 4 hours). Keep the report-only state and target all resources at the level of each rule.
Use each rule's menu
A rule's menu lets you view its impact on sign-ins (successes, failures, report-only), duplicate it, move it to another plan, edit it or delete it. The “edit all rules” action displays a warning: it lets you change the state of all rules at once.
No lockout safeguard observed in preview
In preview, a rule targeting all users and all resources with an MFA requirement, with no exclusion at all, could be saved and then enabled without any warning, unlike classic policies. Always exclude your emergency accounts group at the plan level and always go through report-only before enabling a rule.
Implementation: inventory your policies and read the report
Before grouping anything, you need to know what you have. The scripts below are read-only: they inventory your policies and summarise sign-in results. They do not create any plan, because the supporting research notes that Microsoft Graph, PowerShell, backup and restore need to be verified before adopting plans at scale (analysis by Tony Redmond on Office365itpros).
Inventory and candidates for shared conditions
Prerequisites: PowerShell 7 or later, the Microsoft.Graph.Identity.SignIns module (Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser), the delegated Policy.Read.All permission and an account allowed to read Conditional Access policies. The script produces an inventaire-ca.csv file, the number of policies, the list of enabled policies without exclusions that target all users, and the groups of policies with identical targeting.
1# Connexion avec le scope minimal en lecture2Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome3 4# Récupération de toutes les stratégies d'accès conditionnel, tous états confondus5$policies = Get-MgIdentityConditionalAccessPolicy -All6 7$inventaire = foreach ($p in $policies) {8 $u = $p.Conditions.Users9 # Signature de ciblage : sert à repérer les stratégies qui répètent le même socle10 $signature = '{0}|{1}|{2}|{3}' -f (@($u.IncludeRoles | Sort-Object) -join ','), (@($u.IncludeGroups | Sort-Object) -join ','), (@($u.ExcludeUsers | Sort-Object) -join ','), (@($u.ExcludeGroups | Sort-Object) -join ',')11 12 [pscustomobject]@{13 Nom = $p.DisplayName14 Etat = $p.State15 CibleTousUtilisateurs = (@($u.IncludeUsers) -contains 'All')16 ExclusionsUtilisateurs = @($u.ExcludeUsers).Count17 ExclusionsGroupes = @($u.ExcludeGroups).Count18 Ressources = (@($p.Conditions.Applications.IncludeApplications) -join ';')19 Octroi = (@($p.GrantControls.BuiltInControls) -join ';')20 ForceAuthentification = $p.GrantControls.AuthenticationStrength.DisplayName21 FrequenceConnexion = if ($p.SessionControls.SignInFrequency.IsEnabled) { '{0} {1}' -f $p.SessionControls.SignInFrequency.Value, $p.SessionControls.SignInFrequency.Type } else { '' }22 Signature = $signature23 }24}25 26# Export complet pour analyse hors ligne27$inventaire | Export-Csv -Path .\inventaire-ca.csv -NoTypeInformation -Encoding UTF828 29# Rappel de la limite documentée de 240 stratégies par tenant30Write-Host ('{0} stratégie(s) sur 240 maximum par tenant' -f $inventaire.Count)31 32# Risque de verrouillage : stratégies actives, tous utilisateurs, aucune exclusion33$inventaire | Where-Object { $_.Etat -eq 'enabled' -and $_.CibleTousUtilisateurs -and $_.ExclusionsUtilisateurs -eq 0 -and $_.ExclusionsGroupes -eq 0 } | Format-Table Nom, Octroi -AutoSize34 35# Candidats à un plan : stratégies partageant le même ciblage non trivial36$inventaire | Group-Object Signature | Where-Object { $_.Count -gt 1 -and $_.Name -ne '|||' } | ForEach-Object { '{0} stratégies au ciblage identique : {1}' -f $_.Count, (($_.Group.Nom) -join ' ; ') }Groups of policies with identical targeting are your first candidates for a plan. The script does not show how a plan's rules count toward the 240 limit: the Conditional Access planning documentation recommends consolidating rather than adding, without clarifying this point.
Read the results of rules in report-only mode
Prerequisites: the Microsoft.Graph.Reports module (Install-Module Microsoft.Graph.Reports -Scope CurrentUser), the delegated AuditLog.Read.All permission and a role that allows reading sign-in logs. Over the last seven days, the script groups the number of sign-ins by policy or rule and by result.
1Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome2 3# Fenêtre d'analyse : les 7 derniers jours, en UTC4$depuis = (Get-Date).AddDays(-7).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')5 6# Échantillon de 500 connexions maximum7$connexions = Get-MgAuditLogSignIn -Filter ('createdDateTime ge {0}' -f $depuis) -Top 5008 9# Une ligne par stratégie ou règle évaluée pour chaque connexion10$resultats = foreach ($c in $connexions) {11 foreach ($a in $c.AppliedConditionalAccessPolicies) {12 [pscustomobject]@{ Regle = $a.DisplayName; Resultat = $a.Result }13 }14}15 16# Synthèse : les résultats préfixés reportOnly correspondent au mode rapport seulement17$resultats | Group-Object Regle, Resultat | Sort-Object Name | Select-Object Count, Name | Format-Table -AutoSizeLook for reportOnlyFailure lines: they identify sign-ins that the rule would have blocked if it were enabled. This is your remediation list, to be handled before any move to production. Because each rule appears separately in the logs, a rigorous naming convention makes this summary readable.
Migrate your existing policies without breaking anything
No need to recreate everything: a built-in migration tool analyses the policies you select. Each policy becomes a rule and common settings become shared conditions. The Microsoft Learn migration procedure recommends proceeding by coherent groups of policies.
Start the migration from the Policies page
Click the “Migrate to Conditional Access Policy plans” banner, then Get started. Select a thematic group, for example device and application policies: blocking BYOD (personal devices) in the browser, application restrictions, mobile app protection.
Name the plan and review the proposal
Give the plan a name (for example Devices and applications). The tool looks for genuinely common conditions, such as “all administrators” or “all emergency accounts”; if it finds none, no shared condition is created. You can then edit the plan to add shared identities yourself.
Note the Disabled state
The generated rules start in the Disabled state and the original policies are not modified: they remain active in the list. No switch happens without your decision.
Set the rules to report-only and compare
Set the rules to report-only, let them run for a few days, then compare the sign-in logs using the previous script. In the details of a sign-in, clicking the policy shows the originating plan and the rule concerned.
Enable the rules, then disable the original policies
Once the results are consistent, enable the plan's rules and only then disable the original policies. During coexistence, both sets apply and all must be satisfied: keep this window short.
To structure your validation campaign, rely on our Conditional Access policy testing framework, which details how to avoid blockages in production.
Preview pitfalls and troubleshooting
The last three rows of the table come from the Microsoft Learn documentation; the first two are observations made in preview and may be fixed.
| Symptom | Probable cause | Resolution |
|---|---|---|
| Loss of access after enabling an MFA rule | Rule targeting all users with no exclusion, with no warning in preview | Exclude the emergency accounts group at the plan level, test in report-only, check an emergency account before enabling |
| Unable to target specific client app types, for example to block legacy authentication | Behaviour observed in preview: the “all” app type is added automatically | Keep the corresponding classic policy until the behaviour is fixed |
| “All users” not found at the plan level | Option available only in rules | Define this targeting in each relevant rule |
| Plan exclusion cannot be removed in a rule | Exclusions accumulate, a rule cannot remove those of the plan | Rethink the split: place the exclusion in the rules that need it, not in the foundation |
| Unexpected effect on several rules after a change | Change to the plan's shared foundation, applied to all rules | Validate in report-only and review the impact of each rule before saving |
Location condition: one-hour tokens in preview
According to Microsoft Learn, for users targeted by a plan that uses location as a condition, Microsoft issues one-hour access tokens, without instant IP enforcement. For geoblocking or IP restrictions, keep your classic policies until the preview evolves and test before reorganising production.
Frequently asked questions
Can Conditional Access plans be used in production?
They are in public preview according to the Microsoft Learn documentation accessed on 8 November 2026. Nothing requires you to adopt them: your classic policies continue to work. Start with a limited scope in report-only mode.
Which licence and role are needed to create a plan?
A Microsoft Entra ID P1 or P2 licence is required, and the minimum role is Conditional Access Administrator. The menu is under Entra ID > Conditional Access > Policy plans (Preview).
Should I migrate all my policies at once?
No. Migration can be done by groups of policies, the generated rules start disabled and the original policies are not modified. Proceed theme by theme: report-only, log comparison, rule activation, then deactivation of the original policies.
Do a plan's rules count toward the 240-policy limit?
The documentation consulted mentions a limit of 240 Conditional Access policies per tenant, all states combined, but does not specify how plan rules are counted. If in doubt, consolidate before adding.
Can plans be automated with Microsoft Graph or PowerShell?
Tony Redmond's analysis notes that Graph, PowerShell, backup and restore need to be verified before adoption at scale. Check the Microsoft Learn documentation before automating, and in the meantime use the read-only inventory presented above.
Where to start
Action plan for your first hardening plan
- Check the Microsoft Entra ID P1 or P2 licence and the Conditional Access Administrator role
- Run the inventory to spot policies without exclusions and repeated targeting
- Verify that the emergency accounts group is excluded and tested
- Create a first plan on a specific theme (privileged access or devices and applications)
- Keep all rules in report-only and review the
reportOnlyFailureresults - Enable the rules, then only afterwards disable the original policies
- Keep classic policies for location conditions as long as the one-hour token limitation applies
If you manage several tenants with automated templates, wait for verified APIs and tooling before adopting plans at scale, and limit yourself to testing for now. If you administer a single tenant, start with the privileged access plan: it is where the duplication of exclusions is most obvious. For your existing MFA policies, review our guide to enforcing MFA in Microsoft Entra ID.
Going further
- What is a Conditional Access policy plan? (preview): how it works, condition inheritance, runtime evaluation and preview limitations.
- Migrate Conditional Access policies to a plan (preview): the official procedure, from report-only mode to deactivating the original policies.
- Scale access controls with Microsoft Entra Conditional Access policy plans: the official public preview announcement, with the required licence.
- Microsoft Launches Preview of Entra ID Conditional Access Policy Plans: an independent analysis of the preview restrictions and tooling issues.
