Introduction

At Ignite 2025, Microsoft announced Entra ID would be supporting Synced Passkeys for multiple credential providers.

This means users can now create phishing resistant credentials, and sync those credentials across devices. This new authentication method has a lot of advantages, but also raises a couple of questions. Let’s go over them together.

Synced passkeys

The benefits

1. Stronger security

Obviously, passkeys provide phishing resistant authentication meaning users are protected against attacks such as access token stealing. This method introduces better security than basic MFA methods, and ensures attackers are only able to compromise the login when the system where the passkeys is stored is compromised.

2. Seamless multi-device access

When passkeys are synced across devices, you can log in from any device instead of having to rely on a passkey on a specific device. This is especially useful if you switch between devices frequently.

3. Reduced account recovery hassles

If you lose one device, synced passkeys ensure you still have access to the passkeys via other devices. This makes recovery easier compared to device-bound passkeys.

Enabling synced passkeys

To enable synced passkeys as an administrator, you need to go to the authentication methods blade in the Entra ID admin portal and navigate to the Passkey (FIDO2) authentication method.

Since synced passkeys are still in public preview, you must opt-in to the public preview by clicking the banner at the top of the page:

When clicking the banner, you will be redirected to the new ‘Configure’ tab where you will be able to configure a maximum of three passkey profiles. As the banner states, you must configure the ‘Default passkey profile’ to target at least one passkey target type. Here you can choose between ‘Device-bound’ and ‘Synced’ passkeys.

Important to note here is that you cannot enforce attestation when you want to allow Synced passkeys. Once you enable ‘Enforce attestation’, the synced passkeys option in ‘Target types’ is removed:

After you configured the ‘Default passkey profile’, you need to assign the profile to your users. You can either do this to ‘All users’, or you can select specific groups in Entra ID:

Register a synced passkey

To register a synced passkey as a user, the user can navigate to their ‘Security info’ blade under My Account and click on ‘Add sign-in method’.

If passkeys are properly enabled in the authentication method portal as discussed earlier, you get the option to choose for ‘Passkey’:

In the next pop-up you can either choose to click ‘Next’, or you can choose to click ‘Create a passkey using another device’. In this example we will start with creating a passkey on a phone using Google Password Manager. Even though this passkeys will be created on my phone, I learned during my tests that both buttons lead to the same flow. This means you can just use the ‘Next’ button.

After clicking the ‘Next’ button, a pop-up will ask you where you want to store the passkey. In my tests, it defaults to ‘your Windows device’ (I only tested this on Windows).

However, when you click the ‘change’ button, you get a list of other devices where you can store the passkey on. For the Google Password Manager demo, I chose ‘OnePlus 10T 5G’ since this is my phone that is connected to my Windows device.

In the next pop-up, you will see that a notification is being sent to your phone. When opening your phone, you will see that the Google Password Manager will ask you if you want to save the passkey via a pop-up message. Confirm and follow the steps on your phone.

Once you are done on your phone, Microsoft will ask you to give a name to your passkey. Even though you can choose the name, I find it very nice that they recognize the service that will store your passkey:

After you clicked the ‘Next’ button, the passkey should be saved (if all went well).

Register a synced passkey with a password vault

What is interesting with synced passkeys, is that some password vaults also support to store passkeys. Since most organizations provide their employees with enterprise password vaults, it can be interesting for your employees to store their Microsoft passkeys there as well. In below demo, I show how you can save a passkey to Keeper.

Before you begin, you need to make sure that the Keeper extension is installed in the browser that you use and that prompts are allowed in the settings of the extension.

Once this is the case, go to the ‘Security info’ blade under My Account again and click on ‘Add sign-in method’. Here you again choose for ‘Passkey’, and continue to click ‘Next’.

Even before the Windows pop-up appears on the screen, you will see that the Keeper extension will ask you if you want to save the passkey in Keeper. Here you can click on ‘Create Passkey’:

You will be redirected to the My Account page again, where you can save the passkey under a name you choose.

After you clicked the ‘Next’ button, the passkey should be saved (if all went well).

To login with the passkey, you simply fill-in your UPN in the Microsoft login page and choose to login with ‘face, fingerprint, PIN, or security key’. Keeper will automatically provide a pop-up asking you if you want to login with your passkey.

After clicking ‘Use Passkey’, you will be signed in. One caveat that is important to note is that passkey usage does not seem to work if you did not enter your UPN yet.

If you choose your passkey without entering the UPN first, Keeper seems to give a ‘SecurityError’.

Security thoughts

As you might have noticed when configuring Passkey profiles in the Entra admin blade, you cannot choose to enforce attestation when you want to allow Synced passkeys. In the Microsoft Learn pages they describe that this means Entra ID can’t guarantee any attribute about the passkey, including if it’s type, make, model, provider, and even the Target specific AAGUIDs.

This begs the question in which scenarios you want to allow synced passkeys.

Pro synced passkey scenarios

