An empty Baseline scopes settings page proves nothing about the enforcement rollout

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 appears in both lanes. Before enforcement an exclusion exempts baseline scopes, evaluation is skipped and a token is issued. After enforcement the identical request is evaluated against Windows Azure Active Directory and the user is challenged.
  participant C as Client app
  participant E as Microsoft Entra
  participant CA as Conditional Access
  Note over C,CA: Before enforcement
  C->>E: Token request, scopes openid and profile only
  E->>CA: Match All resources policy
  CA-->>E: Exclusion present, baseline scopes exempt, evaluation skipped
  E-->>C: Token issued, no challenge
  Note over C,CA: After enforcement
  C->>E: Token request, scopes openid and profile only
  E->>CA: Evaluate against audience Windows Azure Active Directory 00000002-0000-0000-c000-000000000000
  CA-->>C: MFA or compliant device challenge

Two Microsoft pages give two rollout dates

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.