Passkeys on the laptop are easy. The phone? Not so much!

Back in February I wrote about how to onboard passkeys safely with Temporary Access Pass, and in Passkeys enabled ≠ phishing-resistant I wrote about tightening Conditional Access afterwards. But I didn’t cover the phone in either of those posts, and that turned out to be a whole story on its own. 😉

First, the scenario:

A user signs in with a TAP and registers a passkey in Windows Hello on the laptop. Conditional Access requires phishing-resistant MFA for all resources in the tenant. The user signs in on the laptop without any issues. Then the same user opens Outlook on the phone, and is asked to sign in.

And that’s where it stops. The user has one phishing-resistant credential, it’s stored on the laptop, and Conditional Access won’t accept anything less. So what does the user do? Calls the helpdesk, of course.

🚨 This is where things can go really wrong. The quickest fixes available to the helpdesk are to exclude the user (or mobile devices) from the policy, or to allow Authenticator push notifications on the phone “for now”. Both of these work, and both of them undo the entire point of rolling out passkeys in the first place.

So why doesn’t the passkey work on the phone?

Short version: Because it’s not supposed to.

A passkey in Windows Hello is device-bound. It doesn’t matter if it’s a Windows Hello for Business credential on a joined device, or the newer Microsoft Entra passkey on Windows on an unmanaged one. Microsoft states quite clearly that the passkey on Windows isn’t synced, and that each device needs its own registration for each account. And that’s the whole point of a device-bound passkey: The private key is created on one device and never leaves it.

So it’s a great security feature. It’s also the reason the phone has no idea the passkey exists.

And there’s another side to this: When the device is gone, so is the passkey. A stolen laptop or a reinstalled computer means the passkey is gone for good, and there’s nothing to restore. The only way back is a new TAP from the helpdesk, using the same controlled process as in the February post. So your onboarding process is also your recovery process, and it needs to be equally secure.

In their deployment guide for phishing-resistant passwordless authentication, Microsoft splits these credentials into two types, and I find that really helpful for understanding the problem:

• Local credentials only work on the device they’re stored on. Windows Hello for Business, the Entra passkey on Windows and Platform SSO on macOS are all local credentials. Great user experience, but they can’t go anywhere.
• Portable credentials can be used across devices, and they can also be used to register credentials on other devices. Passkeys in Microsoft Authenticator, synced passkeys, FIDO2 security keys and smart cards are all portable. Microsoft actually calls these the most important type of credential for most users.

Portlable passkeys and synced passkeys are not the same.

So the user in our scenario has a local credential, but no portable one. That’s really the whole problem in one sentence.

What about authentication transfer?

“Hold on”, I hear you say. “Doesn’t Microsoft already have a feature for this?” Well, sort of. 😉

With authentication transfer, the user scans a QR code from Outlook on the computer with Outlook on the phone, and the sign-in moves over, MFA included. But:

• It’s still in preview, and support varies by Microsoft app and version.
• Only the authentication is transferred. Device claims like compliance aren’t.
• The phone still has no credential of its own. When the session expires, it’s back to the computer for a new QR code.
• 🚨 Microsoft’s own Zero Trust guidance recommends blocking it, since an attacker with access to one device could use it to reach your resources from another.

So in my opinion it’s a convenience feature, not a fix. And if you already block it (as you probably should), it’s not an option at all.

Microsoft sure knows how to make this easy for us…. 🤪

Beware of the broker!

Before we look at the options, there’s one thing which affects all of them: The authentication broker.

According to Microsoft’s passkey authentication matrix, Microsoft apps on iOS and Android use an authentication broker for passkey sign-in. With a broker installed, Outlook sends the user to the passkey sign-in and back to Outlook afterwards. Nice and simple.

The good news is that you don’t have to configure anything in Entra for this. Microsoft’s apps automatically use the broker if it’s installed on the phone. But which apps count as a broker depends on the platform:

• iOS: Only Microsoft Authenticator. Company Portal on iOS doesn’t count!
• Android: Authenticator, Company Portal or the Link to Windows app. If more than one is installed, the first one installed is normally the one that gets used.

