Entra Conditional Access: policy plans and what's new

Conditional Access is usually built policy by policy, without an overall view, and the engine has just changed behavior too: since June 15, 2026, sign-ins that were previously spared now trigger MFA. The Microsoft Entra admin center also exposes a "Policy plans" entry for assembling policies. You will know what to audit in your tenant, which deadlines to plan for, and how to test a policy in report-only mode with Microsoft Graph PowerShell.

Policy plans: a new way to assemble Conditional Access

In the Conditional Access area of the Microsoft Entra admin center (entra.microsoft.com), a Policy plans entry lets you create a blank plan instead of starting from a template. A "What if" environment is offered in the same place, and the list can be filtered by name, description or tag.

The plan is used to group policies rather than create a single one. The interface presents them as a metro-map-style layout, which makes the chain of identities, resources, conditions and controls easy to read. A plan also has an owner (with additional owners possible) and search tags, two fields absent from classic policies. They answer a real governance question: who is accountable for a set of rules.

Building a plan: identities, resources, conditions, controls

The flow follows five steps. Each one groups what the classic policy editor spreads across several panes.

The following table summarizes the conditions seen in the editor and the points of attention that follow from them.

An example of use: a team of on-premises administrators restricted to corporate workstations from a specific manufacturer. The filter combines device ownership equal to company and the manufacturer, then the plan enforces passwordless MFA. Admin policies thus stay in a single readable object.

What changes in the engine: deadlines to audit

Policy plans are an administrative convenience. The changes below, on the other hand, change what your users experience.

Baseline scopes: why MFA shows up in VS Code or Azure CLI

The Microsoft Learn documentation states that since June 15, 2026, a policy that targets All resources with exclusions also applies to sign-ins that request only baseline scopes (OIDC or directory), for example VS Code or Azure CLI with User.Read. Some users therefore receive an MFA prompt they had never seen. Administrators can adjust or postpone this behavior in the Baseline scopes settings.

Custom controls, credential registration, Device state

Three other points call for a decision:

• Custom controls: configurations keep working, but the migration to External MFA must be planned before the May 2027 end of life.
• Register security information: MFA remains required by default to register passwordless credentials. The Learn page says July 6, 2026 whereas a Tech Community post announced July 13, 2026; refer to the Learn page.
• Device state: this condition is deprecated. Microsoft recommends Filter for devices, which you will find in the policy plan.

AI agents: Conditional Access and identity blueprints

Since June 2026, in public preview, Conditional Access also protects AI agent user accounts. You target specific agents or dynamic groups based on Custom Security Attributes. An agent risk condition (Agent Risk), compliant devices (including Windows 365 for Agents), platforms and device filters, and compliant network are available.

The network condition has a limit: for agent accounts, it applies only if the device provides the required signal, for example through the Global Secure Access client.

One default setting deserves your attention: under Users, then User settings, the default permissions now include the ability for users to register agent identity blueprints. This setting is enabled by default. If you do not want every user to create these objects, turn it off.

On the automation side, the Conditional Access Optimization Agent can also propose passkey adoption campaigns, first for administrator roles, and it creates its policies in report-only mode. For the passkey side, our in-depth guide to Entra passkeys details the rollout.

OneDrive and Exchange Web Services: two settings to check

The OneDrive interface has changed: the create and upload button moves to the right, with shortcuts to create a Word, Excel, PowerPoint or PDF document. Sharing a folder displays the link settings (anyone, people in the organization, specific people) and the folder's sharing status.

The "anyone" option remains controllable: an administrator can disable it in the tenant's sharing settings.

In the Microsoft 365 admin center, under Settings, Org settings, Security & privacy, Baseline security mode offers, in its Authentication section, to block access to Exchange Web Services. Enable it only if your migration from older Exchange versions is complete and no line-of-business application still calls this protocol. An inventory of clients before switching avoids breaking a forgotten connector.

Implementation

Policy plans have no API documentation that I could verify. The script below therefore handles a classic Conditional Access policy via Microsoft Graph PowerShell: it creates, in report-only mode, the blocking of legacy clients (Exchange ActiveSync and other legacy protocols), with a break-glass account group excluded.

• Module: Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser (and Microsoft.Graph.Reports for verification).
• Minimum role: Conditional Access Administrator.
• Scopes: Policy.ReadWrite.ConditionalAccess, Policy.Read.All and Application.Read.All.
• Output: the ID, name and state of the created policy, or the JSON body in simulation mode.

