Passkeys in Windows Hello, Security AND Convenience!

It’s been a while since my last blog post and I’m sorry about that, but now we are together again, and what a reunion this will be 🥳

Passkeys for Entra, saved directly in the Windows Hello container, came into public preview a couple of weeks ago. I know I am late to this party, but I have to say that so far this is all I hoped it would be!

The shift to software-based passkey providers changed that framing entirely. iCloud Keychain, Google Password Manager, Bitwarden, Keeper and so on. Suddenly the devices your users already own became the authenticator. Lower investment, lower friction, better adoption. Win-win.

What is a passkey in Windows Hello, and why does it matter?

Regular readers of this blog know that passkeys are one of my absolute favorite developments in identity security over the last few years. And the moment that really changed the conversation was when passkey support expanded beyond physical hardware keys. Before that, passkeys often got mentally filed under “expensive FIDO2 key procurement project for an unknown security feature.” Not exactly the pitch that wins budget approval. 😂

In November 2025 we got synced passkeys, which opened the door to those cloud-based providers. Now, we can also store passkeys directly in the Windows Hello container on Windows devices, giving end users a Windows Hello-style experience without requiring any special enrollment or device configuration. For many organizations, this is a genuinely meaningful step forward. Beware this feature is still in public preview.

⚠️ Important distinction: Passkeys stored in the Windows Hello container are not a replacement for Windows Hello for Business (WHfB). They are a complementary feature, and it is worth understanding how they differ.

WHfB enrolls a device into a specific environment, stores a single credential in the TPM chip, and is tightly coupled to that setup. Passkeys in Windows Hello also use the TPM chip for storage, but they are not bound to a single enrollment. You can store passkeys for tenants you are not enrolled in, and you can store multiple accounts from the same tenant. It is the same familiar Windows Hello experience at unlock, but with significantly more flexibility underneath.

One important caveat: If a user already has a WHfB credential registered for the same account on that device, passkey registration will fail. Keep this in mind when planning your rollout.

Who is it for?

Before going further, I want to be honest about something: This feature is not for everyone. If your users are already on managed, Entra-joined devices with WHfB, and they only ever touch a single tenant, this feature adds nothing for them. The WHfB credential will block passkey registration for the same account on the same device, as noted above. So who is it actually for?

Guest users are a great example. If the target tenant allows passkeys in Windows Hello, a guest can authenticate phishing-resistant without any enrollment in that tenant’s device management whatsoever. Multi-tenant scenarios are another strong fit: A user who operates across two or more tenants cannot enroll WHfB everywhere, but they can register a passkey in Windows Hello for each. And then there are BYOD and shared device scenarios, where managed enrollment is simply not on the table, but you still want phishing-resistant authentication.

But honestly, the group I think benefits the most from this feature is admins and consultants. People like me, who on a daily basis operate across multiple tenants, multiple customers, each with their own environment and their own rules. Before this, phishing-resistant authentication in all of those tenants simultaneously was a real headache. Now I can register a passkey in Windows Hello for each account, on the same device, with the same familiar Windows Hello experience every time. No extra hardware. No juggling authenticator apps across tenants. Just look at the camera and go.

The pattern is clear: The more a user operates outside the boundaries of a single managed environment, the more valuable this feature becomes.

The real barrier to passkey adoption? End users.

Let me be honest about something that does not always make it into the technical documentation: End users do not care about security. Not really. That is not a criticism, it is just human nature. They care about getting their work done. They care about not being blocked. They care about not having to call the helpdesk.

What they do not care about is whether their authentication method is phishing-resistant.

This is the uncomfortable reality that any security team rolling out passkeys needs to accept early. You can have the most technically sound implementation imaginable, and it will still fail if users find it annoying enough to complain about, work around, or simply not complete.

And the friction threshold is lower than most admins think. Requiring a user to find their phone? Friction. Asking them to plug in a physical security key they left in their bag? Friction. A registration flow with more than two or three steps? Friction. Any of these, on their own, is enough to drive support tickets, incomplete rollouts, and eventually a shelf full of expensive FIDO2 keys that nobody uses.

This is exactly why I have always believed that the path to phishing-resistant authentication runs directly through user experience. If it is not easier than what they are doing today, you are fighting an uphill battle from day one.