Since passkeys provide stronger authentication then standard MFA, it is a big step forward to drive secure phishing resistant authentication for your users. Therefore, I would recommend to allow synced passkeys for end-users if that helps to go to an environment with phishing resistant authentication.

However, I do recommend to create a formal risk analysis of the risk vectors synced passkeys introduce as well. Some risk vectors are:

1. Stolen passkey via non company managed credential store

If a user saves their company passkeys to a personally owned credential store (like Google Password Manager or a personally owed Password Manager), the passkey can be leaked if an attacker is able to compromise that personally owned credential store. Since this credential store is not managed by the company, you have no insights to where the passkey exactly lives and if it is properly secured.

2. No attestation on passkey registration

Although we will cover AAGUID allow and block listing later, you are never 100% sure if the AAGUIDs of the Synced passkeys are correct or not. This means that allow or block listing of specific credential managers cannot be fully used as a security control for Synced passkeys.

If you do want to allow Synced passkeys to your end-users as an organization, but still want to allow only specific credential managers, it might be a good idea to only allow the AAGUIDs related to the password manager that you provide to your end-users in the organization. But keep in mind, since attestation cannot be enforced on Synced passkeys you should use this controls as an organizational policy guide rather then an security control. To find the AAGUIDs related to specific credential managers, you can use the Passkeys Authenticator AAGUID Explorer project. This is a community driven project that documents the AAGUIDs of well known credential managers.

Let’s say you only want to allow Keeper as a credential manager for synced passkeys. To configure this you go to the authentication methods in Entra ID again, and configure a passkey profile that only allow the AAGUID of Keeper:

Additionally, you then need to decide which group of users are allowed to use these Synced passkeys:

Against synced passkey scenarios

As discussed in previous section, there are a couple of risk vectors that are being introduced when using synced passkeys. The main challenge with these synced passkeys is that you cannot really trust the properties of the passkey when registered, since attestation cannot be enforced. Therefore, I personally recommend against allowing synced passkeys for privileged accounts for the following reasons:

• No control on where the passkeys live, and if they are securely stored
• You cannot rely on AAGUID allow or block listing as a security control
• Passkeys can be easily synced from privileged devices (such as PAWs) to non-privileged devices

There are a couple of ways on how you can configure Entra ID to only allow synced passkeys for non-privileged users. In the below scenario I used dynamic security groups in Entra ID based on an admin naming convention, which we can use to assign passkey profiles to.

First I created a dynamic group that gets all the admin accounts based on the their UPN:

Secondly, I created a second dynamic group that gets all the non-admin accounts based on the UPN:

In the third step, I configured two passkey profile where the default profiles allows all types of passkeys while the second profile only allows device bound passkeys with attestation enforced.

And lastly, I assigned the passkey profile to the dynamic groups. Making sure admins can only register device bound passkeys and non-admin users can use all kinds of passkeys:

Lockout scenarios

It is important to think of the lockout scenarios that can happen with synced passkeys. In the sections discussed earlier, we used an example where you can create a passkey policy for your end-users that only allowed them to register a synced passkey with an enterprise credential manager like Keeper. This can be done be only allowing the Keeper AAGUID. But if the enterprise credential manager is SSO integrated, users need to be able to login to that credential manager before they can use the passkey. If the user then only has one passkey - the one being on the credential manager - you have a chicken / egg scenario locking out the user from the environment.

Therefore, it is important in scenarios where you restrict the credential managers for passkeys, that user enroll at least two passkeys. One that is stored in their credential manager for easy access when their are logged into it, and one that can be used to access the credential manager. Examples of a second set of passkeys that can be used are Windows Hello for Business, or device bound passkeys in Microsoft Authenticator or FIDO Keys.

Restricting keys in conditional access

Instead of restricting key registration in authentication methods, you can also choose to restrict key usage on authentication by enforcing authentication strength in Conditional Access. You can do this by navigating to the authentication strength page in the Entra admin portal, and creating a new authentication strength for passkeys.

Once configured, you can use the authentication strength in Conditional Access:

The big downside of doing the restriction this way, is that you can only rely on the AAGUID to do the key restrictions. If you remember from the previous sections, the AAGUID is not reliable to be used as a security control for synced passkeys since key attestation cannot be used. Therefore, I recommend do not use this method of key restriction for users that are allowed to register synced passkeys.

I think it well be very helpful if we could check on device-bound or synced passkeys in authentication strengths as well. If we could do this, we would be able to allow admins to register synced passkeys, but enforce them to use a device-bound passkey for highly privileged operations via Conditional Access. Let’s hope this is a feature that Microsoft will provide in the future.

Conclusion

I love that synced passkeys are now supported in Entra ID! It will help organizations a lot in pushing phishing resistant authentication forward to their end users, since we now have far more possibilities to store our passkeys. However, organizations need to be aware of the risk vectors synced passkeys introduce compared to device-bound passkeys as well, and choose wisely if they want to allow synced passkeys for all scenarios and users or not.