Windows Hello for Business Standalone MFA Factor Entra October 2026: The Second Passkey Requirement Disappears

Windows Hello for Business Standalone MFA Factor Entra October 2026: What Microsoft Announced

Windows Hello for Business standalone MFA factor Entra October 2026 is the change identity teams should already be planning for. In Message Center post MC1450134, "Microsoft Entra: Windows Hello for Business and macOS Platform SSO as standalone MFA factors" (published August 7, 2026, updated August 18, 2026), Microsoft states that Entra will "recognize Windows Hello for Business (WHfB) and macOS Platform Single Sign-On (PSSO) as standalone multifactor authentication (MFA) factors in supported authentication scenarios."

The rollout window is specific. General Availability for Worldwide and GCC tenants begins "in early October 2026 and expected to complete in late November 2026." Microsoft tags the post planForChange at normal severity and says plainly that "no configuration changes are required."

That last sentence is the part worth slowing down on. No admin action is required, but the authentication posture of every tenant where people sign in with Windows Hello or a Mac changes on its own — including how many of your accounts Entra reports as MFA-capable, and which devices a user can still authenticate from when something goes wrong.

What Actually Changes, and What Already Worked

Windows Hello for Business is not being added to authentication strengths — it has been there. Microsoft's authentication strengths reference lists "Windows Hello for Business or platform credential" as satisfying all three built-in strengths: MFA strength, Passwordless MFA strength, and Phishing-resistant MFA strength.

What has not worked reliably is the re-authentication path. The same page documents today's limitation in Microsoft's own words:

That is the gap MC1450134 closes. Per the message center post, these are the behaviors after rollout:

Two of those rows deserve emphasis. The MFA-capable row means your compliance number moves without a single user registering anything new — if you report "percentage of users MFA-capable" to an auditor or a board, re-baseline it before and after the rollout so you can explain the jump. The registration-nudge row means the safety net that used to catch single-method users quietly goes away.

Microsoft also files a known issue on that same authentication strengths page that is worth re-reading in this light: when a resource requires both an authentication strength and a sign-in frequency, users "can satisfy both requirements at two different times," and Microsoft's own example is a user unlocking their Windows device with Windows Hello for Business to satisfy a one-hour sign-in frequency while a 24-hour-old passkey sign-in satisfies the strength.

The Catch: Device-Bound Credentials Do Not Travel

Microsoft flags the risk itself, in the "Action required and recommendations" section of MC1450134: "Because WHfB and macOS PSSO credentials are device-bound, users may not be able to complete MFA challenges from devices where those credentials are not available."

That is not a hedge. It is the defining property of both credentials:

• Windows Hello for Business is described by Microsoft as "primarily a device-bound sign-in method linked to device trust," with the credential "tied only to the work or school account used to register the device." Its passkey type is listed as device-bound, not synced (Microsoft Entra passkey on Windows).
• Platform Credential for macOS "provisions a secure enclave backed hardware-bound cryptographic key," built on Windows Hello for Business technology (Platform Credential for macOS).

Microsoft's registration campaign documentation already shows how narrow that binding is in practice. The passkey nudge is evaluated per device-and-browser combination, and the published platform table shows a Windows Hello for Business credential suppresses the nudge only on Windows, while a Mac Platform SSO credential suppresses it only on macOS. Microsoft's own worked example: "if a user has a Windows Hello for Business credential and signs in on Windows with Chrome, the nudge is suppressed. But if the same user signs in on a Mac with Chrome, they're nudged because that credential doesn't apply to that platform." The same page notes that Linux users are never nudged, because FIDO2 passkeys aren't available on Linux.

Put the pieces together and the exposure is concrete. After October, a user whose only registered MFA credential is a Windows Hello for Business credential counts as MFA-capable, stops being nudged to add anything portable, and still cannot complete an MFA challenge from a personal phone, a loaner laptop, a Mac, or a Linux workstation. Broken laptop, reimaged device, travel day, incident response from someone else's machine — those all become helpdesk calls rather than a second-factor prompt. That risk lands hardest on the accounts you can least afford to lock out, which is why emergency access accounts should never depend on a credential bound to one machine.

This also runs alongside the SMS and voice MFA retirement and the passwordless MFA registration change: the portable fallbacks many tenants still lean on are being removed at the same time the system stops asking users to register a replacement.

Detection: Find Your Device-Bound-Only Users Before October

Everyone registered for a passwordless method — FIDO2, Windows Hello for Business, or passwordless phone sign-in. This is the outer ring, not the answer:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isPasswordlessCapable eq true

