Passkey onboarding in Entra: What Microsoft doesn’t tell you!

Passkeys are no longer something you can postpone or treat as a future project. Microsoft has already put it on the public roadmap that passkeys will be automatically enabled for all tenants in March 2026. When that happens, every tenant will have passwordless authentication in play, whether it is ready or not. In my experience, most organization are not ready for this despite what they may think.

The really tricky part

One thing Microsoft documentation mostly ignores is that every tenant starts from a different place. Some are clean and modern. Others have years of policy drift, inherited settings, and half‑finished security projects. I see tenants where “MFA is enforced everywhere”, but that usually means Microsoft Authenticator or SMS. That does not mean the tenant is ready for passkeys or phishing‑resistant authentication. In fact, that assumption is where many problems start.

Legacy MFA methods give a false sense of readiness. They satisfy basic MFA requirements, but they do not satisfy the conditions needed for passkey profiles, nor do they solve the “bootstrap problem” that every tenant faces when transitioning to phishing‑resistant authentication.

Legacy MFA ≠ Passkey Readiness

Weak MFA allows attackers to register their own passkeys during transition!

Setting up a passkey itself is actually very easy. The problems start when you look at how users are allowed to register their first one. Conditional Access, authentication method policies, and existing MFA methods decide who is allowed to onboard and under what conditions. If you don’t think this through, you end up opening a new authentication method to anyone who meets your current MFA requirements. And in many tenants, those requirements still include SMS or other weak method which still remains vulnerable to compromise.

This is why I recommend an onboarding procedure for Passkey/FIDO2 only through Temporary Access Pass (TAP), for both existing and new accounts.

Without a controlled onboarding path using Temporary Access Pass, a compromised account can register a passkey just as easily as a legitimate user. That is really, really bad! TAP isn’t there because passkeys are hard, it’s there to make sure the right person is the one registering the passkey and to block attackers from slipping in during the transition. It also means you need a secure way to issue the TAP and communicate it to the user, without anyone else getting access to it. There are several ways to handle that, depending on the size and complexity of your organization.

Important: I recommend TAP to prevent account takeover during passkey onboarding, not because passkeys are hard to set up (they’re not).

but that’s only half the job…

Enabling passkeys is an important milestone, but it does not magically make a tenant phishing‑resistant. As long as older authentication methods are still allowed (SMS, authenticator app, etc) attackers will continue to target those instead. They are easier to phish/intercept, easier to socially engineer, and much easier to abuse once an account is partially compromised.

Microsoft’s direction is clear: Passkeys and FIDO2 are the future of authentication. Legacy MFA is mostly a compatibility layer now, and it should be treated that way. Once users have onboarded with passkeys, the real work begins, tightening Conditional Access, limiting fallback methods, and phasing out weaker MFA options.

If you skip that cleanup, you’re not reducing your attack surface at all. You’re just adding a new sign‑in method on top of the old ones.

Synced or Device bound?

I am not going to spend much time on this, because I think I covered it in depth in my two blog posts:

• Huge Entra Passkeys changes – Part 1 – Agder in the cloud
• Huge Entra Passkeys changes – Part 2 – Agder in the cloud

But the very short version is that device-bound is a little more secure but perhaps less user friendly for some. Synced passkeys are stored at the provider (for example Google) so if you get a new android phone you don’t have to set up passkeys again, the old ones from your previous android-phone is available on the new phone as well.

The technical stuff – let’s get started with passkey enrollment!!

This example will set up a simple, but effective, onboarding of FIDO2 using Temporary Access Pass and bootstrap (which is what it is for).

First, the scenario:

“We want users to sign in with a TAP and then immediately register a passkey on their account. Passkey/FIDO2 will be required to access other resources in the tenant. This applies to all new and existing users.“

1. First we need Authentication Strength

To require Passkey/FIDO2 in Conditional Access we have to use Authentication strength. There is a built-in one named “Phishing-resistant MFA”, which allows for the use of Windows Hello/Platform credential, certificated-based authentication and Passkey/FIDO2. Notice that is does NOT accept TAP so this will not support onboarding users with TAP.

So under Conditional Access | Authentication strengths we will select “New authentication strength“

Here we give it a name and description.

‼️Notice that select TAP (one-time use) and Passkeys and WHfB. Why? I’ll come back to that soon. Then select “Next” and “Create“.

