Fix Register Security Information Lockouts Before July 6, 2026 for Windows Hello for Business and macOS Platform SSO

If your tenant uses Conditional Access policies that target Register security information, you have a real deadline now. Microsoft says that starting July 6, 2026, those policies begin applying during Windows Hello for Business and macOS Platform SSO credential registration. Today, those flows do not evaluate registration-targeted Conditional Access policies in the same way. After enforcement starts, a user who could previously finish Hello or Platform SSO setup might suddenly get blocked by your grant controls instead.

That matters because many admins built registration policies assuming they only affected MFA and self-service password reset registration. In July, that assumption stops being safe. A policy that requires a specific authentication strength, a trusted location, or a particular MFA method can now sit directly in the path of laptop enrollment and passwordless provisioning.

This is the practical admin workflow that matters: find every policy scoped to Register security information, identify which grant controls would block fresh credential enrollment, test with pilot users, make sure break-glass accounts are excluded, and put a recovery path like Temporary Access Pass in place before enforcement day.

Quick Fix checklist

Use this sequence before broad July rollout:

1. Inventory every Conditional Access policy that includes the user action Register security information.
2. Review whether the policy requires authentication strength, trusted location, specific MFA methods, or device compliance.
3. Exclude emergency access accounts from those policies.
4. Confirm you have at least two working emergency access accounts.
5. Enable and test Temporary Access Pass for pilot users.
6. Test Windows Hello for Business provisioning with a new or reset pilot user.
7. Test macOS Platform SSO registration with a pilot Mac using Company Portal.
8. Review sign-in logs for Conditional Access outcomes and registration failures.
9. Move only the minimum required policy changes into production.
10. Re-test before July 6, not after.

If you only do one thing today, do step 1. A lot of tenants do not remember which Conditional Access policies target user actions instead of cloud apps.

Why this change can break enrollments that looked healthy last week

Microsoft’s Entra guidance now includes a clear warning: starting July 6, 2026, Conditional Access policies that target Register security information apply during Windows Hello for Business and macOS Platform SSO credential registration. Microsoft also says that after enforcement, users registering those credentials must satisfy your configured grant controls before enrollment can complete.

That changes the blast radius of these policies.

Before this enforcement, a registration policy could exist quietly in the tenant while Windows Hello for Business or Platform SSO still completed. After enforcement, those same controls can block the credential bootstrap itself. The high-risk patterns are straightforward:

• Require phishing-resistant MFA before a user can finish registering the credential that would become their phishing-resistant method.
• Require trusted location when the user is enrolling from home, a branch office, or a staging VLAN that is not in your named locations.
• Require a specific MFA method that the user has not registered yet.
• Require device compliance during a registration path where the compliance state is not yet established the way you expect.

For macOS Platform SSO, Microsoft already documents that Company Portal registration depends on Intune enrollment, proper Platform SSO payload configuration, and the user being registered for some form of Entra MFA. For Windows Hello for Business, the whole point is to provision a device-bound passwordless credential. If Conditional Access now inserts stronger registration requirements at that moment, bad policy design can create a chicken-and-egg problem.

Which policies to audit right now

Do not search only by policy name. Search by target scope.

In Microsoft Graph, Conditional Access policies expose user-action targeting through includeUserActions. Microsoft Graph documents the supported value for this scenario as urn:user:registersecurityinfo.

A practical PowerShell audit looks like this:

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

Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {
    $_.Conditions.Applications.IncludeUserActions -contains "urn:user:registersecurityinfo"
  } |
  Select-Object DisplayName, State,
    @{Name='GrantControls';Expression={($_.GrantControls.BuiltInControls + $_.GrantControls.AuthenticationStrength.DisplayName) -join ', '}},
    @{Name='IncludeUsers';Expression={($_.Conditions.Users.IncludeUsers) -join ', '}},
    @{Name='ExcludeUsers';Expression={($_.Conditions.Users.ExcludeUsers) -join ', '}},
    @{Name='IncludeGroups';Expression={($_.Conditions.Users.IncludeGroups) -join ', '}},
    @{Name='ExcludeGroups';Expression={($_.Conditions.Users.ExcludeGroups) -join ', '}}

If you prefer a cleaner export for review:

$policies = Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {
    $_.Conditions.Applications.IncludeUserActions -contains "urn:user:registersecurityinfo"
  }

$policies | ForEach-Object {
  [PSCustomObject]@{
    DisplayName     = $_.DisplayName
    State           = $_.State
    BuiltInControls = ($_.GrantControls.BuiltInControls -join ', ')
    AuthStrength    = $_.GrantControls.AuthenticationStrength.DisplayName
    IncludeUsers    = ($_.Conditions.Users.IncludeUsers -join ', ')
    ExcludeUsers    = ($_.Conditions.Users.ExcludeUsers -join ', ')
    IncludeGroups   = ($_.Conditions.Users.IncludeGroups -join ', ')
    ExcludeGroups   = ($_.Conditions.Users.ExcludeGroups -join ', ')
  }
} | Export-Csv 'C:\Temp\register-security-info-ca-policies.csv' -NoTypeInformation

When you review the results, flag these policies first:

• policies in enabled state
• policies scoped to All users
• policies with no emergency access exclusions
• policies using Require authentication strength
• policies using named locations that are narrower than your real enrollment paths

The grant controls that are most likely to hurt you

Not every registration policy is dangerous. Some are just stricter than they need to be.

Authentication strength

This is the big one. Microsoft’s authentication strengths guidance says the built-in Phishing-resistant MFA strength allows methods such as:

• Windows Hello for Business or platform credential
• FIDO2 security key
• certificate-based authentication (multifactor)

That sounds good until you think about timing. If the user is trying to register Windows Hello for Business or a platform credential for the first time, requiring a phishing-resistant method up front can force them to use some other already-registered phishing-resistant method first. If they do not have one, registration can stall.

Trusted locations

Trusted location controls make sense for security info registration in tightly controlled environments. They make much less sense if your rollout depends on remote hires, field engineers, or home users receiving new hardware. A user on a new Windows laptop at home can satisfy MFA and still fail the registration journey because the named location test is what blocks the policy.

Specific MFA methods or authentication method assumptions

Microsoft’s updated registration guidance explicitly points admins toward Temporary Access Pass because TAP can satisfy Conditional Access MFA requirements for passwordless bootstrap scenarios. If your policy assumes every user already has Authenticator push, phone sign-in, or some other method ready, check that assumption now.

Device compliance

This is where you should slow down and test carefully. Microsoft’s general report-only guidance warns that report-only policies requiring compliant devices can still trigger certificate prompts on macOS, iOS, and Android even when compliance is not enforced. Even if you never intended to block Platform SSO registration, a bad compliance-oriented registration policy can create noise or user confusion during pilot.

A safe remediation workflow before July 6

Step 1: Exclude emergency access accounts

Microsoft recommends excluding emergency access or break-glass accounts from these policies to avoid lockout. Microsoft’s emergency access guidance is also explicit: create two or more emergency access accounts in your organization.

If your registration policy applies to all admins and your only Global Admins depend on normal MFA flows, you are one bad Conditional Access edit away from a support case.

Step 2: Confirm Temporary Access Pass is enabled

Temporary Access Pass is the clean recovery and bootstrap path for this change. Microsoft says users can use TAP to onboard passwordless authentication methods, and the registration policy article says TAP credentials satisfy Conditional Access MFA requirements.

That makes TAP the first thing to validate for:

• new-user Windows Hello for Business enrollment
• recovery after lost phone or broken Authenticator state
• macOS Platform SSO registration where the user lacks a working second factor

A basic preflight check for TAP readiness is:

Connect-MgGraph -Scopes "Policy.Read.All","UserAuthenticationMethod.Read.All"
Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration |
  Select-Object Id, State