Everyone holding a device-bound FIDO2 passkey. Note what this does not return: passKeyDeviceBound is the device-bound passkey method, not Windows Hello for Business or macOS PSSO, so on its own it will not find the WHfB-only users this section is about:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=methodsRegistered/any(x:x eq 'passKeyDeviceBound')

Microsoft documents methodsRegistered as filterable with any/eq but does not publish the full set of values it can hold, so do not guess at a method string inside $filter. Pull methodsRegistered for every user and filter locally — which is what the export below does — or read the Methods registered column in the portal, where Windows Hello for Business is listed by name.

Import-Module Microsoft.Graph.Reports

# Baseline every user's registered methods before the rollout starts.
# Requires AuditLog.Read.All (Reports Reader, Security Reader, Security Administrator or Global Reader).
Get-MgReportAuthenticationMethodUserRegistrationDetail |
  Select-Object UserPrincipalName, IsAdmin, IsMfaCapable, IsPasswordlessCapable,
    @{Name = "Methods"; Expression = { $_.MethodsRegistered -join ";" }} |
  Export-Csv .\entra-mfa-baseline-pre-october-2026.csv -NoTypeInformation

Remediation: What to Do Before the Rollout Starts

1. Make one portable method mandatory in onboarding. This is Microsoft's own first recommendation in MC1450134: "Update onboarding guidance to ensure users register at least one portable MFA method." A device-bound credential plus nothing else is a single point of failure per user.
2. Pick the portable method deliberately. Microsoft suggests "a synced passkey or Microsoft Authenticator passkey in addition to WHfB or macOS PSSO." Note the trade-off Microsoft documents: "Synced passkeys do not support attestation," so a profile with Enforce attestation set to Yes excludes them at registration time — Microsoft's own worked example for high-privileged accounts pairs attestation enforcement with device-bound only (enable passkeys (FIDO2)). Decide which of those two properties you actually need before you publish the guidance.
3. Audit custom authentication strengths. MC1450134 asks you to "review custom Authentication Strength policies to confirm WHfB and macOS PSSO are allowed where appropriate." The three built-in strengths already include "Windows Hello for Business or platform credential"; it is the custom ones you wrote yourself that may now behave differently than you assumed.
4. Check your passkey profile AAGUID allowlists before telling users to register. If you use key restrictions, Microsoft documents that the macOS Platform Credential AAGUID 7FD635B3-2EF9-4542-8D9D-164F2C771EFC must be in the allowed list for WebAuthn challenges. For Windows Hello passkeys, the documented AAGUIDs are 08987058-cadc-4b81-b6e1-30de50dcbe96 (hardware TPM), 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (VBS hardware) and 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (software TPM) — and Microsoft notes a profile targeting them cannot enforce attestation.
5. Fix break-glass accounts first. Emergency access accounts must be reachable from a device that is not the one that broke. Confirm they hold a portable credential and remain excluded from the policies that would otherwise strand them.
6. Re-baseline the MFA-capable metric and tell whoever consumes it. The number will move because the definition moved, not because coverage improved. Compare your pre-rollout CSV against the post-rollout one rather than reporting the new figure as progress.
7. Test in report-only mode. Conditional Access policy changes you make in response to this should be validated against real traffic before enforcement, the same discipline that catches the baseline policy coverage gaps most tenants carry.
8. Update helpdesk documentation. MC1450134's final recommendation is explicit: users with only WHfB or macOS PSSO "will no longer be automatically guided to register an additional MFA method," so the guidance has to come from you. A wider review of where this sits in tenant hygiene is covered in our Entra ID audit guide.

How EtcSec Detects This

EtcSec's Conditional Access and privileged access checks target the conditions that turn this rollout from a non-event into a lockout. CA_NO_MFA_REQUIREMENT flags tenants with no policy actually requiring MFA, where a shifting MFA-capable count creates false confidence. CA_NO_BREAK_GLASS_EXCLUSION catches emergency-access accounts without a documented exclusion pattern — the accounts most likely to be stranded by a device-bound-only credential. PA_GLOBAL_ADMIN_NOT_MFA surfaces privileged accounts whose MFA enforcement does not hold up. CA_NO_SESSION_CONTROLS finds tenants relying on sign-in frequency that WHfB and macOS PSSO will now satisfy during 2FA, and CA_POLICY_REPORT_ONLY catches the policies you tested for this change but never actually enforced.