Which brings me to why passkeys in the Windows Hello container genuinely excite me. Look at what the registration experience actually asks of the user: They open a browser, navigate to their security info, click to add a passkey, and then… look at their webcam. Or touch the fingerprint reader they already use to unlock their laptop every morning. That is it. No phone to find. No key to plug in. No app to open. No code to type.

It reuses a gesture they already perform dozens of times a day without thinking about it.

That is not a small thing. That is the difference between a security feature that gets adopted and one that gets quietly abandoned after the pilot group. When the path of least resistance and the secure path are the same path, you win. This feature, in my opinion, is one of the best examples of that principle done right!

Client requirement

At the time of writing, the Windows Hello container as a passkey provider works on both managed and unmanaged Windows devices. No Entra join, no MDM enrollment required. On the device side, a TPM chip is recommended but not strictly required, as a software-based fallback exists.

Configuring the tenant

Passkeys in the Windows Hello container are not enabled by default. You need to explicitly allow them through the FIDO2 authentication method in your tenant.

Navigate to Entra ID | Authentication methods | Passkey (FIDO2). Make sure the method is enabled and targeted to the correct user groups.

The following settings are required during the public preview of this feature. We can expect changes to these requirements once this feature becomes GA (Generally Available).

Under the Configure tab, click Add profile. Give it a name and set Enforce attestation to No, this is required during public preview, and registration will fail if attestation is enforced. Set Target Types to Device-bound.

You then need to allow the three Windows Hello AAGUIDs. Microsoft has added these as predefined options in the UI, just select them from the list rather than pasting the GUIDs manually. This is shown in the next couple of screenshots.

For reference, the AAGUIDs are:

👍 As mentioned: Microsoft has Windows Hello (and passkeys in Microsoft Authenticator) as prefined options so you don’t have to enter their AAGUIDs manually!

Finally, assign the profile to the appropriate user groups.

As always: If your tenant has Conditional Access policies requiring phishing-resistant MFA or specific authentication strengths, verify that your Authentication strength definition includes Passkey (FIDO2). The built-in Phishing-resistant MFA strength already covers this, so if you are using that, you are good.

💡 Pro tip: If you are following the TAP-based onboarding approach I described in my previous passkey post, the same flow applies here. The passkey provider is just Windows Hello instead of an external one.

Registering an using passkeys in Windows Hello

The flow for setting up a passkey in Windows Hello is pretty much the same as before. You sign in to https://aka.ms/mysecurityinfo and select Add sign-in method and then select Passkey.

A wizard opens and click next on the first window and verify the next screen reads This will be saved on your Windows device.

Then I authenticate using Windows Hello, in my case that means looking into the webcam.

❗ The screenshot below is worth a closer look. You will notice two different accounts mentioned:

• PattiF@sk47w.onmicrosoft.com at the top: This is the account the passkey is being registered for
• Sorensen, Per-Torben in the Windows Hello greeting: This is the account signed in interactively on the device

This is expected behavior. Windows Hello always greets the user who is locally signed in on the device, regardless of which account you are registering a passkey for. So do not be alarmed if these do not match (they often will not) especially in the multi-tenant and guest scenarios this feature is built for. You should inform your users to avoid any confusion about this.

Last step is to give the passkey a display name, and then you can see the passkey listed under the Security info of the user.

Below you see the end-user experience when signing in with a passkey: The users wants to sign in, we get the passkey-prompt and now I can simply glance into the webcam to sign in. Here we again see 2 different names, with the same reason as explained during passkey registration.

It just doesn’t get much easier than this!

Wrapping up

Passkeys in the Windows Hello container is not a dramatic shift, but sometimes that is exactly what moves the needle. The technical setup is straightforward. The user experience is frictionless. And for anyone operating across multiple tenants, this is a genuinely meaningful improvement.

For years, the “secure path” and the “easy path” have been at odds in identity security. The reason to go phishing-resistant has always been there. What was missing was a way to get there without fighting your users every step of the way. Passkeys in the Windows Hello container change that. That shift, more than any technical detail, is what makes this worth paying attention to.

If you have been waiting for a good time to push phishing-resistant authentication into your unmanaged and BYOD scenarios, this is it. Test it in your own environment, roll it out carefully, and do not forget the TAP-based onboarding flow to keep registration properly controlled.

Thanks for reading, and I promise the next one will not take as long. 😄