Microsoft Entra Passkeys on Windows Bring Phishing-Resistant Sign-In to Unmanaged PCs
Microsoft is extending Entra passkeys on Windows to a part of the estate that has usually fallen back to weaker sign-in: personal, shared, and otherwise unmanaged PCs. The practical change is not that Windows gets a new passwordless option in general, but that organizations can now use phishing-resistant Entra authentication on Windows devices outside the usual managed, Entra-joined setup, using Windows Hello biometrics or PIN.
What changed, and where it matters most
The rollout enters public preview worldwide from mid-March to late April 2026, with government clouds following later. The key coverage expansion is outside managed environments. Windows Hello for Business already serves managed, Entra-joined devices well, including device sign-in and access to cloud resources. The new Entra passkeys on Windows fill the gap for users who still need secure access from personal or unmanaged Windows machines.
That distinction matters because many organizations have mixed device realities even when their policy assumes a cleaner environment. Contractors, hybrid workers, shared PCs, and bring-your-own-device cases often end up relying on passwords or less consistent second-factor flows. Entra passkeys on Windows give those scenarios a phishing-resistant option without requiring the device to become part of the managed fleet.
How the Windows implementation actually works
The passkey is device-bound and stored in the Windows Hello container. Authentication uses Windows Hello’s biometric or PIN methods to unlock the credential locally, while Entra ID relies on public-key cryptography: the private key stays on the device and the public key is registered with Entra. That design reduces remote theft risk because the credential itself does not leave the PC.
It also means these passkeys do not sync across devices. A user who signs in on three Windows PCs needs three separate registrations. In practice, this behaves more like an integrated hardware security key than a cloud-synced consumer passkey model. Multiple Entra accounts can exist on one machine, but each account needs its own passkey registration on that device.
One common misread should be corrected early: this does not replace Windows Hello for Business. It adds another Windows-based authenticator path for Entra accounts in scenarios where Windows Hello for Business is not the deployed answer.
What admins have to configure before anyone can use it
This is not on by default. Organizations must enable Passkeys (FIDO2) in Entra Authentication Methods, then create and assign a passkey profile to the relevant user groups. During public preview, administrators also need to explicitly allow the Windows Hello authenticator by configuring the appropriate Authenticator Attestation GUIDs, or AAGUIDs.
There is also an account-level constraint that affects rollout planning: users cannot register an Entra passkey on Windows if a Windows Hello for Business credential already exists for the same account and container. That prevents simple side-by-side registration in every case and makes targeting important, especially in environments where some users move between managed and unmanaged devices.
| Deployment point | What to know |
|---|---|
| Feature enablement | Enable Passkeys (FIDO2) in Entra Authentication Methods. |
| Windows allowance | Whitelist the Windows Hello AAGUIDs during public preview. |
| User targeting | Assign the passkey profile to selected groups rather than assuming universal fit. |
| Registration prerequisite | User must complete multifactor authentication within five minutes before passkey registration. |
| Coexistence limit | No Entra passkey registration if Windows Hello for Business already exists for the same account/container. |
| Device behavior | Passkeys are local to each Windows device and do not sync across PCs. |
What stays the same in policy and governance
Existing Conditional Access policies do not need to be rewritten just to accommodate this feature. Entra passkeys on Windows satisfy phishing-resistant authentication strength, so organizations already using authentication strength requirements can apply them here without creating a separate policy branch.
That said, “no policy changes required” is not the same as “no validation required.” Teams with strict Conditional Access designs should test registration and sign-in flows before broad rollout, especially where authentication strength, device assumptions, and account segmentation intersect. The governance question is less about compliance exceptions and more about whether current policy logic still matches real user paths on unmanaged devices.
Where the operational friction will show up first
The main deployment limit is not cryptography but scale management. Because passkeys are per-device and non-syncing, onboarding becomes a repeated process for users with multiple Windows PCs. Recovery also depends on other trusted devices or authenticators, which means helpdesk workflows need to be ready before rollout, not after lockouts start.
Organizations should pay particular attention to multi-account and multi-device cases. A user may be able to keep several Entra accounts on one machine, but each registration is separate, and the Windows Hello for Business conflict for the same account/container adds another edge case. The next useful checkpoint is not whether passkeys are more secure in theory, but how registration, support, and user communication are handled when unmanaged Windows access becomes part of the passwordless program.
Quick answers
Do Entra passkeys on Windows sync across devices? No. Each Windows PC needs its own registration.
Do they replace Windows Hello for Business? No. Windows Hello for Business remains the recommended option for managed, Entra-joined devices.
Will Conditional Access need to be rebuilt? Generally no. Existing policies continue to apply, and passkeys meet phishing-resistant authentication strength.