1#Requires -Modules Microsoft.Graph.Identity.SignIns
2[CmdletBinding()]
3param(
4    # Identifiant du groupe de comptes de secours à exclure (à remplacer)
5    [Parameter(Mandatory)][string]$BreakGlassGroupId,
6    [string]$PolicyName = 'CA-BLOCK-LEGACY-AUTH-REPORT-ONLY',
7    # Simulation : affiche le corps sans rien créer
8    [switch]$DryRun
9)
10 
11Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess','Policy.Read.All','Application.Read.All' -NoWelcome
12 
13# Évite de créer un doublon
14$existing = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.DisplayName -eq $PolicyName }
15if ($existing) {
16    throw ('Une stratégie nommée {0} existe déjà (Id {1}).' -f $PolicyName, $existing.Id)
17}
18 
19# Stratégie en mode rapport seul : évaluée et journalisée, jamais appliquée
20$body = @{
21    displayName = $PolicyName
22    state       = 'enabledForReportingButNotEnforced'
23    conditions  = @{
24        clientAppTypes = @('exchangeActiveSync', 'other')
25        applications   = @{ includeApplications = @('All') }
26        users          = @{
27            includeUsers  = @('All')
28            excludeGroups = @($BreakGlassGroupId)
29        }
30    }
31    grantControls = @{
32        operator        = 'OR'
33        builtInControls = @('block')
34    }
35}
36 
37if ($DryRun) {
38    Write-Host 'Mode simulation : aucune stratégie créée. Corps de la requête :'
39    $body | ConvertTo-Json -Depth 6
40    return
41}
42 
43$created = New-MgIdentityConditionalAccessPolicy -BodyParameter $body
44$created | Select-Object Id, DisplayName, State

First run .\New-CaLegacyAuthReportOnly.ps1 -BreakGlassGroupId '<group GUID>' -DryRun, then run it again without -DryRun. The expected state in the output is enabledForReportingButNotEnforced.

Check what the policy would have blocked

The following block aggregates the policy's results in the sign-in logs (Reports Reader role, AuditLog.Read.All scope). A reportOnlyFailure result denotes a sign-in that would have been blocked. An empty output means no sign-in in this sample concerned the policy; a delay before entries appear in the logs is possible.

1$policyName = 'CA-BLOCK-LEGACY-AUTH-REPORT-ONLY'
2Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome
3 
4Get-MgAuditLogSignIn -Top 200 |
5    ForEach-Object {
6        $signIn = $_
7        $signIn.AppliedConditionalAccessPolicies |
8            Where-Object { $_.DisplayName -eq $policyName } |
9            ForEach-Object {
10                [pscustomobject]@{
11                    Utilisateur = $signIn.UserPrincipalName
12                    Application = $signIn.AppDisplayName
13                    ClientApp   = $signIn.ClientAppUsed
14                    Resultat    = $_.Result
15                }
16            }
17    } |
18    Group-Object -Property Resultat |
19    Select-Object Name, Count

When the results are clean (no legitimate usage blocked), move to enforcement with the block below.

1# Remplacez par l’Id affiché à la création
2$policyId = '<Id de la stratégie>'
3Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -BodyParameter @{ state = 'enabled' }
4Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId | Select-Object DisplayName, State

Troubleshooting

Frequently asked questions

Which license is needed for risk conditions in a policy?

Risk-based conditions (user risk and sign-in risk) rely on Identity Protection and require Microsoft Entra ID P2. The editor's other conditions were not confirmed for licensing in the sources consulted.

Are policy plans generally available?

The status is not confirmed: no official documentation page consulted describes this feature. Watch the Entra release notes, which specify the status of each feature (preview or general availability).

Why are my developers getting an MFA prompt they didn't have before?

Since June 15, 2026, policies targeting All resources with resource exclusions also apply to sign-ins that request only baseline scopes, such as VS Code or Azure CLI with User.Read. The Baseline scopes settings let you adjust or postpone this behavior.

Do my custom controls stop working immediately?

No. Their retirement is set for September 30, 2026 and their end of life for May 2027, but existing configurations continue to work during the transition. The migration to External MFA must still be planned.

Where to start: four ordered checks

Start with what affects your users today, then move on to what is coming.

1. List your All resources policies with exclusions and compare them with the MFA prompts observed since June 15, 2026.
2. Inventory your Custom controls and plan their migration to External MFA before May 2027.
3. Decide whether users can register agent identity blueprints, then adjust the default setting.
4. Test any new rule in report-only mode, with the script above or a policy plan.

If your organization is already experimenting with AI agents, then handle agent targeting and the blueprint setting before policy plans: they are what expose your tenant the most. If it still uses Exchange Web Services for line-of-business applications, postpone the Baseline security mode block until the inventory is complete. To follow the overall calendar, our review of Microsoft 365 news for July 2026 completes this overview.

Going further

• Microsoft Entra releases and announcements (What’s new): the monthly Entra release notes, with the status of each feature.
• Improved enforcement for All resources policies with resource exclusions: the enforcement change since June 2026 and the settings to control it.
• Microsoft Entra ID security updates: What organizations need to do now: the deadlines to prepare for, including the retirement of Custom controls.
• Conditional Access: Conditions: the reference on conditions and those that have become deprecated.