If an app in your tenant suddenly started prompting for MFA or failing with a device compliance error in mid-2026 and nobody touched a Conditional Access policy, you probably met Microsoft's baseline scopes enforcement change. Conditional Access policies that target All resources but carry one or more resource exclusions used to skip sign-ins that asked only for OpenID Connect or a few basic directory scopes; now those sign-ins are evaluated like everything else. In this post I'll explain what changed, who is affected, what breaks, how to find and fix the affected apps, and how to verify.
Status (October 2026): Microsoft announced the change in January 2026 (Message center MC1223829). After two date changes, Microsoft Learn gives 15 June 2026 as the start of a progressive rollout over several weeks, with per-tenant notices two weeks before and after. By now the new behaviour should be the default in tenants that didn't opt out; tenants that chose Customize behavior or Disable enforcement keep that setting until they change it. Re-check the Learn page, because Microsoft updates it.
What is changing#
Microsoft calls the affected permissions baseline scopes: the OIDC scopes openid, profile, email and offline_access, plus the baseline directory scopes User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All and Member.Read.Hidden. Previously, when an All resources policy had any resource exclusion, a sign-in that requested only these scopes wasn't evaluated against that policy at all; the request didn't map to a protected resource, so the user got a token without MFA or device checks. After the change, such requests are treated as directory access and evaluated with Windows Azure Active Directory (Azure AD Graph) as the Conditional Access audience, so every All resources policy, with or without exclusions, and any policy that explicitly targets that resource, now applies. Microsoft frames it as closing a gap under its Secure Future Initiative.
Who is affected#
All three conditions must be true: you have at least one Conditional Access policy targeting All resources, that policy has one or more resource exclusions, and users sign in through apps that request only baseline scopes. Microsoft's own examples are the Visual Studio Code desktop client (openid and profile) and Azure CLI (only User.Read). Two groups of apps change behaviour:
- Public clients (desktop, mobile, CLI) that request only baseline scopes, whether or not they're excluded anywhere.
- Confidential clients (web apps) that are excluded from an All resources policy and request only baseline directory scopes such as
User.Read.
Nothing changes for apps that request any other scope (for example Mail.Read or Files.Read), because they were already evaluated against the real resource, nor for confidential clients that request only OIDC scopes, nor for tenants whose All resources policies have no exclusions. Most apps request more than baseline scopes, which is why Microsoft says most organisations need no action.
What breaks if you do nothing#
- Users see new MFA prompts in tools they used to open silently, such as Azure CLI or VS Code. Many won't notice because the device already satisfied MFA for something else, but a client that starts a fresh session every time will prompt every time.
- Policies that require a compliant device or an app protection policy, or that block access, now bite those sign-ins. An OIDC-only line-of-business app used from unmanaged devices under a compliant-device policy fails outright.
- Custom apps written to request only
openidandprofileand not built to handle a Conditional Access claims challenge return an error instead of stepping the user up.
What to do now#
1. Find the policies in scope#
In the Microsoft Entra admin center go to Entra ID › Conditional Access › Policies and open each policy whose target resources are All resources; note any entries under Exclude. If none of your All resources policies exclude anything, you're done.
2. Find the apps#
Review the excluded apps first; Microsoft recommends that as the quickest route. Then look at the sign-in logs: open Entra ID › Monitoring & health › Sign-in logs, filter by application, and open an event's Conditional Access tab to see which policies were evaluated and the result. After enforcement, sign-ins that only requested baseline scopes show Windows Azure Active Directory as the audience. If you use the Customize behavior option (step 4), the placeholder app you registered appears as the Conditional Access audience instead, which gives you a clean filter. Microsoft publishes a Graph query for exactly that; it uses the beta sign-in log endpoint:
GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-09-01T00:00:00Z and createdDateTime lt 2026-09-02T00:00:00Z and conditionalAccessAudiences/any(a:a eq '<your-custom-app-id>')&$select=createdDateTime,appId,appDisplayName,userDisplayName,userPrincipalName,ipAddress,conditionalAccessStatusRun it over several days and you have the list of client apps that request only baseline scopes.
3. Decide per app#
| App type | Action |
|---|---|
| Public client, only baseline scopes | Decide whether it really should bypass Conditional Access. Usually no; if there's a business case, use Customize behavior for that policy. |
| Confidential client, excluded, only directory scopes (tenant-owned) | Ask the developers to request openid and profile instead of User.Read for basic profile data; OIDC-only confidential clients aren't affected. |
| Confidential client, excluded, only directory scopes (ISV-owned) | Ask the vendor the same question; if they can't ship in time, use Customize behavior. |
| Any tenant-owned app | Make sure it handles Conditional Access challenges: with MSAL, catch the UI-required exception and call the interactive acquire-token method with the returned claims value; web apps should pass the claims challenge back to the authorize request. Replace anything still on ADAL. |
4. Choose how enforcement lands#
The Baseline scopes settings page in Conditional Access is reachable only through the direct link https://aka.ms/BaselineScopesSettingsUX (a Conditional Access Administrator can change it). Enable enforcement switches the new behaviour on immediately; use it in a test tenant to see the impact early. Customize behavior keeps the legacy behaviour for specific policies: register a single-tenant placeholder application, exclude it from the policy that needs the old behaviour, then select it in the settings page; baseline scopes are evaluated against that app, and because it's excluded, that policy skips them while every other policy enforces. Disable enforcement turns it off tenant-wide, and Microsoft explicitly doesn't recommend it. If you pick Customize or Disable, the rollout won't override your choice.
How to verify#
- Sign in with a test account through Azure CLI (
az login) on a device that hasn't satisfied MFA. Under an All resources MFA policy with an exclusion you should now be prompted; the sign-in log event shows the policy as applied with Windows Azure Active Directory as the target. - For a confidential client you changed to OIDC-only scopes, confirm the sign-in log shows no Conditional Access challenge and the app still gets the profile claims it needs.
- Re-run the Graph query after a week; whatever remains is either accepted or covered by Customize behavior.
- Open the Baseline scopes settings page: once the rollout has applied enforcement, no option shows as selected, because the behaviour is now the default.
Timeline#
| Date | Event |
|---|---|
| 29 January 2026 | MC1223829 sent to tenants with All resources policies that have exclusions; the original notice gave 27 March 2026 as the start |
| Spring 2026 | Start date moved to 13 May and then to 15 June 2026; Baseline scopes settings and Learn guidance published |
| 15 June 2026 onwards | Progressive rollout over several weeks; MC1400649 gave individual tenants two weeks' notice |
| October 2026 | Default behaviour for tenants that didn't opt out; the settings remain changeable at any time |
The broader lesson is the mindset Microsoft is pushing: assume every sign-in is evaluated. An exclusion should exempt a specific resource for a specific reason, not become a side door that any client can walk through by asking for less. Review your exclusions, keep a report-only copy of your All resources policies to watch for surprises, and treat "the app only asks for openid" as a reason to tighten, not to exempt.