If your org uses TAP only for emergencies, that is fine. But test it before July 6, not during the first failed laptop setup.

Step 3: Pilot Windows Hello for Business registration

Use a pilot user whose existing Hello credential is reset or who has not provisioned Hello on the device yet. Then verify:

1. user sign-in succeeds
2. Windows Hello for Business registration begins
3. Conditional Access does not demand an impossible method
4. the credential is created successfully
5. the sign-in logs show the expected result

For evidence, review the failed or successful sign-in in:

Microsoft Entra admin center > Identity > Monitoring & health > Sign-in logs

Look at the Conditional Access tab and note whether the registration policy appears as success, failure, or report-only output.

Step 4: Pilot macOS Platform SSO registration

Microsoft’s Company Portal registration guidance says Platform SSO registration requires:

• macOS 14 Sonoma or later recommended
• Company Portal version 5.2404.0 or later
• Intune enrollment
• configured Platform SSO payload
• some form of Entra MFA for the user

That means your pilot must be realistic. Test with an actual Mac on the same network conditions your users will have. If your Platform SSO rollout depends on home users, do not pilot only from the corporate LAN.

Step 5: Re-check sign-in logs after each test

The sign-in log is where you separate a Conditional Access problem from a device configuration problem. You want to know whether the failure came from:

• policy targeting
• grant control mismatch
• missing registration method
• location restriction
• a separate Intune or Platform SSO payload issue

Do not change two policies at once and then guess which one fixed it.

Logs and where to check

Your first stop is still the Entra sign-in log.

High-value fields:

• Conditional Access result
• policy name
• authentication requirement
• failure reason
• location and client details

Useful failure patterns to watch for:

Access has been blocked by Conditional Access policies.
MFA requirement not satisfied.
Authentication strength requirement not satisfied.
User must register security information.

If you want a quick Graph pull for recent registration-related sign-ins:

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

$start = (Get-Date).AddDays(-7).ToString("o")
Get-MgAuditLogSignIn -Filter "createdDateTime ge $start" -Top 100 |
  Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName,
    ConditionalAccessStatus, Status |
  Format-List

Also note one caveat from Microsoft’s broader Conditional Access reporting guidance: report-only mode has historically had exceptions for User Actions scope. Microsoft now tells admins to test this registration change with report-only before enforcement, but I would not trust report-only as the only proof. Use it where the tenant exposes useful data, then validate with real pilot registrations and sign-in log review.

Limitations and gotchas

A few traps are easy to miss.

Your policy might be secure and still operationally wrong

A policy can be logically strong and still be a bad fit for credential bootstrap. Requiring phishing-resistant MFA for general admin access is reasonable. Requiring it at the exact moment a user is trying to create their first phishing-resistant credential may not be.

Remote enrollments are where weak assumptions show up first

Named locations and strict method assumptions tend to look fine during office testing. They fail when a user is on guest Wi-Fi, home broadband, or a staging network for new devices.

Platform SSO issues can look like Conditional Access issues

macOS Platform SSO already has its own failure patterns around Company Portal version, Intune payload design, and TLS inspection. If the sign-in logs show success but the Mac still cannot finish registration, move back to the Platform SSO configuration and networking path.

Guest and cross-tenant scenarios are trickier

Microsoft’s target resources guidance notes that registration-targeted user actions have special behavior for some guest scenarios. If you support B2B admin or contractor onboarding flows, pilot those separately instead of assuming employee testing covers them.

Conclusion

The July 6, 2026 enforcement change is exactly the kind of identity change that turns into an endpoint incident if nobody owns the overlap. A Conditional Access policy that once looked like an MFA-registration control can now block Windows Hello for Business and macOS Platform SSO at the worst possible moment: first-run credential setup.

Audit the policies now, exclude emergency accounts, make sure Temporary Access Pass works, and test both Windows and Mac registration flows with real pilot users. If you wait for the first laptop that cannot finish passwordless setup, you are already doing outage response instead of change management.