On 6 July 2026, Entra ID Conditional Access extends to Windows Hello for Business enrolment and macOS Platform SSO registration. Policy requirements such as trusted locations and authentication strength will then apply during device registration — not only at sign-in. Which policies need reviewing, and what can you still do this week?
In the week of 6 July 2026, Microsoft is rolling out a security change in Entra ID that has direct consequences for organisations using Windows Hello for Business or macOS Platform SSO. Conditional Access policies targeting the action Register security information will from that point also be evaluated during Windows Hello for Business provisioning and macOS Platform SSO registration. Any organisation that does not review its CA policies risks users being unable to complete their device registration.
The change is a deliberate step by Microsoft towards more consistent identity policy. Until now, a simplified evaluation applied during registration flows: MFA was enforced, but the Grant controls of the applicable Conditional Access policy were not evaluated. With this update, Microsoft closes that gap.
Windows Hello for Business is a phishing-resistant authentication method built into Windows 10 and Windows 11. On the first sign-in to a device managed via Intune or via an Entra ID join, a user goes through a provisioning flow: a device-bound cryptographic key is created in the TPM chip and linked to a biometric profile or PIN. That key works only on that specific device, and the private key never leaves it.
During that provisioning flow, Entra ID has until now verified that the user authenticated correctly — MFA was required — but the Grant controls of any Conditional Access policies targeting Register security information were not evaluated. Requirements such as a Compliant Device, a trusted network location, or a specific authentication method therefore did not apply at the moment of enrolment, even if they applied during regular sign-in.
From the week of 6 July, the Grant controls of Conditional Access policies targeting Register security information will also be evaluated during Windows Hello for Business provisioning and macOS Platform SSO registration. In practice: if your policy requires that registration only takes place at a trusted location, an employee setting up a new laptop at home will not be able to complete Windows Hello for Business provisioning — unless their home network is marked as a trusted Named Location.
The same applies to authentication strength. If your policy sets a specific authentication method as a Grant control, the user must be able to use that method at that moment. For organisations requiring phishing-resistant MFA, this means the user must already have a phishing-resistant method in place before enrolling Windows Hello for Business — creating a circular dependency when WHfB is itself the phishing-resistant method you want to roll out.
Not every organisation needs to take action. The change only affects organisations with Conditional Access policies that explicitly target the Register security information action with Grant controls. If no such policy exists — the case in many baseline configurations — nothing changes and no action is required.
Organisations that do have such a policy need to check two scenarios. First, policies with location restrictions: if registration is limited to trusted locations or Compliant Devices, this can block new employees registering their first device from a location not yet configured as trusted. Second, policies with authentication requirements that create a circular dependency: if you want to use Windows Hello for Business as your phishing-resistant method but already require a phishing-resistant method for the registration step itself, the user can never complete the initial enrolment.
Alongside Windows Hello for Business, the same change applies to macOS Platform SSO registration. macOS Platform SSO links a macOS device to an Entra ID identity via a device-bound credential stored in the Mac's Secure Enclave. Enrolment takes place via the macOS Setup Assistant or via a managed onboarding flow in Intune or another MDM solution.
For organisations with a mixed device fleet — Windows and macOS side by side — both platforms now go through the same CA evaluation at registration. This simplifies policy in the long term, but requires attention now to verify that existing policies do not inadvertently block enrolment on either platform.
Step 1: identify the relevant policies. Open the Entra portal at entra.microsoft.com, navigate to Protection > Conditional Access, and filter for policies targeting the Register security information action. If no policy targets this action, no action is required.
Step 2: assess the Grant controls for each policy found. Ask yourself: can a new employee registering their first device satisfy all Grant controls at that moment? Think of someone working from home, on an unknown network, or without a phishing-resistant method set up yet. If the answer is no, consider whether Grant controls need to be adjusted or whether an exception is needed for the initial enrolment.
Step 3: test via report-only mode. Temporarily set the policy to report-only, run a test registration using a test user, and check the sign-in logs in the Entra portal. You will see exactly which Grant controls would be enforced and whether a block would occur. This takes less than thirty minutes and removes the uncertainty entirely before the change takes effect.
The roll-out takes place during the week of 6 to 13 July 2026. That gives IT teams a short window to act. Three priorities for the coming days: audit your CA policies for the Register security information action, assess whether onboarding scenarios for new employees still work under your policy's Grant controls, and consider adding a Named Location for new device registration if your policy contains location restrictions.
If your onboarding flow requires employees to enrol Windows Hello for Business at home and your policy restricts registration to trusted locations, there are two solutions: add home networks as Named Locations, or configure a separate registration policy without location restrictions that only applies to initial enrolment. Microsoft recommends testing this scenario in report-only mode before 6 July so you know exactly what changes in your specific configuration.
The 6 July change closes a real security gap: the enrolment of phishing-resistant authentication methods was until now not subject to the same CA requirements as day-to-day sign-in. That changes now. For IT teams, the action required is limited but time-sensitive. Want your Conditional Access configuration reviewed or support setting up phishing-resistant authentication for your device estate? Contact Zarioh for a no-obligation conversation.
