Action Required: Entra Conditional Access Enforced for Windows Hello for Business Registration from July 6

Published June 27, 2026  ·  Category: Microsoft Entra ID, Conditional Access, Windows Hello for Business

Microsoft has announced a significant expansion to how Conditional Access (CA) policies are applied during security information registration. Starting the week of July 6, 2026, CA policies scoped to the "Register security information" user action will be enforced not just in My Security Info (mysignins.microsoft.com) and the Microsoft Authenticator app, but also during:

• Windows Hello for Business provisioning — including during Windows Out-of-Box Experience (OOBE) on Entra-joined and Hybrid Entra-joined devices
• macOS Platform SSO registration — when users register a Platform Credential or a SmartCard-equivalent on macOS

This change is part of a broader hardening effort across Microsoft Entra ID that also includes the deprecation of Custom Controls in favour of External Authentication Methods (EAM), SSPR registration policy enforcement, and the rollout of a global registration campaign starting July 6. Each of these changes has its own deadline and admin action required — all covered in this post.

What is the "Register security information" User Action?

In Conditional Access, a user action is a special target that allows you to apply CA policy to specific user-initiated tasks rather than to application sign-ins. The Register security information action controls the registration of MFA methods, passwordless credentials, and SSPR authentication methods — essentially anything a user does when they visit My Security Info or are prompted to register a new credential.

Until now, the enforcement scope of this user action was limited to browser-based registration flows (My Security Info) and the Authenticator app. Device-side flows — such as WHfB provisioning that happens in the background during Autopilot Enrolment Status Page (ESP), or during a user's first sign-in on a freshly imaged device — were evaluated in report-only mode or bypassed entirely, depending on your policy configuration.

From July 6, this changes. The enforcement gate expands to device-side registration flows. Any Grant controls on a matching CA policy (such as requiring a compliant device, requiring MFA, requiring terms-of-use acceptance, or requiring a specific authentication strength) will be evaluated before WHfB provisioning can complete.

Why This Can Break WHfB Provisioning

Consider a common CA policy pattern: "Require MFA or a compliant device to register security information." This is a sensible defence-in-depth control — you don't want an attacker who has stolen credentials to be able to register their own MFA methods. However, the same policy creates a bootstrapping problem during device provisioning:

1. A new device joins Entra ID during Autopilot or manual enrolment.
2. The device is not yet compliant — Intune policy hasn't finished applying.
3. The user is prompted to complete WHfB provisioning (PIN/biometric setup).
4. CA evaluates the Register security info policy — device is not compliant, MFA may not be satisfiable at this stage — access is blocked.
5. WHfB provisioning fails silently or with a cryptic error. The user is stuck.

This scenario has been flagged extensively in the community by experts including Rudy Ooms (Call4Cloud) and Peter van der Woude (petervanderwoude.nl), both of whom have documented edge cases in CA and Intune policy sequencing during Autopilot flows. Jan Ketil Skanke (MVP, CloudWay) has similarly highlighted timing-sensitive issues during device provisioning where compliance state lags behind CA evaluation. The enforced expansion of this user action requires admins to revisit those scenarios with urgency.

Auditing Your CA Policies — What to Check

Your first task is to identify all CA policies in your tenant that target the Register security information user action, then assess whether their Grant controls can be satisfied during a device provisioning flow. Use the following PowerShell script to enumerate them via the Microsoft Graph API:

# Requires: Microsoft.Graph.Identity.SignIns module
# Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "Policy.Read.All"

$policies = Get-MgIdentityConditionalAccessPolicy -All

$secInfoPolicies = $policies | Where-Object {
    $_.Conditions.UserRiskLevels -eq $null -and
    $_.Conditions.Applications.IncludeUserActions -contains "urn:user:registerdevice" -or
    $_.Conditions.Applications.IncludeUserActions -contains "urn:user:registersecurityinfo"
}

Write-Host "Found $($secInfoPolicies.Count) CA policies targeting security info registration:" -ForegroundColor Cyan

foreach ($policy in $secInfoPolicies) {
    Write-Host "`n--- Policy: $($policy.DisplayName) ---" -ForegroundColor Yellow
    Write-Host "  State         : $($policy.State)"
    Write-Host "  Grant Controls: $($policy.GrantControls.BuiltInControls -join ', ')"
    Write-Host "  Operator      : $($policy.GrantControls.Operator)"
    Write-Host "  Included Users: $($policy.Conditions.Users.IncludeUsers -join ', ')"
    Write-Host "  Excluded Users: $($policy.Conditions.Users.ExcludeUsers -join ', ')"
    Write-Host "  Included Groups: $($policy.Conditions.Users.IncludeGroups -join ', ')"
    Write-Host "  Excluded Groups: $($policy.Conditions.Users.ExcludeGroups -join ', ')"
}

$secInfoPolicies | Select-Object DisplayName, State,
    @{N='GrantControls';E={$_.GrantControls.BuiltInControls -join ', '}},
    @{N='Operator';E={$_.GrantControls.Operator}} |
    Export-Csv -Path ".\CA-SecurityInfo-Policies-$(Get-Date -f yyyyMMdd).csv" -NoTypeInformation

