Summary
- Microsoft plans to start the worldwide rollout in early October 2026 and complete it by late November.
- Windows Hello for Business and macOS Platform SSO will satisfy supported MFA requirements without requiring an additional registered passkey.
- The change reduces authentication friction but alters assumptions built into Conditional Access, authentication-strength, and onboarding processes.
Microsoft is changing how Entra ID treats device-bound credentials, allowing Windows Hello for Business and macOS Platform Single Sign-On to satisfy supported multifactor authentication requirements without requiring an additional registered passkey.
The company plans to begin the worldwide rollout in early October 2026 and complete it by late November, according to Microsoft Message Center notice MC1450134.
Windows Hello for Business and macOS Platform SSO can already satisfy MFA during primary sign-in. Users can nevertheless encounter another authentication or registration step during some step-up prompts, authentication-strength policies, or sign-in-frequency checks.
After the change, Entra will recognise the two methods as standalone MFA factors in supported scenarios. A user who has already established one of the credentials will therefore be able to meet those requirements without registering an additional passkey purely for the extra challenge.
The change reflects Microsoft’s wider move towards phishing-resistant authentication. Windows Hello for Business uses a device-bound cryptographic credential protected by local user verification, while macOS Platform SSO provides a comparable route for managed Apple devices.
Both designs reduce dependence on reusable passwords and approval-based methods that can be intercepted or socially engineered. Microsoft already lists Windows Hello for Business among the verification methods supported by Entra multifactor authentication.
The October change is operationally narrower than a redesign of MFA, but it can affect identity policies built around today’s sign-in behaviour. Organisations may have onboarding instructions, help-desk processes, Conditional Access rules, or custom authentication strengths that assume a user will maintain another method alongside the device credential.
Microsoft says no configuration change is required for the new behaviour itself. Administrators may still need to review policies and documentation to establish whether the resulting authentication flow matches the organisation’s intended assurance model.
The update also arrives alongside Microsoft’s separate effort to allow password-only users to register phishing-resistant credentials without first establishing weaker methods such as SMS or voice. Together, the changes reduce the number of cases where adoption of stronger authentication depends on maintaining a weaker bootstrap mechanism.
Device-bound authentication does not remove every identity risk. Session theft, compromised endpoints, recovery mechanisms, administrative resets, and applications using different authentication paths can still bypass the protection offered by a phishing-resistant primary credential.
Recovery also remains a different problem from routine sign-in. Credentials tied to a particular computer cannot substitute automatically for a recovery route when that device is lost, damaged, replaced, or inaccessible.
The change therefore simplifies the normal authentication path without eliminating the need to design fallback and recovery separately. From October, Entra will increasingly treat an established device credential as the multifactor control itself rather than requiring users to prove possession of another authentication method simply to satisfy a fresh MFA event.
