Microsoft recently announced the official retirement of SMS and voice authentication, as mentioned here. Passkeys will officially be the default authentication as of September 2026, with SMS and Voice authentication will be retired in February 2027.
I felt that means we should revisit passkeys and talk about some things you need to account for in conditional access and otherwise. If you want a refresher, I’ve written some amazing articles about both things:
- Deep Dive into Microsoft Authenticator Passkeys on iOS
- Moving Passwordless with Temporary Access Passes and Passkeys
- Passkey Architecture and Their Integration Into Windows
- The Magnificent 8 Conditional Access Policies of Microsoft Entra
So, we’ve established I’ve done a ton of work on Passkeys in different ways and just trying to understand it overall. Today, we are going to cover:
- What are Passkeys?
- Configuring the Passkey Authentication Method
- How to Properly Configure Conditional Access Policies for Passkeys
- The Passkey User Experience
What are Passkeys?
We will cover these concepts:
Feel free to look at my article Deep Dive into Microsoft Authenticator Passkeys on iOS to get a good understanding about how it works on an iOS device, but this section overall is to build understanding on how the technology itself works.
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 communication with authenticators, providing really nice interaction flow between RPs and Apps.
One of the ways FIDO extends 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.
Configuring the Passkey Authentication Method
You can easily configure the passkey authentication method. You can check out the video below as well. All it requires is configuring the passkey profile and mapping that profile to a group of people or just mapping it to “All Users.”
One interesting thing to note, is that you can only support “Synced” passkeys if you disable attestation. Ideally, enforcing attestation is very important especially on mobile platforms. You must fundamentally decide if you want “synced” passkeys across devices or if you want to enforce attestation. I will ALWAYS choose attestation over synced as I personally don’t consider synced passkeys to be truly phishing-resistant, which is the main goal.
Feel free to watch the demo below, which shows you how to build the entire thing out from start to finish:
How to Configure Conditional Access Policies for Passkeys
The Conditional Access Policies for supporting passkeys can be a little bit tricky. We will lay it all out, so it makes sense.
You need a few different policies for it to work and allow people to register passkeys organically.
We have 3 policies:
Require MFA for Everyone
This policy specifically is scoped to ALL users and uses the legacy “Require Multifactor Authentication”
It’s weird, but you will see shortly, why we’re not using authentication strength policies and doing anything more than this.
Passkey Registration
This policy helps facilitate the registration of the passkey by targeting the User Action for “Register security information” and enforcing MFA.
Specifically, this policy will enforce MFA when the user tries to register their security information.
You should keep in mind with this, if you’re using “Combined Registration Mode”, which registers auth methods for both MFA and SSPR (self-service password reset) at the same time, what you are allowed to do:
Microsoft also has a really cool flowchart, which explains the experience:
Require Passkey for All Users
This one requires a bit more effort and thought. It requires a few things, but will be what enforces those passkeys:
- We exclude the “Azure Credential Configuration Endpoint Service”
- Create an Auth Strength Policy to enforce passkeys
Okay, let’s discuss these items.
The reason you need to use the legacy “Require MFA” is that it breaks the Azure Credential Configuration Endpoint Service need for passkeys. When you use Auth Strengths instead, it will create situations like this:
The Azure Credential Configuration Endpoint Service is used when auth methods are registered and will be seen as an actor in your audit logs. This service handles all of the backend credential processing, security keys, and more. It’s vital to exclude that out to make all of this work.
Second, we create the Auth Strength Policy, which is very easy to do. You go here, select “New Authentication Strength” and add the authentication methods that you want to use, as you can see its very easy:
Select “Advanced Options” and then configure what passkeys you want to configure:
Check out this video on creating the auth strength policies below, which will help you out:
Once done, it’s super easy. You do it the same as a regular MFA policy, but use “Require Authentication Strength” instead of “Require MFA”:
The Passkey User Experience
The passkey user experience can be a bit confusing and has a few different moving parts. The ideal goal is for it to be as seamless as possible. Luckily, when it becomes the default things will start to flow much easier.
Check out my video below, which shows that experience:
