Conditional Access All resources exclusions: test the 2026 change

Microsoft Entra Conditional Access now enforces policies that target All resources and have one or more resource exclusions on sign-ins that request only baseline scopes, such as openid, profile or User.Read. Those sign-ins used to skip the policy entirely; now they are evaluated as directory access against Windows Azure Active Directory, so users of apps like Azure CLI, the Visual Studio Code desktop client or an excluded web app that only reads the user profile can suddenly be asked for MFA, a compliant device or be blocked. To find out which apps break, list your affected policies, use the Customize behavior setting with a placeholder application to log the affected sign-ins, test those apps, and then choose between full enforcement and a targeted exception.

Who this is for and what you will have at the end

This guide is for Conditional Access administrators in tenants that use All resources policies with exclusions, typically a "require compliant device for all resources except X" or "block everything except Y" design. It is also for help desk leads investigating new MFA or device prompts that appeared after June 2026.

At the end you will have:

• A list of the policies that the change touches.
• A sign-in-log based list of the client applications that request only baseline scopes.
• A decision for each app: accept enforcement, change the app's scopes, or keep the legacy behavior with a placeholder exclusion.
• The tenant-wide setting chosen deliberately rather than by default.

What changed and when

The message center post was addressed to tenants where Microsoft's telemetry found at least one All resources policy with one or more resource exclusions.

The baseline scopes

• OIDC scopes: email, offline_access, openid, profile
• Baseline directory scopes: User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden

What is now enforced, and what isn't

The last row is why most tenants see little impact: most apps ask for more than the baseline and were already evaluated.

Prerequisites

• Conditional Access Administrator to change the Baseline scopes settings and policies.
• Reports Reader, Security Reader or Global Reader to read sign-in logs. To see applied Conditional Access policies through the Microsoft Graph sign-ins API, the account needs Global Reader, Security Reader, Security Administrator or Conditional Access Administrator.
• Microsoft Graph PowerShell with Policy.Read.All, Application.Read.All and AuditLog.Read.All, or Graph Explorer.
• Rights to register an application if you plan to use Customize behavior.

Step 1: Find the policies in scope

Microsoft publishes a Graph filter that lists policies targeting All resources with at least one exclusion:

GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies?$filter=conditions/applications/includeApplications/any(a:a eq 'All') and conditions/applications/excludeApplications/any()&$select=id,displayName

The same check in PowerShell, with the excluded resources resolved to names so you can see what each exception was for:

Connect-MgGraph -Scopes 'Policy.Read.All', 'Application.Read.All'
 
$policies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.Conditions.Applications.IncludeApplications -contains 'All' -and
    @($_.Conditions.Applications.ExcludeApplications).Count -gt 0
}
 
foreach ($p in $policies) {
    $excluded = foreach ($id in $p.Conditions.Applications.ExcludeApplications) {
        if ($id -match '^[0-9a-fA-F-]{36}$') {
            $sp = Get-MgServicePrincipal -Filter "appId eq '$id'"
            if ($sp) { "$($sp.DisplayName) ($id)" } else { $id }
        } else { $id }
    }
    [pscustomobject]@{
        Policy   = $p.DisplayName
        State    = $p.State
        Grant    = ($p.GrantControls.BuiltInControls -join ', ')
        Excluded = ($excluded -join '; ')
    }
}

If the list is empty, the change doesn't affect you. If it isn't, note the grant control of each policy. Block, require compliant device and require app protection policy are the controls most likely to stop a user outright; require MFA usually means one extra prompt.

Step 2: Log the sign-ins that would be affected

The documented way to identify affected applications in a production tenant is to temporarily route baseline scopes to a placeholder application with Customize behavior. While it is in place, the legacy behavior applies to the policies that exclude the placeholder, and every sign-in that requests only baseline scopes lists the placeholder as a Conditional Access audience in the sign-in logs.

1. Register a new single-tenant application, for example CA-BaselineScopes-Placeholder. No further configuration is needed. Record its application (client) ID.
2. In each policy from Step 1 where you want to keep the old behavior during testing, add the placeholder application to Target resources > Exclude.
3. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator and open https://aka.ms/BaselineScopesSettingsUX. The settings are only reachable through this direct link.
4. Select Customize behavior, select Save, and choose the placeholder application.

Collect sign-ins over several working days so that weekly and monthly tasks show up, then query them:

Connect-MgGraph -Scopes 'AuditLog.Read.All'
 
$placeholder = '<placeholder-app-id>'
$filter = "createdDateTime ge 2026-10-01T00:00:00Z and createdDateTime lt 2026-10-15T00:00:00Z " +
          "and conditionalAccessAudiences/any(a:a eq '$placeholder')"
 
Get-MgBetaAuditLogSignIn -Filter $filter -All |
    Group-Object AppId, AppDisplayName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Get-MgBetaAuditLogSignIn is in the Microsoft.Graph.Beta.Reports module. The beta sign-ins API returns interactive sign-ins unless you filter on signInEventTypes, which is usually what you want here because the prompts land on interactive sign-ins. The result is your list of client applications that request only baseline scopes.

Step 3: Classify each application