There are also different minimum versions depending on the credential. On Android, a FIDO2 security key in native apps requires Android 13 or later, while a passkey in Authenticator requires Android 14 or later. On iOS, native apps require iOS 16 without the Microsoft Enterprise SSO plug-in, and iOS 17.1 with it.

Whichever option you choose below, make a broker part of your standard mobile setup. In most tenants that means Authenticator should be on the phone anyway.

Without a broker it’s a different story. The same matrix shows that Word, Excel and PowerPoint support passkeys without a broker on both iOS and Android, but Outlook, Teams and OneDrive on Android do not. So if you get a ticket saying “the passkey works in Word but not in Outlook”, now you know why. 😉

Enough background, let’s fix this! 💪 I’ve come up with five options, some good, some less good, and one I’ll beg you not to use. Let’s go through them one by one

Option 1: A passkey in Microsoft Authenticator

This is the option Microsoft recommends, and it’s also my default choice for an end-user. The user keeps Windows Hello on the laptop and registers a second passkey, this time in Authenticator on the phone. Authenticator then handles passkey sign-in to Microsoft apps like Outlook, OneDrive and SharePoint, on both iOS and Android.

If you’ve read older guidance saying same-device sign-in doesn’t work on Android yet, that has changed. The current version of Sign in with passkeys in Authenticator documents it for native apps on Android, and only lists the Edge browser on Android as “coming soon”.

What the user needs to do

The user needs iOS 17 or Android 14 (or newer). Microsoft recommends registering directly in the Authenticator app, because that’s what gives single sign-on to the other Microsoft apps. On iOS the steps are:

1. Install Microsoft Authenticator from the App Store.
2. Tap “Add work or school account“. If the account is already in Authenticator, tap the account and select “Create a passkey” instead.
3. Sign in and complete MFA. This is where the TAP comes in.
4. Set up a screen lock if the phone asks for one.
5. Tap “Settings” to enable Authenticator as a passkey provider. On iOS 18 this is under Settings > General > AutoFill & Passwords, and on iOS 17 under Settings > Passwords > Password Options. Make sure “AutoFill Passwords and Passkeys” is turned on, and that Authenticator is selected under “AutoFill From“.
6. Go back to Authenticator and tap “Done“.

On Android the steps are mostly the same, but in step 5 the user selects Authenticator under Passwords & accounts > Additional providers. Microsoft points out that this can vary with the make and model of the phone, and if Android 14 won’t let you select Authenticator as a provider, their recommendation is to upgrade to Android 15. I’m sure your helpdesk will love that one. 😅

The full walkthrough for both platforms is in Register passkeys in Authenticator on Android and iOS devices.

What you need to do as an admin

First you need a passkey profile which allows Authenticator:

1. Sign in to the Entra admin center as at least an Authentication Policy Administrator.
2. Navigate to “Entra ID” > “Authentication methods“.
3. Select “Passkey (FIDO2)” > “Configure” and then “+ Add profile“.
4. Give it a name, for example “Authenticator passkeys”.
5. Choose whether to enforce attestation or not (more on that below).
6. Under “Passkey types“, select “Device-bound“.
7. Select “Target specific AAGUIDs“, set “Behavior” to “Allow“, then “+ Add AAGUID” > “Microsoft Authenticator” and “Save“.

Then assign the profile to your users:

1. Under “Passkey (FIDO2)“, open “Enable and target” and make sure “Enable” is set to “On“.
2. Select “Add target“, choose your group, select the new profile and click “Save“.

‼️ Notice that I use a separate profile for Authenticator. Why? Because a profile for passkeys in Windows Hello can’t enforce attestation, according to Enable Microsoft Entra passkey on Windows. So if you add both Windows Hello and Authenticator to the same profile (which Microsoft even shows as an example), you lose attestation for Authenticator as well. A user targeted by several profiles is allowed to use a passkey as long as it satisfies at least one of them, so two profiles on the same group should let you keep attestation for Authenticator.

