Register security information now also applies to Windows Hello for Business and Platform SSO
On Monday 6 July Microsoft starts rolling out a change that makes Conditional Access policies targeting the user action Register security information also apply when users provision Windows Hello for Business or register a Mac for Platform SSO. The rollout should be complete for all tenants on 13 July. If you never built a policy on that user action, nothing changes for you. If you have one, it was probably written with the Security info page in My Sign-ins in mind, and from that week it also applies during your Autopilot and Mac onboarding.
Photo: Yevhenii Deshko on Unsplash
What the user action covers today
Conditional Access has only two user actions: Register security information and Register or join devices. The second one isn't part of this change (it only offers MFA and authentication strength as grant controls, see user actions). Register security information is evaluated when a user goes through combined registration: the Security info page in My Sign-ins, and the interrupt mode that appears when a user has to register for SSPR or MFA. According to Microsoft Learn, users who sign in to the Authenticator app or turn on passwordless phone sign-in are also subject to it. It's where most organisations put rules like "register only from a trusted location", "registration requires MFA outside the office", "registration only from a compliant device", or an authentication strength that includes Temporary Access Pass (TAP) so new hires can bootstrap.
Windows Hello for Business and Platform SSO never went through this. When Windows provisions Hello for Business, the provisioning app requests an access token for the Azure Device Registration Service through WAM, the user must have done MFA within the last ten minutes, and that's the whole check (how provisioning works). Platform SSO with Secure Enclave or smart card also requires MFA during setup (Intune Platform SSO guide). Neither flow evaluated your registration policies. That changes now: the default MFA requirement stays, and on top of it the conditions and grant controls of every enabled policy that targets the user action apply (report-only policies aren't enforced), whether that's an authentication strength, a location condition or a device requirement. The timeline is already covered well in MC1326253 (published 29 May) and Microsoft's Entra blog, so I'll focus on what to check in your own policies.
Windows Hello for Business and Platform SSO never went through this. When Windows provisions Hello for Business, the provisioning app requests an access token for the Azure Device Registration Service through WAM, the user must have done MFA within the last ten minutes, and that's the whole check (how provisioning works). Platform SSO with Secure Enclave or smart card also requires MFA during setup (Intune Platform SSO guide). Neither flow evaluated your registration policies. That changes now: the default MFA requirement stays, and on top of it the conditions and grant controls of every enabled policy that targets the user action apply (report-only policies aren't enforced), whether that's an authentication strength, a location condition or a device requirement. The timeline is already covered well in MC1326253 (published 29 May) and Microsoft's Entra blog, so I'll focus on what to check in your own policies.
Policy designs that can block onboarding
Requiring a compliant device is the one I would look at first. Learn mentions that organisations used device compliance to secure registration, and for browser registration from an existing managed laptop that works fine. Hello for Business provisioning, however, starts right after the user's first sign-in on a freshly deployed device, and at that point Intune may not have finished evaluating compliance. For hybrid joined Autopilot devices this is documented: the Autopilot known issues page explains that the hybrid device's compliance state shows N/A until a user signs in, because Intune only syncs with the hybrid device ID after a successful user sign-in. Provisioning runs during exactly that first sign-in. On a Mac, as far as I can tell, the order of enrolment, Entra registration and compliance reporting differs in practice between the Company Portal flow and Automated Device Enrollment (Microsoft doesn't document that ordering explicitly), so I wouldn't assume the Mac is compliant when the "Registration Required" notification appears.
A policy that requires a Microsoft Entra hybrid joined device is less risky on Windows, because Hello for Business can only provision on a hybrid device once the join is complete. But a Mac is never hybrid joined, so if that is the only grant control, Platform SSO registration has no way to satisfy it.
Trusted locations are the next one. A policy that blocks registration outside trusted locations, or requires a compliant device outside them, was harmless as long as people registered their authenticator at the office or through a VPN. Once enforcement starts, the same policy applies to a remote employee unboxing an Autopilot laptop at home, and Hello for Business provisioning will fail there.
The bootstrap problem is harder to spot. TAP satisfies the Require multifactor authentication control, and during Microsoft Entra join a user can sign in with a TAP without a password, join the device and register Hello for Business in one go. On hybrid joined devices, and on devices that are already joined, the user first has to authenticate with another method (such as a password) before the TAP is accepted for Hello for Business. The catch is in authentication strengths: TAP is only part of the built-in Multifactor authentication strength, not of Passwordless MFA or Phishing-resistant MFA. If your registration policy requires one of the latter two (a common choice once a passwordless programme matures), a new hire who only has a TAP can't satisfy it, and from now on that applies in OOBE as well. Learn documents the fix: a custom authentication strength that includes the TAP combination alongside the methods you actually want, assigned to the Register security information policy (see the "Bootstrap and recovery" example in how authentication strengths work). Federated multifactor also only appears in the MFA strength, which matters if your federated domain uses
There are also two timing details. If the user signed in with a single-use TAP and Hello for Business provisioning starts more than ten minutes later, they need a second TAP, or you use a multi-use TAP; the TAP article has a table for exactly this. And the MFA performed during OOBE only saves the user a prompt if it also meets your policy. Microsoft's own message warns that users may see a new authentication prompt during device setup, so tell your service desk.
Then there are the exclusions. Any exclusion on these policies (a "new starters" group, guests, a provisioning account) now also exempts that population from your controls on Hello for Business and Platform SSO registration. There is no separate user action for these two flows. If you want them handled differently from browser registration, your only option is the regular conditions on the same user action. The device platforms condition looks like the obvious candidate, and filter for devices is another one, but I haven't seen Microsoft confirm which conditions are evaluated in these flows.
A policy that requires a Microsoft Entra hybrid joined device is less risky on Windows, because Hello for Business can only provision on a hybrid device once the join is complete. But a Mac is never hybrid joined, so if that is the only grant control, Platform SSO registration has no way to satisfy it.
Trusted locations are the next one. A policy that blocks registration outside trusted locations, or requires a compliant device outside them, was harmless as long as people registered their authenticator at the office or through a VPN. Once enforcement starts, the same policy applies to a remote employee unboxing an Autopilot laptop at home, and Hello for Business provisioning will fail there.
The bootstrap problem is harder to spot. TAP satisfies the Require multifactor authentication control, and during Microsoft Entra join a user can sign in with a TAP without a password, join the device and register Hello for Business in one go. On hybrid joined devices, and on devices that are already joined, the user first has to authenticate with another method (such as a password) before the TAP is accepted for Hello for Business. The catch is in authentication strengths: TAP is only part of the built-in Multifactor authentication strength, not of Passwordless MFA or Phishing-resistant MFA. If your registration policy requires one of the latter two (a common choice once a passwordless programme matures), a new hire who only has a TAP can't satisfy it, and from now on that applies in OOBE as well. Learn documents the fix: a custom authentication strength that includes the TAP combination alongside the methods you actually want, assigned to the Register security information policy (see the "Bootstrap and recovery" example in how authentication strengths work). Federated multifactor also only appears in the MFA strength, which matters if your federated domain uses
enforceMfaByFederatedIdp, because then the MFA for Hello for Business provisioning happens at your federation server.There are also two timing details. If the user signed in with a single-use TAP and Hello for Business provisioning starts more than ten minutes later, they need a second TAP, or you use a multi-use TAP; the TAP article has a table for exactly this. And the MFA performed during OOBE only saves the user a prompt if it also meets your policy. Microsoft's own message warns that users may see a new authentication prompt during device setup, so tell your service desk.
Then there are the exclusions. Any exclusion on these policies (a "new starters" group, guests, a provisioning account) now also exempts that population from your controls on Hello for Business and Platform SSO registration. There is no separate user action for these two flows. If you want them handled differently from browser registration, your only option is the regular conditions on the same user action. The device platforms condition looks like the obvious candidate, and filter for devices is another one, but I haven't seen Microsoft confirm which conditions are evaluated in these flows.
Finding the policies
The portal filter works, but in a tenant with many policies I'd rather have a list including grant controls. Microsoft Graph PowerShell, with the user action as it appears in the
includeUserActions property: Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
Where-Object { $_.Conditions.Applications.IncludeUserActions -contains 'urn:user:registersecurityinfo' } |
Select-Object DisplayName, State,
@{ n = 'BuiltInControls'; e = { $_.GrantControls.BuiltInControls -join ', ' } },
@{ n = 'Operator'; e = { $_.GrantControls.Operator } },
@{ n = 'AuthStrength'; e = { $_.GrantControls.AuthenticationStrength.DisplayName } },
@{ n = 'InclLocations'; e = { $_.Conditions.Locations.IncludeLocations -join ', ' } },
@{ n = 'ExclLocations'; e = { $_.Conditions.Locations.ExcludeLocations -join ', ' } },
@{ n = 'Platforms'; e = { $_.Conditions.Platforms.IncludePlatforms -join ', ' } } |
Format-Table -AutoSize
Look for
compliantDevice and domainJoinedDevice in the built-in controls, block combined with location conditions, and authentication strengths without TAP. Include policies in report-only state in your review, because someone is going to switch them on eventually. Testing the change
Both Microsoft's message and the Learn note recommend testing with report-only mode. However, the report-only article states that policies can be evaluated in report-only mode "except for items included in the User Actions scope". I wouldn't count on report-only results for these policies. The What If tool does support user actions: simulate a new-hire test account, select Register security information as the target, set the platform to Windows or macOS, and use a home IP address. That tells you which policies would apply and which grant controls the user would have to satisfy.
Real testing can only happen once the change has reached your tenant, so plan a fresh Autopilot device and a fresh Mac with a test account in the week of 6 July, ideally before your next onboarding wave. Microsoft hasn't documented exactly how the new evaluation appears in the sign-in logs. The provisioning token is requested for the Device Registration Service (app ID
Real testing can only happen once the change has reached your tenant, so plan a fresh Autopilot device and a fresh Mac with a test account in the week of 6 July, ideally before your next onboarding wave. Microsoft hasn't documented exactly how the new evaluation appears in the sign-in logs. The provisioning token is requested for the Device Registration Service (app ID
01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9), so I'd start there and check the Conditional Access tab. If you stream sign-in logs to Log Analytics, this query shows which resources your registration policies are evaluated against (fill in your own policy names), so you can compare the period before and after the rollout: let regPolicies = dynamic(["CA-RegisterSecInfo-TrustedLocations", "CA-RegisterSecInfo-AuthStrength"]);
SigninLogs
| where TimeGenerated > ago(14d)
| mv-expand cap = ConditionalAccessPolicies
| where tostring(cap.displayName) in (regPolicies)
| where tostring(cap.result) !in ("notApplied", "notEnabled")
| summarize Count = count() by AppDisplayName, ResourceDisplayName, Policy = tostring(cap.displayName), Result = tostring(cap.result), ResultType
| order by Count desc
On the Windows device itself, the User Device Registration admin log (Applications and Services Logs, Microsoft, Windows) shows the provisioning prerequisite checks and event 300 when the key is registered. The PIN creation error list is useful when a test fails.
Before 6 July
Run the script above and, for each policy targeting Register security information, answer one question: can a new employee on a brand new device, at home, holding nothing but a TAP, satisfy this? If the answer is no, either add a custom authentication strength that includes TAP, move the device or location requirement to a condition that doesn't hit OOBE, or decide consciously that remote Hello for Business provisioning should fail. Then book a test device for the rollout week.
Sources
- MC1326253: Conditional Access policies now apply to Windows Hello for Business and macOS Platform SSO registration
- Microsoft Entra blog: Microsoft Entra ID security updates, what organizations need to do now
- Protect security info registration with Conditional Access
- Conditional Access target resources: user actions
- How Windows Hello for Business provisioning works
- Configure Platform SSO for macOS devices in Intune
- Windows Autopilot known issues
- Temporary Access Pass: Windows device setup
- Built-in and custom authentication strengths
- How authentication strengths work
- conditionalAccessApplications resource type (Microsoft Graph)
- Conditional Access report-only mode
- Conditional Access What If tool
- Windows Hello for Business errors during PIN creation