Conditional Access on All resources: the baseline scopes exemption ends on 15 June

The timeline is already well covered (announced 29 January with a March date, moved to 13 May, then to 15 June), so I'll stick to the mechanics. The Learn section that describes them used to be called "Conditional Access behavior when an all resources policy has an app exclusion" and now lives on as the legacy behavior section of the target resources article. The rule was: if any app is excluded from an All resources policy, certain low-privilege scopes are excluded from enforcement of that policy. The reasoning was practical: nearly every client asks for User.Read next to its real resource (Outlook does it with its Exchange token, to show who is signed in), and an excluded app wouldn't work if that part of the request was still held to the policy.

The list is split by client type, and the condition differs between the two:

• Native clients and SPAs: Azure AD Graph email, offline_access, openid, profile, User.Read, and on Microsoft Graph the same plus People.Read.
• Confidential clients, "if they're excluded from an All resources policy": additionally User.Read.All and User.ReadBasic.All, and on Microsoft Graph also People.Read.All, GroupMember.Read.All and Member.Read.Hidden.

The "if they're excluded" qualifier only sits on the confidential client line. For public clients the trigger was any exclusion in the policy. Exclude one SaaS app because it can't cope with your compliant device requirement, and every public client in the tenant that requests nothing beyond those scopes walks past that policy. That is why Microsoft's own examples in the new guidance are Visual Studio Code (which asks for openid and profile) and Azure CLI (which asks for only User.Read at sign-in). Neither is excluded in a typical tenant; it was the exclusion of an unrelated app that let them through.

What came through that gap was limited. The tokens give access to your own profile, and for an excluded confidential client to user and group membership reads across the directory. A follow-up token for a real resource (Exchange, SharePoint, Azure Resource Manager) is still evaluated against your policies at that point, so this was never a full bypass. But a sign-in that succeeds without the MFA or compliant device your baseline policy asks for also confirms to whoever holds the password that it works, and directory reads are the usual first step of reconnaissance. Microsoft has long recommended a baseline MFA policy on All resources without exclusions; the documented workaround for protecting directory data was a separate policy on Windows Azure Active Directory (00000002-0000-0000-c000-000000000000), selected through a custom security attribute filter because that resource doesn't appear in the app picker.