Write-Host "`nExport complete." -ForegroundColor Green

Pay particular attention to any policy in Enabled state (not report-only) that includes Grant controls such as:

• compliantDevice — will fail on newly provisioned devices not yet Intune-compliant
• mfa — may fail if the user has no prior MFA method registered (chicken-and-egg scenario)
• domainJoinedDevice — will fail on Entra-only (non-hybrid) joined devices
• termsOfUse — may not be presentable during OOBE/silent provisioning flows

Recommended Remediation Strategies

There are several approaches depending on your environment. Microsoft's recommended guidance (see learn.microsoft.com — CA for security info registration) is to use authentication context or scoped exclusions to allow WHfB provisioning to proceed while still protecting browser-based self-service registration:

Option 1: Exclude the WHfB Provisioning Flow via Named Location or Trusted Device

If your provisioning devices originate from a known network (e.g., on-premises or a specific subnet used during Autopilot staging), create a Named Location and add it as an exclusion to the Grant control, or use a device filter to exclude devices in a specific Entra ID group used during provisioning. This is the least disruptive short-term fix but requires careful scoping.

Option 2: Use Authentication Strengths Instead of Legacy MFA Grant

Replace a standalone mfa Grant control with an Authentication Strength policy that explicitly allows Windows Hello for Business as a satisfying method. This means users who have already completed WHfB registration on another device can satisfy the policy, while new users still need a path. Combine with a Temporary Access Pass (TAP) policy to bootstrap new users.

Option 3: Place Policies in Report-Only Mode Before the Deadline

If you are not ready to reconfigure policies before July 6, switch the relevant CA policies to Report-only mode immediately. This will prevent enforcement while still logging sign-in data you can analyse to understand impact. Re-enable enforcement only once you have validated your configuration in a test group.

Related Entra Security Changes — Same Wave

The WHfB enforcement change does not arrive alone. Microsoft's Entra ID Security Updates blog post and the What's New in Microsoft Entra — June 2026 post together outline a cluster of related changes arriving between July and September 2026:

Custom Controls → External Authentication Methods Migration

If your organisation integrated a third-party MFA provider (e.g., Duo Security, RSA SecurID, Okta MFA) using the legacy Custom Controls feature in CA, you need to act urgently. Custom Controls are being deprecated as part of this same security hardening wave. The replacement is External Authentication Methods (EAM), which provides a standards-compliant integration path using OpenID Connect.

The critical difference: Custom Controls were a "trust us, it worked" signal — Entra had no visibility into what the third-party actually verified. EAM provides a proper claims-based assertion that Entra can cryptographically validate, enabling it to be included in Authentication Strength policies. This is a significant improvement in the security model, but requires re-registration of your third-party MFA provider under the new EAM framework and updates to all CA policies that currently reference Custom Controls.

SSPR Registration Enforcement — September 7, 2026

Separate from but related to the CA changes, Microsoft is enforcing that SSPR will only accept authentication methods that the user has already registered. Today, SSPR can fall back to methods the user hasn't explicitly registered (e.g., sending a code to a mobile number on file from an HR system). From September 7, that fallback is removed.

This means any user who hasn't registered MFA methods through My Security Info and who needs to reset their password will be locked out of self-service reset. The remediation is to run the authentication methods registration report and proactively nudge or require users to register. The registration campaign starting July 6 will help, but for managed devices you should also consider pushing the Microsoft Authenticator app via Intune App deployment and pairing it with an MFA nudge policy.

Admin Checklist — Actions Before July 6

Testing in Report-Only Mode

Report-only mode is your best friend here. Before July 6, if you haven't already tested your CA policies against a real WHfB provisioning flow, do the following:

1. In Entra admin centre > Protection > Conditional Access, switch the relevant policy to Report-only.
2. Perform a full WHfB provisioning test — either via Autopilot, manually joining a VM to Entra ID, or using an existing device with WHfB reset.
3. Navigate to Entra admin centre > Monitoring > Sign-in logs, filter for your test user, and look for the Register security information sign-in event.
4. In the sign-in event detail, check the Report-only tab — it shows whether the policy would have granted or blocked access, and which condition failed.
5. Iterate on your policy exclusions or Grant control structure until report-only shows success for the provisioning flow without opening excessive gaps for other flows.

Additional References

• Microsoft Learn — Configure a CA policy for the Register security information user action
• Microsoft Entra Blog — Microsoft Entra ID Security Updates: What Organizations Need to Do Now
• Microsoft Entra Blog — What's New in Microsoft Entra: June 2026
• Microsoft Learn — Temporary Access Pass in Microsoft Entra ID
• Microsoft Learn — External Authentication Methods in Microsoft Entra ID
• Microsoft Learn — Authentication Strength policies

This post covers Microsoft Entra ID changes announced through June 2026. Always validate configurations in a test environment before applying to production. Deadlines are subject to change by Microsoft — refer to the official Message Centre posts MC1000000-series for tenant-specific rollout timelines.