A few weeks about passkeys were introduced in public preview in Entra. This is a huge deal and every person is basically writing articles about passkey this and passkey that. I thought I would go about it in a different way digging deep into the architecture and then discussing Entra. Today we will discuss:

• Passkey architecture
• How Do Passkeys work?
• Passkey Storage on Windows Powered by TPM
• Passkeys in Windows
• Passkey Supportability
• Implementing passkeys in Microsoft Entra ID

We have a ton to cover on the architectural side, so let’s get started with this passkey party.

Passkey Architecture

So what exactly are passkeys anyways? Simply, the idea is that we move from username and password to a cryptographic model. Passkeys by design are 4 things:

• User-centric and simple by simply providing approval to create and use them.
• Unique keys by service with zero reuse.
• Passkeys are only stored on a user’s device. Relying party (RP) servers will store public key like a standard public key/private key architecture. Private keys are secure and even sync services cannot access them.
• Phishing-resistant authentication that eliminate a human component and ensures only the right service can use them.

Account bootstrapping powers the passkey journey similarly to a user onboarding workflow. At a programmatic level, you start by verifying their authentication method was sufficient. Maybe that means they used MFA, or hardware token, or whatever your standard is.

After that, they send a call to ensure the device and OS support passkeys:

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()

Based on that response, the website will prompt you to create a passkey. Some of the sites that support passkeys are found here. You can see Kayak is prompting me to create a passkey at account creation:

They are using a call known as “navigator.credentials.create(), but I won’t waste more time on that. Once that WebAuthn call resolves, a response is sent back that will associate a public key and the WebAuthn credential ID (unique ID that identifies the passkey credential).

The nice thing is with reauthentication flow it functions the same way leveraging the same WebAuthn API calls with navigator.credentials.get for subsequent authentication attempts.

How Do Passkeys Work?

Passkeys are facilitates by two technical specs synergistically. WebAuthn as hinted at previously aka “W3C Web Auth” and Client to Authenticator Protocol (CTAP). CTAP, which is part of FIDO handles communications with the authenticator via USB, NFC, and Bluetooth. Your OS will leverage CTAP to pass requests from WebAuthn to the authenticator over the intended transport. CTAP simplifies the communication with authenticators, providing really nice interaction flow between RPs and Apps.

One of the ways FIDO is extending the usability of passkeys is with Cross-Device Authentication (CDA), which makes passkeys the first phishing resistant authentication method that can be used on a different device. This has been one of the issues with Okta’s phishing resistant authentication. You had to use Okta Verify as an example on the device you are authenticating on to maintain phishing resistant authentication. CDA is powered by the previously mentioned CTAP.

Taking it one step further, vendors like Microsoft are implementing synced passkeys which will make a passkey on your mobile device available on your Windows desktop (as an example). Today, we will be primarily focusing on “device-bound passkeys” which are bound to a single authenticator. This means the credential itself cannot leave the device.

Passkey Storage on Windows Powered by TPM

So let’s take a few minutes and talk about TPM. As we know, TPM is the microsoft designed to provide security functions like encryption on Windows devices today. The TPM lets you create cryptographic keys and encrypt them. This lets your TPM act as the sole thing that can decrypt those keys.

The TPM has a primary wrapping key called the “storage root key” stored inside of the TPM. In addition, the Endorsement Key is the private part of the EK never exposed to anything.

The TPM, the private keys are separated from the memory controlled by the OS. You can seal keys to the TPM and assurance about system state can be made before unsealing keys. The TPM key storage provider (KSP) is where your passkey private keys will be stored as seen above. These keys cannot leave the TPM.

Part of the capabilities of the TPM, will let you enforce lockout for only the device PIN. Part of that security is TPM 2.0 anti-hammering where the TPM will lock after 32 authorization failures. Overall, the security provided by TPM is very compelling. It’s good to note that the TPM is also what protects the secrets that power Windows Hello for Business as well.

Passkeys in Windows

As of Windows 11 22H2, Windows now offers a native experience for passkey management. From an OS supportability, Windows Pro, Enterprise, and Education all support passkeys now.

Within Windows, you can leverage passkeys on the local Windows devices itself or with FIDO security keys. Not every hardware security key supports passkeys, but for example Yubico supports it from YubiKey 5 Series+.

You can see passkeys within the settings menu easily today:

At this point, it doesn’t appear you can access/view passkeys in CMD like you can with Windows Hello credentials AKA Microsoft Passport:

Passkey Supportability

As far as device support goes, this nice matrix shows you what the level of support for passkeys are:

Implementing passkeys in Microsoft Entra ID

The good news is implementing passkeys in Entra is pretty easy. My video below walks through the entire thing.

Simply, you enable FIDO 2 security keys in the Entra auth methods:

You should also look at the security settings. Make sure to leave attestation off so you can actually use it. I also added the AAGUID for my Yubikey. You can find that awesome blog with all of the AAGUIDs here:

One thing I didn’t cover in my video is adding the AAGUID for Microsoft Authenticator passkeys:

• Authenticator for Android: de1e552d-db1d-4423-a619-566b625cdc84
• Authenticator for iOS: 90a3ccdf-635c-4729-a248-9b709135078f

You will also create the authentication strength method for your passkeys (including the Authenticator AAGUIDs) below. You can use this into your Conditional Access policy that I cover in my video demo below:

Once you finish enabling things, you can go to your Sign-In Methods and register here. In a later blog article, I will cover the mobile passkeys with authenticator as it has plenty of cool stuff in there.

From here, you register your FIDO key to use for the passkey:

Enjoy my video demo:

Final Thoughts

So, the gist of this article is DON’T BE AFRAID OF PASSKEYS. Credentials are bad. Certs are good. There’s a ton of dissention on passkeys right now. They are the future and I know certificates are scary. If you want to learn more about PKI (Public Key Infrastructure) there are tons of great resources out there. Anyone on the Windows side should be putting in the work to learn about certs, TPM, and encryption overall. They are key aspects to securing Windows devices.