🚨 Another very important detail: If you only allow TAP (One-time use) in your new authentication strength (like on the picture above), then navigate to “Authentication methods” and make sure Temporary Access Pass settings are set to only allow One-Time use like on the picture below. If this setting says “No”, then you Authentication strength will reject your TAP! I spent quite some time troubleshooting that one, so you don’t have to. 😉

2. Then we set up Conditional Access

With the required Authentications strength in place, we can start setting up Conditional Access. For this scenario we need 2 Conditional Access policies (or do we? keep reading…. 😉)

Beware, as I mentioned in the start of the post: Every tenant starts from a different place, so this example setup does NOT take existing Conditional Access policies into account. That part you’ll have to do yourself.

Conditional Access policy #1 – Require Phishing-resistant MFA

Simple and straightforward, as shown below. In this example, the policy is scoped to a security group for testing or pilot use, which I recommend, because it also makes it easy to exclude test accounts from other policies in the tenant. The policy then targets All resources (meaning everything in the tenant) and, finally, requires the Phishing-resistant MFA authentication strength. 

Conditional Access policy #2 – Require Phishing-resistant MFA

This policy is scoped to the same security group, but it targets the Register security information user action. That means it applies when a user tries to add a new authentication method (for example through aka.ms/mysecurityinfo). It then requires the authentication strength you created earlier, Onboard Passkey/FIDO2, which allows TAP to be used during this process.

3. Test (and maybe watch it fail)

First and foremost: Wait at least 10 minutes after you made any changes before you test!

Now, in theory this is all we have to do before signing in to aka.ms/mysecurityinfo with a TAP and register a Passkey. Unfortunately this has not worked for me at all. 😱

I’ve tested on no less than 4 tenants and the result was the same every time: I need to allow TAP for some 1st party enterprise apps in addition to those 2 policies I just showed you above. The frustrating part here is that I see online that other people have made this work with only those 2 Conditional Access policies, but it just won’t work when I try it.

Why does it behave different? I honestly have no idea. I have tried to disable both SSPR, Registration campaign and the MFA registration policy under Identity Protection in all 4 tenants I tested on.

4. If it still fails: Allow TAP for a few more apps

🥳 After much troubleshooting I finally found a way to make it work. The fix is to allow these apps to use TAP, using a third CA policy, and exclude the same apps in the first CA policy.

So first I add the 6 apps as exceptions from the first policy (the one which requires “Phishing-resistant MFA”).

Then I create a new policy which targets the same security group and the same 6 apps and requires “Onboard Passkey/FIDO2” for those.

5. Wait another 10+ minutes and test again

In every tenant I tested this on, I had to make all 3 CA policies with the 6 apps excluded from phishing-resistant MFA before I could sign in with a TAP to register my first passkey. This is why I added FIDO2 and WHfB to the “Onboard Passkey/FIDO2” authentication strength earlier.

The apps I had to register

These are the 6 apps (and their Appid) which I had to allow the user to reach with a TAP to make this work.

In all the tenants I tested, “My Signins” was not in the list of apps in the Conditional Access policies. If that’s the case, you need only to add a Serviceprincipal to the Appid, and then you’re good to go.

This is a simple matter of connecting with PowerShell with the “Application.ReadWrite.All” scope and run New-MgServicePrincipal. Simple script to fix this is below. Just replace the Appid in the end if you need to do the same for another app.

Connect-MgGraph -Scopes "Application.ReadWrite.All"
New-MgServicePrincipal -AppId "19db86c3-b2b9-44cc-b339-36da233a3be2"

Conclusion

Passkeys are not the hard part, but onboarding them safely is.

Microsoft enabling passkeys by default does not make a tenant phishing‑resistant, and it does not mean the tenant is ready. If you allow passkey registration under weak MFA conditions, you are not improving security. You are potentially giving attackers a stronger foothold than before. In my own opinion: Temporary Access Pass is not optional in this transition. It is the control that decides whether the right person registers the first passkey. Remember Zero Trust: “Assume breach”.

Also, do not assume Conditional Access behaves consistently across tenants, or exactly as documentation suggests. In my testing, as explained thoroughly now, it clearly does not. First‑party Microsoft apps, authentication strengths, and TAP introduce edge cases that you must test in your own environment!

Treat passkeys as a migration, not a feature toggle. The real security improvement only comes when legacy MFA methods are deliberately restricted and eventually removed. Until then, passkeys are just another sign‑in method. Not a solution.

Thank you everyone who managed to read this post all the way to the end. Surely none of you just scrolled all the way down, right? 😁