Conditional Access Register Security Information Windows Hello macOS Platform SSO Scope Change (July 13, 2026)

Conditional Access Register Security Information Windows Hello macOS Platform SSO: What Changed

Conditional access register security information windows hello macos platform sso — that's the mouthful Microsoft Entra admins now need to know. As of July 13, 2026, Conditional Access policies that target the Register security information user action also govern Windows Hello for Business (WHfB) and macOS Platform Single Sign-on (SSO) credential registration, whether or not you intended that when you first scoped the policy. If your tenant scoped that user action narrowly — say, only to cover the combined MFA/SSPR registration experience — WHfB and macOS Platform SSO enrollment is now unexpectedly gated by the same Grant controls. If your tenant deliberately excluded those flows to keep device provisioning frictionless, that exclusion no longer holds either: the flows are in-scope by default now.

Before this change, Windows Hello for Business and macOS Platform SSO registration didn't evaluate Conditional Access policies scoped to Register security information at all — even though a policy existed and targeted that user action, it simply wasn't consulted during WHfB/Platform SSO enrollment. Microsoft's official guidance is explicit about what did and didn't change:

Microsoft also confirmed the rollout window and impact scope in Message Center post MC1326253, "Conditional Access policies now apply to Windows Hello for Business and macOS Platform SSO registration": rollout began July 6, 2026 and completed July 13, 2026, and tenants with no Conditional Access policy targeting Register security information see no change — default MFA enforcement for passwordless credential registration is untouched.

How the Enforcement Works

The mechanism itself isn't new — it's the same Register security information user action that has governed the combined MFA/SSPR registration experience for years. What's new is that Windows Hello for Business provisioning and macOS Platform SSO registration are now routed through that same Conditional Access evaluation. Concretely, after enforcement a user registering WHfB or macOS Platform SSO credentials must satisfy whatever Grant controls the matching policy requires — authentication strength, a trusted location, a specific MFA method, or device compliance — before the registration completes.

Two details from Microsoft's guidance matter for planning your response:

• External authentication methods are currently incompatible with authentication strength as a grant control for this user action — a compatibility gap that echoes the broader Custom Controls retirement for external authentication methods already underway in Entra. If your policy pairs Register security information with an authentication-strength requirement and your tenant relies on external authentication methods, Microsoft recommends using the Require multifactor authentication grant control instead.
• Temporary Access Pass (TAP) satisfies the Conditional Access MFA requirement for registration, which is how Microsoft expects admins to bootstrap new users into WHfB/macOS Platform SSO without a chicken-and-egg problem (a user can't satisfy an MFA/auth-strength grant control with a credential they haven't registered yet). TAP does not work for guest users.

Who Gets Caught Out

This is a scope change, not a new policy you have to author — which is exactly why it's easy to miss. Two failure modes are worth checking for specifically:

1. Narrow policy, new friction. A policy scoped to Register security information with Grant: require authentication strength (built for securing MFA/SSPR enrollment) now also applies to WHfB and macOS Platform SSO. A new hire enrolling a managed Windows device off a trusted network can get blocked mid-setup because they can't yet satisfy the authentication strength the policy demands — precisely the gap Temporary Access Pass exists to close.
2. Deliberate exclusion, silently reversed. If your team previously kept WHfB/macOS Platform SSO provisioning outside Conditional Access scope on purpose — for example to avoid slowing down zero-touch device deployment — that carve-out is gone as of July 13, 2026. The registration flow is enforced by default now; excluding it again requires an explicit change.

Related reading: our passwordless MFA registration change coverage and the broader Conditional Access gaps guide both touch adjacent scoping decisions worth revisiting alongside this rollout.

Detection — Audit Your Tenant's Exposure

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=(createdDateTime ge 2026-07-06T00:00:00Z and createdDateTime le 2026-07-13T23:59:59Z) and conditionalAccessStatus eq 'failure'

Get-MgAuditLogSignIn -Filter "createdDateTime gt 2026-07-06T00:00:00Z" | Select-Object `
  @{Name="User";Expression={$_.UserDisplayName}}, `
  @{Name="ClientApp";Expression={$_.ClientAppUsed}}, `
  @{Name="CA Result";Expression={$_.ConditionalAccessStatus}}, `
  @{Name="FailureReason";Expression={$_.FailureReason}}, `
  @{Name="Device";Expression={$_.DeviceDetail.DeviceDisplayName}}

Remediation — Steps to Take Now

1. Enumerate every policy scoped to Register security information and note its Grant controls. This is the full exposure surface for this change — nothing else in your Conditional Access policy set is affected.
2. Re-run each policy in report-only mode and review policy impact results before assuming behavior didn't change on July 13.
3. Exclude emergency access (break-glass) accounts and service accounts/service principals from any policy targeting this user action, per Microsoft's standing recommendation — see our break-glass account coverage for why unexcluded emergency accounts are a recurring finding.
4. Issue a Temporary Access Pass for new hires and device re-provisioning so WHfB/macOS Platform SSO enrollment doesn't hit the chicken-and-egg authentication-strength problem. TAP satisfies the Conditional Access MFA requirement for registration — but remember it doesn't work for guest users.
5. Don't pair external authentication methods with a Require authentication strength grant control on this user action; use Require multifactor authentication instead, per Microsoft's explicit compatibility warning.
6. Update helpdesk documentation about the new authentication prompts users may see mid-setup — this was Microsoft's own recommended action in MC1326253, and it's the cheapest way to cut support tickets from confused new hires. Our Entra ID audit guide covers where Conditional Access scope reviews fit into a broader tenant review.

How EtcSec Detects This

EtcSec's Conditional Access checks flag exactly the misconfigurations that turn this rollout from a non-event into an outage: CA_POLICY_REPORT_ONLY catches policies left in report-only mode that admins believe are enforcing (so the July 13 change was tested but never actually turned on), CA_NO_BREAK_GLASS_EXCLUSION catches emergency-access accounts that aren't excluded from a Register-security-information policy — now a lockout risk on registration, not just sign-in — and CA_EXCESSIVE_EXCLUSIONS flags policies whose exclusion lists have grown wide enough that the scope tightening this rollout brings is effectively moot.