Huge Entra Passkeys changes – Part 1

If you’ve read my earlier posts regarding passkeys, you know that Entra Passkeys was my number 1 anticipated feature in 2024, even more than Copilot for M365. It was launched in public preview in April of that year but it was quite frankly a dud. Perhaps the most frustrating limitation was that passkeys were locked to the Microsoft Authenticator mobile app, with no option for alternative storage.

I have mentioned the shortcomings and frustration of passkeys back then more than once, but now that we’re about to close out 2025, have things improved?

Big Changes Bring Bigger Consequences

In this post I will focus on what I think is a very controversial move by not only Microsoft, but other providers with the same functionality. I’m thinking about synchronized passkeys which is now available in public preview. Now at their core, passkeys rely on PKI, the same proven cryptographic foundation we’ve used for decades in certificates and secure communication.

One of the core concepts it’s built upon is that the private key is treated like The One Ring which Frodo must carry to Mordor: “Keep it secret. Keep it safe“. It never leaves the device where it is installed, because if an attacker manages to get the private key, they can impersonate the legitimate user, access all protected resources, and even forge trusted communications. In short: A catastrophic breach of security!

So at Ignite 2025, Microsoft announced synced Passkeys for Entra, and and I, for one, have quite a few reservations. I completely understand the appeal for an end-user of syncing your passkeys, and I know that this will improve user friendliness dramatically. But is it worth it?

🚨 Device‑bound passkeys vs syncable passkeys is a security trade‑off.

Device‑bound passkeys keep private keys on a single authenticator (like a phone or hardware key), minimizing exposure and reduce the attack surface for credential compromise.

Syncable passkeys make sign‑in seamless across devices, but that convenience comes at the cost of expanding potential attack vectors. The credential material can be targeted through the sync service itself, compromised accounts, or weak recovery mechanisms. So the security of the passkey provider (explained below) directly impacts the security of the passkey itself.

I may sound skeptical about synced passkeys, but the reality isn’t that black and white. When you look at the alternatives, the picture changes. If the choice is between users adopting syncable passkeys or sticking with passwords plus MFA, then to me there’s no question: Synced passkeys are the better option by far! They deliver passwordless, phishing-resistant authentication. In essence, we’re trading a proven defense against phishing for a far less common attack vector.

The Silver Lining of Syncable Passkeys

First we need to explain briefly what a passkey provider is.

A passkey provider is the system that stores, discovers, and presents your FIDO2/WebAuthn passkeys to apps and browsers so you can authenticate. Think of it as the “home” and interface for your credentials. As just mentioned, providers can be either device‑bound or syncable: Device‑bound keeps keys on one authenticator, while syncable makes them available across devices via the cloud).

The silver lining is that when you enable syncable passkeys in Entra, both iCloud Keychain and Google Password Manager are automatically included as providers. (This is currently not available for device-bound passkeys).

🥳 In practice, this means you’re (finally!) no longer limited to storing passkeys in the Microsoft Authenticator app, you can now keep them in iCloud Keychain or Google Password Manager instead. At first glance this might not seem significant, but this is huge since it removes dependency on a single mobile device. Passkeys can now be accessed directly on an iPad, Chromebook, or any other iOS/Android‑based device, giving users far more flexibility in how and where they authenticate. The downside is again that these are synced, so the attack surface for the passkey is potentially slightly larger.

This addresses my huge gripe about passkeys and securing users in environments where a mobile device is not available. Like elementary schools, hospitals, industrial sectors etc. This change is, in my opinion, much more important than being able to sync your passkeys.

In short: Enabling syncable passkeys also enables additional passkey providers, removing the Microsoft Authenticator dependency!

🚨 A synced passkey means the passkey is synchronized across devices that use the same provider. It does not sync between different providers. For example, a passkey stored in Google Password Manager is only available there and won’t appear in iCloud Keychain, Microsoft Authenticator, or other providers.

Configuring you tenant

In Entra you need to navigate to Authentication methods, and select Passkeys (FIDO2). Here you have an option to opt-in to the public preview of syncable passkeys.

You will receive a prompt for converting your settings into a default passkey profile. Currently Entra allows you to configure up to 3 passkey profiles to help you set different requirements and restrictions for different personas in your environment. Make sure your default passkey profile is set up, or it will revert to the standard configuration.

Below is the edit screen where you must choose:

• Enforce attestation: Yes/no (description further below)
• Target types: Device bound and/or syncable passkeys
• Target specific AAGUIDs: Allows you to specify specific models of passkeys providers and to allow only those specified or block those specified

