Windows Hello for Business as standalone MFA factor: what the October 2026 Entra change means

Windows Hello for Business has long been the recommended authentication method for managed Windows devices in a Microsoft Entra environment. It combines something you know, a PIN, with something you are, a fingerprint or facial recognition, and stores the cryptographic key in the device's TPM chip. Phishing-resistant, fast, and user-friendly.

Yet the technology had a practical limitation until recently: in certain Conditional Access flows, users who had signed in via Windows Hello for Business were still prompted for a second verification through the Authenticator app or an SMS code. That felt illogical, since they had just proved their identity through a strong, hardware-bound mechanism. Microsoft is structurally resolving this: from October 2026, Entra ID will recognise Windows Hello for Business and macOS Platform SSO as standalone MFA factors.

How does Windows Hello for Business work in Entra ID today?

Windows Hello for Business uses a key pair created in the TPM chip when the device is registered. The private key never leaves the device. At sign-in, the device cryptographically proves it holds the correct key, while the user unlocks via PIN, fingerprint, or face recognition.

In the current situation, WHfB already counts in Entra as a primary authenticator satisfying the password requirement. For a standard sign-in where Conditional Access does not impose an explicit MFA requirement, everything works smoothly. But once a CA policy requires an MFA claim, or triggers a step-up MFA for access to a sensitive application, the user may still see an additional verification prompt, even though the WHfB sign-in was already phishing-resistant.

This is technically explainable: the MFA claim and the WHfB claim were not always treated as equivalent in all CA evaluation flows. That discrepancy is exactly what Microsoft is now resolving.

What changes in October 2026?

From early October 2026, Microsoft Entra ID will officially recognise Windows Hello for Business and macOS Platform SSO Secure Enclave credentials as standalone MFA factors. In practice, this means three things.

First, users with WHfB will now be able to satisfy an MFA step-up in Conditional Access without an additional authentication prompt appearing. The WHfB sign-in counts as sufficient proof, including for strict Conditional Access requirements that explicitly ask for MFA.

Second, WHfB will be recognised as a method satisfying Authentication Strength requirements. If you have configured an Authentication Strength policy in Conditional Access with phishing-resistant methods, WHfB will automatically fall under it once the change is active.

Third, sign-in frequency challenges, the situation where Entra asks a user to re-authenticate after a configured interval, will be handled through WHfB without the user needing to open the Authenticator app. The experience becomes significantly simpler for end users.

The change rolls out automatically. There is no tenant-wide switch for administrators to enable. The rollout starts in early October and reaches all tenants worldwide, including GCC, by the end of November 2026.

What does this mean for your Conditional Access policies?

Although the change is positive for user experience, it is wise for IT administrators to review existing Conditional Access policies before the rollout reaches your tenant. Two points to watch.

First point: CA policies with an explicit MFA requirement that you configured to force a second factor on top of WHfB will work differently after October. Where users were previously automatically challenged for a second factor, the WHfB sign-in will now be considered sufficient. If you deliberately wanted to enforce a second factor for certain applications or locations, you need to specify that more precisely through Authentication Strength rather than relying on generic MFA requirements.

Second point: tenants working with named locations or sign-in risk-based policies should verify that allowed authentication methods are correctly configured. A CA policy that requires additional verification at high sign-in risk must be explicitly described after October, otherwise WHfB will be considered sufficient even for risky sign-in attempts.

Most organisations will find that the change works in their favour: fewer prompts, less frustration for users, and a more consistent security experience. But a brief audit of your CA policies is worth the effort.

The registration change: Conditional Access on WHfB provisioning

Alongside the MFA recognition, Microsoft has also adjusted the registration flow. CA policies targeting the user action 'Register security information' now apply when users provision Windows Hello for Business on a device or register macOS Platform SSO.

This was not previously the case: WHfB registration on a device fell outside the scope of CA policies on 'Register security information'. Administrators who wanted to control who could provision WHfB had no native CA mechanism to do so. That has now changed.

Concretely, this means you can now use Conditional Access to determine under which conditions a user may register WHfB on a new device. You can require that the device is compliant, that the sign-in takes place from a trusted location, or that a strong verification method is already present. This gives IT teams finer-grained control over the roll-out of phishing-resistant authentication within the organisation.

macOS Platform SSO: the same story for Apple devices

The change does not only apply to Windows. macOS Platform SSO, the feature that allows managed Mac devices to authenticate to Entra ID via the secure enclave of the Apple chip, receives the same status. An employee signing in on a managed Mac via Platform SSO will automatically satisfy the MFA requirement in Conditional Access from October onwards.

Platform SSO requires macOS Ventura (13) or later and configuration via an Intune profile or another MDM system. The Secure Enclave of the Apple Silicon chip stores the private key with comparable security guarantees to the TPM on Windows. For organisations with a mixed environment of Windows and Mac, this is a step toward a consistent, phishing-resistant sign-in experience on both platforms.

What should you do now?

Four concrete steps for IT administrators in the run-up to October 2026. First, inventory in your Entra portal how many users already have WHfB configured and on how many devices. The Authentication methods activity reports show the current spread of authentication methods per user.

Second, review your Conditional Access policies for MFA requirements. Look for policies with the grant control 'Require multifactor authentication' and determine whether the intended behaviour still holds after October. Where needed, add an Authentication Strength specification to define more precisely which methods are permitted.

Third, assess your CA policies on 'Register security information'. Since these now apply to WHfB provisioning, you can add specific requirements such as device compliance or trusted location. Do this carefully so that existing onboarding flows for new employees or devices are not unexpectedly blocked.

Fourth, consider broadening the WHfB roll-out if you have not yet migrated all Windows users. The October change makes WHfB even more attractive: users experience fewer prompts, security is phishing-resistant, and no extra Authenticator step is needed. Want help reviewing your Conditional Access policy, rolling out Windows Hello for Business, or configuring macOS Platform SSO? Contact Zarioh.