🚨 Beware of overlapping passkey profiles! A passkey only has to satisfy one of the profiles a user is targeted by, so the most permissive profile always wins. If any profile targeting a user allows unattested passkeys, a stricter attestation profile targeting the same user does absolutely nothing. The Default profile is the usual culprit here, since it targets All users unless you scope it down. (I was reminded of this behavior myself while testing for this blog post 🤣) So before you build a stricter profile on top, make sure the users are not targeted by another passkey profile with more relaxed settings.

Now for the tricky part: Conditional Access. If you followed my February post, your users onboard with a TAP, and phishing-resistant MFA is required for all resources. That’s still exactly what I recommend, but the phone adds a little twist.

There are two ways to get a passkey into Authenticator:

• Through Security info in the browser (aka.ms/mysecurityinfo). This is covered by the policy targeting “Register security information” with the “Onboard Passkey/FIDO2” authentication strength from the February post, so the TAP works fine here.
• By signing in to the Authenticator app and creating the passkey there. This is the one Microsoft recommends, because it also gives the user single sign-on to the other Microsoft apps. But signing in to Authenticator isn’t the registration user action, it’s a regular sign-in. And as Microsoft points out in Enable passkeys in Authenticator, a policy requiring phishing-resistant MFA for All resources also covers Authenticator. So the user needs a passkey to sign in to Authenticator, in order to create the passkey in Authenticator. Yes, you read that correctly. 🥵

In the February post I had to exclude six Microsoft apps from the phishing-resistant policy and allow TAP for them instead. Whether that also covers the Authenticator sign-in is something you need to test in your own tenant.

💡 But here’s the good news for our scenario: The user already has a passkey on the laptop! So there’s no need for a new TAP. The user can sign in to Security info on the laptop with Windows Hello, add a passkey in Authenticator, and scan the QR code with the phone. The catch? Cross-device registration doesn’t work if you enforce attestation for Authenticator. So you’ll have to choose: Attestation and in-app registration with a TAP, or no attestation and an easy cross-device registration from the laptop.

Beware of two more things that will block the registration:

• A CA policy with “Require approved client app” or “Require app protection policy” for All resources, because Authenticator doesn’t support app protection policies.
• Android phones with both a Work profile and a Personal profile. The passkey only works from the profile it’s stored in, so the user may need one passkey in each.

Pros and cons

Pros:

• Phishing-resistant and device-bound, and you can enforce attestation. Authenticator uses Apple’s App Attest service and Google’s Play Integrity API to prove it’s the genuine app.
• This is Microsoft’s preferred portable credential.
• Passkey sign-in to Outlook and the other Microsoft apps on the phone, which is exactly the problem we’re trying to solve.
• It also works as a backup for the laptop. If Windows Hello breaks, the user can scan a QR code with the phone and sign in anyway.
• The user can use it to set up the next laptop, without needing a new TAP.

Cons:

• Requires iOS 17 or Android 14, so older phones are out.
• Enabling Authenticator as a passkey provider on Android depends on the phone manufacturer.
• Lost phone, lost passkey. Back to the helpdesk for a new TAP.
• The CA loop and the app protection issues need some planning before you roll this out.
• Attestation depends on Apple and Google. Attested passkeys also can’t be registered cross-device.
• It requires Authenticator on the phone. If it’s the user’s personal phone, they might refuse (more on that in option 3).

Option 2: Synced passkeys

I covered synced vs device-bound passkeys in Part 1 and Part 2 of my passkey changes posts, so I won’t repeat all of it here. The short version is that a synced passkey is stored at a provider like iCloud Keychain or Google Password Manager or other 3rd party provider, and it’s available on every device signed in to that account. Both synced and device-bound passkeys are now generally available in Entra ID.

For the user, this is probably the most convenient option of them all. Register once, and the passkey is on the phone, on the tablet, and on the next phone as well. But convenience always comes at a price, and here the price is control.

So what exactly does that mean? 🤔 Well, a synced passkey isn’t bound to one device anymore. It’s stored in the user’s Apple or Google account (or other 3rd party), and synced to every device signed in to that account. That changes a few things you need to be aware of:

• The passkey is only as secure as the account it’s synced to. Very often that’s the user’s personal Apple or Google account. Its password, its MFA and its recovery process are now part of your attack surface, and you have zero control over any of them.
• You don’t know where the passkey is. 🚨Synced passkeys follows the account, not the device!🚨 On Apple that means every iPhone, iPad and Mac on the same Apple Account. On Android it goes even further: Google Password Manager syncs passkeys to Chrome on Windows, macOS and Linux as well, for any Chrome profile signed in to the same Google account. To unlock them on a new device, the user only needs their Google Password Manager PIN or the screen lock of their Android phone. So yes, the work passkey can end up in Chrome on the family PC at home.❗
• The user picks the provider, not you. The passkey can also be stored in a third-party password manager, like Samsung Pass, 1Password or Bitwarden, each with its own sync, security, and recovery features.
• The passkey can be shared. On Apple devices, users can share passkeys with AirDrop or through shared password groups with family and trusted contacts. Google Password Manager has family sharing too, but I haven’t found anything confirming it works for passkeys.

One thing I really dislike: Many password managers let users keep the browser extension unlocked, which leaves any passkey stored there available without further authentication. The GIF below shows this with my passkey for SAS. I simply click the NordPass pop-up where the passkey is stored, and I’m signed in. No PIN, no biometrics, no master password, because I can configure the extention to remain unlocked.

Synced passkey + 3rd party vault + browser extention = 😱

This isn’t meant to single out SAS or NordPass. It just happens to be where my passkey was stored. The point is that the extension’s lock behavior is a setting the end user controls, and many password managers offer the same option.

• Why the sign-in succeeds: The passkey provider performs user verification itself. An unlocked vault can report user verification as satisfied, and the website has no way to tell the difference.
• Relevance for Entra ID: The same thing applies if synced passkeys in password managers are allowed in your tenant. For privileged accounts, require device-bound, attested passkeys with AAGUID restrictions, which keeps password-manager passkeys out.

The good news? The passkey is useless without its registration in Entra ID. If a user leaves, or you suspect something is wrong, delete the passkey from the user’s authentication methods or disable the account, and it stops working no matter how many devices it has synced to.

What the user needs to do

These steps are from Register a synced passkey (FIDO2):

1. Make sure the phone has a passkey provider configured. On Android this is under Settings > Security and privacy > More security settings > Passwords, passkeys, and autofill. For iOS, Microsoft says to open Settings > General > AutoFill & Passwords and set “Set Up Codes In” to “Passwords“.
2. Open a browser on the phone, sign in to aka.ms/mysecurityinfo and complete MFA.
3. Tap “+ Add sign-in method” > “Passkey” > “Next“, then “Next” again on iOS or “Continue” on Android.
4. Give the passkey a name, tap “Next” and then “Done“.

What you need to do as an admin

⚠️ First, check this one: According to How to enable passkeys (FIDO2) in Microsoft Entra ID, if you haven’t opted in to passkey profiles yet and attestation isn’t enforced, synced passkeys are already enabled in your tenant. So you may have made this decision already, without knowing it.

To enable synced passkeys on purpose, and only for the groups you want:

1. Sign in to the Entra admin center as at least an Authentication Policy Administrator.
2. Navigate to “Entra ID” > “Authentication methods” > “Passkey (FIDO2)” > “Configure” under Authentication methods.
3. Add a new profile, or edit an existing one, and select “Synced” under “Passkey type“. Save.
4. Target the profile to the groups which should be allowed to use synced passkeys.

Beware: If you disable synced passkeys in a profile later, users who have already registered one can’t sign in with it anymore. So think this through before you enable it.

Pros and cons

Pros:

• The best user experience of all the options, and it survives replacing the phone.
• Built into the operating system, so no extra app is needed to register it.
• Still phishing-resistant.
• Can be scoped to specific groups with passkey profiles.

Cons:

• No attestation. Microsoft says to treat synced passkeys as phishing-resistant, but with the same security posture as other unattested authenticators.
• Without attestation, Microsoft states that Entra ID can’t guarantee anything about the passkey, not even whether it’s synced or device-bound. Your AAGUID restrictions become more of a guideline than a security control.
• 🚨 Security depends on the user’s Apple or Google account (see above).

🤔 So would I use it? For admins and other high-value accounts: No! For the broad user population it can absolutely be a valid choice, and I’ll get back to that in my recommended setup.

Option 3: A FIDO2 security key on the phone

Some users simply won’t install a work app on their own private phone. The folks over at MSEndpointMgr call this “the personal phone problem“, and it’s very real. For these users, a FIDO2 security key can be the portable credential instead.

For the user it looks like this: The key is registered on the computer through aka.ms/mysecurityinfo, not on the phone. That’s because Microsoft’s authentication matrix notes that registering a new security key doesn’t work in iOS browsers, since they don’t prompt the user to set up a PIN or biometrics. After that, the user taps the key (NFC) or plugs it in (USB-C or Lightning) when Outlook asks for a sign-in. On Android, a broker is still needed for Outlook, Teams and OneDrive.

On the admin side there’s not much new to configure, as long as your passkey profiles allow the key models you hand out. The real work is in choosing which keys to buy:

• Bluetooth (BLE) security keys aren’t supported on iOS or Android.
• NFC with FIPS 140-3 certified security keys isn’t supported on iOS. So if you bought FIPS keys for compliance reasons, your iPhone users will have to plug them in instead. [LAB TEST: FIPS key over USB-C on an iPhone 15 or newer.]
• Yubico keys with YubiOTP enabled might not work on older Android devices. Disabling YubiOTP is the documented workaround.

Pros:

• Phishing-resistant, device-bound and supports attestation.
• Doesn’t depend on the phone at all. Phone battery dead? The key still works.
• Solves the personal phone problem on iOS, where Outlook, Teams and OneDrive support passkeys without a broker.
• Works on the computer as well, so it doubles as a backup.

Cons:

• Keys cost money, and they get lost.
• The user has to carry the key around, and tap or plug it in every time the phone needs a new sign-in.
• The FIPS and NFC limitation on iOS.
• Can’t be registered from a browser on an iPhone.
• On Android a broker is still needed for Outlook, Teams and OneDrive, so the personal phone problem is only half solved there.

Option 4: Lower the requirement on mobile and require a compliant device instead

Some tenants solve the mobile problem by splitting Conditional Access into one policy for desktop and one for mobile. Microsoft even suggests this as a workaround in Enable passkeys in Authenticator. Some take it one step further: Keep phishing-resistant MFA on the computer, and on mobile require regular MFA plus a compliant device instead.

🚨 Be very careful with this one! The device platform condition in Conditional Access is based on the user agent string, and in Conditional Access: Conditions Microsoft states that since user agent strings can be modified, this information isn’t verified. They recommend using the condition together with device compliance, or in a block policy.

What does that mean in practice? If your mobile policy is weaker than your desktop policy, an attacker with an AiTM phishing kit can change the user agent to iOS and end up in the weaker policy. So the only safe way to lower the authentication requirement on mobile is to raise the device requirement at the same time.

What you need to do as an admin

Policy A: Desktop (and everything else)

1. Users: Your passkey group. Exclude your break-glass accounts.
2. Target resources: “All resources“.
3. Conditions > Device platforms: Include “Any device“, exclude “Android” and “iOS“.
4. Grant: “Require authentication strength” > “Phishing-resistant MFA“.

Policy B: Mobile

1. Users: Same group, same exclusions.
2. Target resources: “All resources“.
3. Conditions > Device platforms: Include “Android” and “iOS“.
4. Grant: “Require multifactor authentication” and “Require device to be marked as compliant“, with “Require all the selected controls“.

Now anyone faking a mobile user agent also needs an Intune compliant device, which an attacker’s proxy can’t provide. And unknown platforms end up in policy A. As always: Start in “Report-only“!

What the user needs to do