What is attestation?

Attestation in FIDO2 works much like the role of a trusted Certificate Authority in traditional PKI. When you create a new passkey, your device generates a key pair and sends the public key to the service you’re registering with. Alongside that, it includes an attestation certificate signed by the device’s manufacturer. This certificate acts as proof that the authenticator is genuine and that the key was created securely on a trusted device, just as a CA’s signature proves that a website’s certificate is legitimate and issued by a recognized authority.

The service receiving the passkey can then check the attestation against a list of trusted vendors, similar to how browsers verify whether a site’s SSL certificate comes from a trusted CA. This allows organizations to enforce policies, such as only accepting passkeys from devices that meet certain security standards. At the same time, attestation can reveal details about the device model or brand, which raises privacy considerations. To balance this, many services accept self‑attestation, which is like issuing your own certificate: it doesn’t provide the same level of assurance about the device, but it still proves the key is valid and usable.

👉 As of today: Syncable passkeys requires you to disable “enforce attestation“.

Once you’ve created your default passkey profile, you can add up to two additional profiles. A practical approach I would recommend in general is:

• One default profile for everyday users
• A stricter profile for accounts with elevated privileges.

The profile for accounts with elevated privileges should enforce attestation, device bound only and if possible restrict to a specific set up AAGUIDs. Enforcing AAGUIDs for privileged accounts is a good option because it ensures only trusted, verified authenticator models can be used, reducing the risk of compromised or insecure devices being allowed.

😂 Because no admins should use a cheap FIDO2 key they picked up from Donnie Do-Bad who runs the shady store around the corner. 😉

The end-user experience for syncable passkeys

Let’s set privileged accounts aside and focus on passkeys in Google Password Manager. Let’s test this feature with Lynne Robbins, who currently has no MFA methods assigned, using the default passkey profile we configured first.

So I’m providing her a TAP for signing in with it, just like in this previous post, and now I’m ready to register a passkey.

When adding an MFA method, this can be unintuitive, but the middle option “Passkey” represents any passkey outside of the Microsoft Authenticator mobile app (which is the top option).

Select Next

Click “Change” for location

Select “iPhone, iPad or Android device“, and then scan the QR code on the screen with the device you want to store the passkey in. If you scan it with an iOS device, the passkey will be stored in the iCloud Keychain for the account signed on that device. Likewise if you scan the QR code with an android device, it will store the passkey in Google Password Manager for the account signed in to that Android device.

Here I’ve scanned the QR code with an android phone, and I will keep the suggested passkey name and complete the wizard.

Now Lynne has a synced passkey stored in Google Password Manager. It works anywhere that passkey provider is supported, signing her in through that Google account.

➖ It’s important to keep in mind that once a passkey is stored in Google Password Manager, its overall security is tied directly to the strength of your Google account itself. In theory, the passkey could be compromised if any place where that Google account is signed in is not properly secured. This means the protection of your passkey doesn’t just depend on the device you registered it with, but also on how well your Google account is safeguarded through measures like strong passwords, multi‑factor authentication, and careful management of where you stay signed in. The same principle applies to using iCloud Keychain.

➕ On the other hand, in environments without mobile phones (schools, hospitals, industrial settings), synced passkeys are a huge improvement over having no MFA at all. By allowing credentials to be stored in services like iCloud Keychain or Google Password Manager, users can authenticate securely on shared or non‑mobile devices without relying on a phone. This means that instead of falling back to weaker, single‑factor logins, organizations in these settings can still benefit from the stronger protection of passkeys (something that’s often missing in mobile‑restricted environments).

Outro

🚨 Phishing is the most prevalent attack vector today, and it’s a threat that every organization MUST take seriously.

As we move into 2026, phishing‑resistant multi‑factor authentication is more important than ever. Passkeys in Entra are stepping into that role, evolving from an experimental feature into a cornerstone of modern identity. Syncable passkeys bring undeniable convenience, but they also potentially expand the attack surface in ways organizations must carefully weigh.

The real challenge isn’t whether passkeys will succeed, but how we design policies that balance usability with security. Device‑bound solutions may remain the gold standard for privileged accounts, while synced passkeys can finally make strong authentication practical, especially in environments where mobile devices aren’t an option.

In the end, Entra’s evolution shows us again that identity is never static but a constant trade‑off between protection and accessibility. The question isn’t if passkeys will reshape authentication, but how responsibly we’ll adopt them (Like avoiding bargain‑bin FIDO2 keys from Donnie Do‑Bad’s corner shop).

But wait, there’s more – in part 2. See you there! 😉