After the rollout, baseline scopes (Microsoft's umbrella term for the four OIDC scopes plus User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All and Member.Read.Hidden) are evaluated as directory access and mapped to Azure AD Graph, the Windows Azure Active Directory resource, as the Conditional Access audience. Policies on All resources with exclusions, and policies that explicitly target Azure AD Graph, are then enforced for sign-ins that request only these scopes. A client that requests even one scope outside the list doesn't change: it was already evaluated against the resource it asked for. An excluded confidential client that asks only for OIDC scopes doesn't change either.

Microsoft's list of scenarios that justify keeping the legacy behavior shows where this causes problems, and it matches the policy sets I see in larger environments: an All resources policy with Require compliant device and an excluded app that has to work from unmanaged devices, an All resources policy with Require app protection policy and clients that don't integrate the Intune SDK, block policies with exclusions, and public clients that were deliberately kept away from device compliance. In each of those, a sign-in that requested only baseline scopes used to succeed, and from the rollout onwards it has to satisfy the policy. For apps you build yourself, check that they handle a Conditional Access challenge (developer guidance), and for a confidential client that only needs the user's name and email, switching from User.Read to openid and profile keeps it out of scope entirely.

The rollout is progressive over several weeks. Since the 5 June revision of MC1223829, Microsoft says you get another Message Center post two weeks before the rollout reaches your tenant and one after it completes.

Start with the policies. Anything that includes All and has at least one entry in excludeApplications is in scope. An exclusion of Office365 or MicrosoftAdminPortals counts as a resource exclusion as well.

Pay most attention to results where Grant contains compliantDevice, compliantApplication or block.

For the sign-ins themselves there are two routes. Without changing anything, Log Analytics already shows candidates: sign-ins to Microsoft Graph or Windows Azure Active Directory where your All resources policy reports notApplied. ConditionalAccessPolicies is a dynamic column in SigninLogs and a string in AADNonInteractiveUserSignInLogs, hence the parse_json on one side.

Treat the output as a candidate list: notApplied also appears when the user is excluded or a condition such as platform or location didn't match. The precise route goes through the new settings page.

The configuration arrived with the 15 April revision of MC1223829: guidance at aka.ms/BaselineScopesSettings and the page itself at aka.ms/BaselineScopesSettingsUX. You won't find it by clicking through the Conditional Access blade; the direct link is required, and you need at least Conditional Access Administrator. There are three options.

Enable enforcement switches to the new behavior right away, ahead of the rollout. Microsoft suggests trying it in a test tenant first. Disable enforcement keeps the legacy behavior for every policy in the tenant. Microsoft describes it as a temporary opt-out and doesn't recommend it, but hasn't published an end date for it. Whatever you choose here is not overridden by the rollout. If you choose nothing, enforcement is applied automatically and the page shows no selection afterwards, because enforcement has become the default.

Customize behavior takes more explanation. You register a single-tenant application (no further configuration needed), exclude it from the policies where you want to keep the legacy behavior, and select it on the settings page as the target for baseline scopes. Baseline-scope-only sign-ins are then evaluated against your placeholder app instead of Windows Azure Active Directory. Where the placeholder is excluded, the policy doesn't apply, which gives you the old behavior per policy. Everywhere else enforcement applies.

Two things follow from that design. First, Microsoft's wording implies that selecting Customize behavior before 15 June turns on enforcement for every policy that doesn't exclude the placeholder (Learn doesn't say in so many words that it takes effect ahead of the rollout), so treat it as live from the moment you save; it doesn't leave everything as it is. Second, the placeholder becomes a marker in your logs: every sign-in that requested only baseline scopes lists its app ID as a Conditional Access audience. The Learn page currently says this happens "after selecting the Enable enforcement option", but in that mode there is no custom application to show, so read it as Customize behavior.

That gives a clean measurement setup. Exclude the placeholder from exactly the All resources policies that already have exclusions, select Customize behavior, and your effective behavior stays legacy while the logs record every affected sign-in. Then:

After a week or two you have the real list. Fix what you own, talk to the vendors of what you don't, remove the placeholder exclusion policy by policy, and finish with Enable enforcement.

The Require approved client app grant retires on 30 June 2026, the same month and often in the same policy set. Microsoft's messaging about it has shifted along the way. MC1220751 in January said a policy with only this grant would behave as if the grant wasn't selected. The migration article was rewritten at the end of May and now says the control, and every policy that uses it, goes read-only on 30 June: no creating or editing, disabling and deleting still possible, and existing enabled policies keep being enforced. The practical consequence of the newer wording is that after 30 June you can no longer fix such a policy in place. Migrate before then: Require approved client app or Require app protection policy with Require one of the selected controls for existing policies, and Require app protection policy alone for new ones. That grant only works if an Intune app protection policy actually exists for those apps and users; without one, users are blocked. approvedApplication without compliantApplication in the Grant column of the script above shows you which policies still need it.

My suggestion for this week: run the policy script, list every exclusion on a policy with compliant device, app protection or block, and if there are any, set up the placeholder app with Customize behavior before 15 June so you have the list of affected sign-ins from your logs before the first users call the service desk.

• MC1223829: Conditional Access enforcement for All resources policies with resource exclusions
• Improved enforcement for All resources policies with resource exclusions
• Conditional Access target resources: legacy behavior when an All resources policy has a resource exclusion
• Require MFA strength for all users
• Developer guidance for Conditional Access
• Baseline scopes settings guidance (aka.ms/BaselineScopesSettings)
• SigninLogs table reference
• AADNonInteractiveUserSignInLogs table reference
• MC1220751: retirement of the Require approved client app grant
• Migrate approved client app to application protection policy in Conditional Access