For any application your organization owns, confirm it can handle a Conditional Access challenge (MFA, device compliance). An app that requests tokens silently and can't show an interactive prompt will fail where it used to succeed; Microsoft's Conditional Access developer guidance covers the required changes.

Microsoft lists the scenarios where keeping the legacy behavior can be justified:

• An All resources policy that requires a compliant device, with specific apps that must work from unmanaged devices.
• An All resources policy that requires an app protection policy, with client apps that don't integrate the Intune SDK.
• An All resources block policy with specific apps that must stay reachable.
• Public clients that must be exempt from device compliance requirements.

Step 4: Test the enforced behavior

Test with real users of each app from Step 2:

1. In a test tenant (the setting is tenant-wide), select Enable enforcement on the Baseline scopes settings page, select Save, then confirm.
2. Sign in to each application with a pilot account that matches the policy's conditions (device state, location, user group).
3. Record the experience: no change, extra MFA prompt, device compliance block, or outright failure.
4. For each failure, open the sign-in event, select the Conditional Access tab, select the policy and check Audience under the resource section. Windows Azure Active Directory in the audience list confirms the sign-in was caught by this change.

Enable enforcement applies the new behavior to all All resources policies with exclusions immediately, so use a test tenant when you can. To revert, select Disable enforcement.

If your sign-in logs go to Log Analytics, this query surfaces failed sign-ins whose Conditional Access audiences include Windows Azure Active Directory:

SigninLogs
| where TimeGenerated > ago(14d)
| where ConditionalAccessStatus == "failure"
| where ConditionalAccessAudiences has "00000002-0000-0000-c000-000000000000"
| summarize Failures = count(), Users = dcount(UserPrincipalName) by AppDisplayName, AppId, ResultType
| order by Failures desc

Step 5: Choose the tenant setting

The rollout doesn't override a choice you made, and you can change the setting at any time. If you choose Customize behavior permanently, remove the placeholder exclusion from every policy where you no longer need it; any policy that excludes it keeps the old gap.

Step 6: Fix the design behind the exclusions

Microsoft's long-term recommendation is a baseline MFA policy for all users and All resources with no resource exclusions. Exclusions in an All resources policy were often added to let one app through a device or block control; consider moving those requirements into separate policies that target named resources, so the baseline MFA policy can stay exclusion-free. Applications that are compliant-device exceptions are also good candidates for review in a wider Zero Trust access design.

Verify

• Rerun the Step 1 script after changes and confirm every remaining exclusion is documented.
• Rerun the Step 2 sign-in query after a week; only the apps you consciously exempted should appear against the placeholder.
• Spot-check sign-ins for Azure CLI and Visual Studio Code: they should now show the policy as applied rather than not applied.
• Confirm the Baseline scopes settings page shows the option you chose. If enforcement was applied by default, no option appears selected because enforcement is the default behavior.

Troubleshooting

Users of an excluded web app now see AADSTS53000 (DeviceNotCompliant) from unmanaged devices. The app requests only baseline directory scopes and the All resources policy requires a compliant device. Ask the developer to request OIDC scopes only, or add a placeholder exclusion with Customize behavior for that policy.

AADSTS53003 (BlockedByConditionalAccess) for a tool that used to work. A block policy targeting All resources with exclusions now applies to the tool's baseline-scope sign-in. Confirm with the Audience list in the sign-in event, then decide whether the tool should be allowed.

Azure CLI asks for MFA at az login. Expected: Azure CLI requests only User.Read. This also helps with Azure mandatory MFA for resource changes; see fixing Azure CLI, PowerShell and Terraform sign-ins.

AADSTS53009 (Application needs to enforce Intune protection policies). An All resources policy requiring an app protection policy now applies to a client that doesn't integrate the Intune SDK. Exempt it through Customize behavior or change the policy design.

The placeholder app never appears in sign-in logs. Check that Customize behavior is saved with the right application, that the placeholder is excluded from the policies you are testing, and that your query's time range starts after you made the change.

You never received MC1223829. The notice was addressed to tenants where telemetry found an All resources policy with a resource exclusion, so your tenant probably had none at the time. Rerun Step 1 anyway, and again before you add an exclusion.

Checklist

• Policies targeting All resources with exclusions listed, with each exclusion's purpose recorded.
• Placeholder application registered and Customize behavior used to log affected sign-ins for several days.
• Each affected app classified: accept, switch to OIDC scopes, or exempt with a documented reason.
• Own applications confirmed to handle Conditional Access challenges.
• Enforcement tested in a test tenant or with pilot users.
• Tenant setting set deliberately; Disable enforcement used only as a short-term measure.
• Plan in place for a baseline MFA policy for all users and All resources without exclusions.

References

• Enforcement for baseline scopes in Conditional Access
• Targeting resources in Conditional Access policies
• Troubleshooting sign-in problems with Conditional Access
• MC1223829: Upcoming Conditional Access change, improved enforcement for policies with resource exclusions
• Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions (Microsoft Entra blog)
• List Conditional Access policies (Microsoft Graph)
• Get-MgIdentityConditionalAccessPolicy
• Get-MgServicePrincipal
• List signIns (Microsoft Graph beta)
• SigninLogs table reference