An empty Baseline scopes settings page proves nothing about the enforcement rollout
A Conditional Access policy targeting All resources with a resource exclusion now enforces on sign-ins requesting only baseline scopes, and the Baseline scopes settings page renders empty whether or not the rollout reached the tenant. Inventory the policy shape, the only part a read-only call can measure.
Since 15 June 2026, a Conditional Access policy targeting All resources that carries a resource exclusion no longer exempts sign-ins requesting only baseline scopes. They are evaluated as directory access instead, and the page that appears to report this renders empty in both tenant states.
Last verified: 2026-08-20.
What Microsoft states
The enforcement page, read on 2026-08-20, sets the schedule: "The rollout begins on June 15, 2026, and will be rolled out progressively over several weeks."
The mechanism is on the Target resources page, where baseline scopes "are now evaluated as directory access and mapped to Azure AD Graph (resource: Windows Azure Active Directory, ID: 00000002-0000-0000-c000-000000000000)". The request is identical before and after; only the audience it is evaluated against differs. Microsoft's examples are Visual Studio Code and Azure CLI, "which requests only User.Read", each moving from no MFA prompt to an MFA prompt.
sequenceDiagram accTitle: One unchanged sign-in before and after baseline scope enforcement accDescr: The same token request for openid and profile is sent in both phases. Before enforcement the resource exclusion exempts it and a token is issued with no challenge. After enforcement the identical request is evaluated as directory access and the user is challenged. participant C as Client participant E as Entra Note over C,E: Before C->>E: openid, profile only E-->>C: Exempt, token Note over C,E: After C->>E: openid, profile only E-->>C: Directory access, MFA
Two Microsoft pages give two rollout dates
| Source, read 2026-08-20 | Timing | Who is affected |
|---|---|---|
| Enforcement page | "begins on June 15, 2026" | "This enforcement change is applied to all tenants as part of the rollout." |
| Target resources page | "The change is rolling out in phases starting in March, 2026." | No tenant scope. |
| Microsoft Entra blog | "enforcement now starting on June 15, 2026" | "Tenants without this policy configuration will not be impacted." |
Plan against 15 June 2026, the date on the dedicated page and on the Entra blog. The March wording sits on the page cited as background, so an administrator arriving by the documented route reads a rollout that started five months ago.
Why the settings page answers nothing
The FAQ says: "You won't see any selections in the Baseline scopes settings after enforcement is applied because the behavior becomes the default." The next sentence gives the mechanism away: "If you previously chose Disable enforcement or Customize behavior, your tenant continues to use your selected configuration."
Only a deliberate override is a selection. A tenant the rollout has not reached made none, and a tenant where enforcement became the default made none either. The panel is a write-only override register, not a state readout.
The page also needs a direct link: "This direct link is required to view the settings." Measured 2026-08-20, the short link answers HTTP 301 to an address carrying feature.isbaselinescopesenabled=true, so navigation does not reach it.
Prerequisites
- Conditional Access in the tenant. Microsoft's developer guidance says it "is a feature included in Microsoft Entra ID P1 or P2", with Microsoft 365 Business licences also covered.
- Delegated
Policy.Read.All, which Microsoft lists as least privileged for this operation, with "Not available." in the higher privileged column. - A role granting that read without a write. Microsoft lists five; ask for Security Reader or Global Reader, since Conditional Access Administrator can also write policies.
- The Microsoft Graph PowerShell module.
The read-only check
The enforcement state cannot be read. The policy shape can, and it is the only precondition an operator controls. The output says nothing about which applications request only baseline scopes.
# Read-only. Lists policies and filters in memory. Nothing here writes any object.
Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome
Get-MgIdentityConditionalAccessPolicy -All |
Where-Object {
$_.Conditions.Applications.IncludeApplications -contains 'All' -and
$_.Conditions.Applications.ExcludeApplications.Count -gt 0
} |
Select-Object DisplayName, State,
@{ n = 'ExcludedResources'; e = { $_.Conditions.Applications.ExcludeApplications -join ', ' } },
@{ n = 'GrantControls'; e = { $_.GrantControls.BuiltInControls -join ', ' } } |
Format-Table -AutoSize
Disconnect-MgGraph
Expected output
One row per policy in scope, or none at all. No rows means no All resources policy carries a resource exclusion, which Microsoft states is unaffected, though that describes today's configuration rather than a permanent exemption.
Rows mean three columns read together. State: only an enabled policy challenges anyone. ExcludedResources: the list whose exemption no longer covers baseline-scope sign-ins. GrantControls: mfa is a prompt, compliantDevice is a hard failure for any client that cannot satisfy it, block is a denial.
Side effects
None from the check, which acquires a read scope and filters locally. The writes sit on the settings page: Microsoft says of the first option that it "immediately enables the updated Conditional Access behavior for All resources policies with exclusions". The Customize behavior option requires registering an application in the tenant.
Rollback
Nothing to roll back from the check. Disable enforcement returns the tenant to the legacy behaviour, at a cost Microsoft prints: "Selecting this option disables enforcement for all policies in the tenant, which could create gaps in your Conditional Access coverage." Customize behavior retains it per policy through a single-tenant application excluded from that policy. Either survives the schedule: "the upcoming rollout will not override your configured behavior."
Limitations
The check measures policy shape. It does not measure enforcement state, which no documented Graph endpoint or cmdlet returns, and the settings page carries no applied date. The enforcement page does publish one Graph query, a beta auditLogs/signIns filter on conditionalAccessAudiences, but it answers a different question: it lists applications that requested only baseline scopes AFTER an administrator selected Enable enforcement and named a custom application, so it reports on a configuration somebody already chose rather than on whether the rollout has arrived. The only evidence enforcement is live is a sign-in log entry naming Windows Azure Active Directory as the audience, and that is bounded: "Only sign-in events that occurred within the Microsoft Entra ID default retention period are available."
Microsoft's identification query runs on the beta sign-in logs endpoint and filters on a custom application ID that exists only after Customize behavior is configured, so following that section from its own first step yields a query with nothing to filter on.
The two Learn pages differ on which scopes count as baseline for public clients, so neither list is definitive for both client types. No page read in this pass states sovereign cloud applicability.
Decision: Act now
Act now, on a narrow action: run the shape inventory this week and file the result with its date. The trigger is a default already live: the rollout opened on 15 June 2026 and is progressive. There is nothing to wait for, because no API returns the state. Monitor fails on its own terms: the only thing to watch is a log entry that appears after the first user has been challenged.
The Microsoft 365 tenant hardening service is where a Conditional Access inventory like this gets a named owner and a dated record.
Tenant Monitor's monthly read carries the tenant's Conditional Access and MFA posture alongside the licence and app findings, which is where a silent default change like this one would first surface as a dated record, from Tenant Monitor.
Sources and further reading
- Improved enforcement for All resources policies with resource exclusions
- Conditional Access: Target resources
- Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions
- List policies (conditionalAccessRoot)
- List signIns
- Developer guidance for Microsoft Entra Conditional Access
Turn the procedure into a tenant decision.
The Architecture Workshop maps the checks, side effects, and rollback path to your own Microsoft 365 environment.
Review the workshopMore from Ops Log
A Microsoft 365 DKIM CNAME target has two documented formats: read it per domain, never build it
Microsoft documents two DKIM CNAME target formats for Microsoft 365 custom domains, one ending in onmicrosoft.com and one in dkim.mail.microsoft. The page splits them by new versus existing custom domain and never mentions tenant age. Read each domain's values with Get-DkimSigningConfig.
The Azure role called Cost Management Reader is not read-only
Cost Management Reader is described as able to view cost data, yet its action list carries a Microsoft.Support wildcard that includes creating and updating support tickets. The built-in Reader role matches it on every Cost Management feature and cannot write a ticket.
Google's admin.directory.user.security scope has no read-only form
Google publishes no read-only form of the admin.directory.user.security scope. The scope that lists a user's OAuth tokens and app passwords is the same scope that deletes them, so treat any grant of it as a write permission when reviewing a third-party app.