Microsoft updated its Learn documentation for Conditional Access with resource exclusions on 8 October 2026. The change matters for tenants that apply policies to “All resources” and exclude selected resources. Baseline scopes such as openid, profile, or User.Read were previously not enforced automatically in these constellations. Microsoft now describes an improved enforcement model: sign-ins that request only these baseline scopes are evaluated as directory access and can trigger Conditional Access requirements.
Why this change matters for SMBs
In organizations with 10 to 250 seats, Conditional Access rules often grow over several years. A common pattern is a broad policy for all resources, combined with exceptions for line-of-business applications, older clients, or administration paths. That is exactly where behavior can change: if a client requests only baseline scopes, an MFA, device, or app protection requirement can now apply, even if the same access previously worked without a challenge.
From a security perspective, the change is reasonable because Microsoft closes a gap between excluded resources and directory access. For operations, preparation is the key point. The helpdesk should know whether Visual Studio Code, Azure CLI, internal web applications, or ISV apps might suddenly present additional access requirements.
Which configurations are affected
Microsoft names three conditions that must all be true. The tenant has Conditional Access policies that target “All resources”. These policies include resource exclusions. Users sign in through applications that request only baseline scopes.
- OIDC baseline scopes such as
email,offline_access,openid, andprofile, - directory scopes such as
User.Read,User.Read.All,People.Read, orGroupMember.Read.All, - public clients such as desktop apps that request only those scopes,
- confidential clients excluded from an All resources policy that use only baseline directory scopes.
For a Conditional Access design, this means exceptions should not be reviewed only by application name. The scopes a client actually requests are equally important.
How to interpret rollout and dates
Microsoft states that rollout of the enforcement model for baseline scopes began on 15 June 2026. The Learn page was updated on 8 October 2026 and describes the change as behavior that is applied across tenants. If no setting was changed, the new enforcement is enabled automatically; after it is applied, Microsoft says no selections appear in the baseline scopes settings because the behavior becomes the default.
This is not a licensing or procurement topic. It is a technical operations review. If an organization uses Disable enforcement or Customize behavior, Microsoft says the configured deviation remains in place, but it should be documented deliberately. Microsoft recommends aligning with the new enforcement model and describes Customize behavior only for specific scenarios where legacy behavior still has to be retained.
What users might notice
The visible impact depends on the configured grant controls. A policy might require MFA, a compliant device, app protection, or other controls. Microsoft lists Visual Studio Code with openid and profile, Azure CLI with User.Read, and excluded web applications with User.Read and People.Read as examples. Before the change, the sign-in could continue without MFA; after the change, Conditional Access can evaluate Windows Azure Active Directory as the target resource.
Applications that request additional resource scopes beyond baseline scopes, such as Mail.Read or Files.Read, are not affected in the same way. Those access requests were already evaluated through the respective resource. For Microsoft 365 Consulting and daily operations, this distinction matters: not every app is affected, but affected exceptions can be business-critical.
Concrete next steps
A pragmatic review can start without a major redesign:
- Identify policies that include “All resources” and exclude resources.
- Use the Microsoft Graph query named by Microsoft to inventory affected policies.
- Review sign-in logs for applications that use only baseline scopes.
- Test tenant-owned apps to confirm they handle Conditional Access challenges cleanly.
- Clarify ISV apps that use baseline directory scopes with the vendor.
Temporary deviations should be documented tightly: which policy, which application, which reason, and which date for renewed review. A permanent global disablement is not recommended by Microsoft because it can create gaps in Conditional Access coverage.
Official Microsoft sources
- Microsoft Learn: Enforcement for baseline scopes in Conditional Access
- Microsoft Learn: Targeting resources in Conditional Access policies
- Microsoft Learn: Developer guidance for Conditional Access
If you want to check whether your Conditional Access exclusions still behave as intended, we review policies, sign-in logs, and app behavior as part of a Microsoft Security Assessment – get in touch.
What does this mean for your environment?
Assess the topic in the context of your Microsoft 365 environment and define a practical next step.
You speak directly with Sebastian Kerssen – working in the Microsoft ecosystem since 2014, with personal consulting and a dedicated point of contact.