Enroll the phone in Intune, and keep using Authenticator push notifications with number matching. From the user’s point of view nothing really changes, which is exactly why this option is so tempting.

Pros and cons

Pros:

• Very little friction, since users keep the MFA methods they already have.
• Requiring a compliant device is widely considered an effective protection against AiTM in the community, because the token is never issued to a device which can’t prove it’s compliant. Jeffrey Appel has a good overview of AiTM mitigations if you want to dig deeper.
• Works on phones which are too old for passkeys in Authenticator.

Cons:

• The sign-in method itself is still phishable. You’ve moved the security boundary from the credential to the device, and it’s only as good as your Intune compliance configuration. There’s also published research on getting tokens which satisfy compliance-based CA without a compliant device, so don’t treat this as a brick wall.
• Requires Intune enrollment of the phones. If they’re personal phones, that’s more of a political discussion than a technical one.
• It’s not phishing-resistant MFA. If you report that “all users are phishing-resistant”, this option makes that statement false for mobile.
• Two policies to maintain, and one mistake in the device platform conditions opens up exactly what you tried to close.

In my opinion, this is a transition tool for tenants with managed phones. Not a permanent solution.

Option 5: Exclude mobile from the policy (please don’t!)

After closing the door for phishing attacks, you simply open the door again, and I’m including this one because I know it happens. The helpdesk excludes the user, the group or the mobile platforms from the phishing-resistant policy. “Temporarily”, of course. 🙄

Pros:

• Works instantly, and no more tickets.

Cons:

• EVERYTHING else! Temporary exceptions have a tendency to become permanent, because nobody owns removing them. The excluded path accepts exactly the methods AiTM kits are built to phish. And if this is how mobile was solved, the passkey rollout didn’t really protect much.

If you absolutely have to: Put a time limit on it, document it, and put the responsibility (and a calendar reminder) on someone to remove it.

Comparing the options

So, should users have one passkey or two?

As you can tell, the options focuses around an additional passkey, so should the user have a passkey on the phone instead of on the computer? Or one for the computer only, and one for the phone only?

Short answer: Both!

Longer (and serious) answer: I would recommend one local and one portable. The Windows Hello passkey is computer-only by design, and that’s perfectly fine. It’s the fastest and smoothest sign-in the user will ever have on that computer. A phone-based passkey, say in Microsoft Authenticator, doesn’t support signing in to or unlocking the Windows client itself. The portable one signs the user in on the phone, works as a backup for the computer if Windows Hello breaks, and can be used to set up the next computer without a new TAP.

Which portable credential you choose depends on the user. The important thing is that it’s a choice you make deliberately. People are different, their needs are different, and every organization runs in its own environment with its own risks and requirements. There’s no “one size fits all” when it comes to passkeys, and I’d be very skeptical of anyone who claims there is. 😉

So this is what I would use as a starting point (your mileage may vary):

Test, test and test again!

As I wrote in the February post: Every tenant starts from a different place, and Conditional Access doesn’t always behave the way the documentation says it will. So before you roll anything out, test at least this:

• A proper onboarding procesure from beginning to end (Both new emplyees an existing users)
• Outlook, Teams and OneDrive on both iOS and Android, with and without a broker installed.
• Passkey registration in Authenticator, with your actual CA policies in place. Watch out for the loop: The policy can demand phishing-resistant MFA to reach registration, before the user has a passkey to satisfy it with.
• Android phones with a Work profile.
• Registering attested passkeys on a busy Monday morning, when everyone does it at the same time.
• Your FIPS keys on an iPhone, over USB-C.
• If you go for option 4: A sign-in from an unmanaged device with a faked mobile user agent. It should fail!

That’s it for this time

Passkeys on the computer are the easy part. The moment users pick up their phone, you find out whether your rollout gave them a portable credential or not. So give every user a portable credential, keep the local one on the computer, and have a plan ready for when the phone gets lost. And when the helpdesk asks if they can exclude mobile “for now”, point them this post. 😉

Thank you all, and I truly hope this is helpful for you!