Passkey as first MFA method: What could go wrong?

If you have onboarded anyone to passkeys in Entra, you know the awkward part. Before a user can register a passkey, they need an MFA method already. So either you hand them a Temporary Access Pass, or you let them register SMS first and promise yourself you will clean it up later.

We both know how often that cleanup happens. 🙄

Microsoft is finally fixing this. Two Message Center notices landed on August 7, and together they remove a good chunk of the friction in passwordless onboarding.

What is actually changing

Source: MC1450133

The short version: A user with nothing but a password will be able to register a passkey directly. No detour through SMS or Authenticator first.

Microsoft’s own article Register a passkey (FIDO2) explains the behaviour. You need to sign in with MFA before adding a passkey. If you do not have at least one MFA method registered, you have to add one MFA method before registering your passkey. The documented way around it is a Temporary Access Pass issued by an admin, which is also what I recommended back in February and I still recommend (more on that later).

The rollout comes in two phases:

Notice anything odd about that Phase 2 start date? 🤨 The notice was published in August 2026 and says the rollout begins in early January 2026. It almost certainly means 2027. 😉

One more detail worth catching. Authenticator App passkey is in Phase 2, not Phase 1, and it was not even in the original version of the notice. So if your plan is “everyone registers a passkey in Microsoft Authenticator”, you are waiting for the later window, not the October one.

The second change which needs attention too

Source: MC1450134

This one gets perhaps less attention but I think it deserves more. Windows Hello for Business (WHfB) and macOS Platform SSO (PSSO) become standalone MFA factors. GA runs from early October to late November 2026.

Right now WHfB can satisfy MFA at primary sign-in, but a user may still get pushed to register something else to get through step-up prompts and Authentication strength checks. After this change they satisfy those on their own. A user whose only method is WHfB or macOS Platform SSO now counts as MFA capable.

Which is correct. Telling someone who just signed in with Windows Hello that they need to go and set up “a real MFA method” was always a bit silly. 🤡

A very nice addition: WHfB and macOS PSSO credentials will show up in My Security Info as auto-registered passkeys. So if a user who has never registered a passkey opens their security info page, they will find a passkey already registered. They may not realize this is their WHfB or PSSO method and be confused, perhaps even contact IT and ask if they’ve been hacked. So at the very least make sure your IT support team is aware of this small change.

But there is another catch: These credentials are device bound. Lost laptop, laptop in for repair, user borrowing a colleague’s machine, and the credential simply is not there. Combine that with the other half of the change, where a user signing in with only a password will no longer be automatically prompted to register an additional MFA method if WHfB or macOS PSSO is all they have, and you can end up with users who are perfectly secure right up until the moment they are locked out. So this could potentially be an awkward situation.

So if I am right about this, I suggest you make sure people have something portable as well. Microsoft recommends a synced passkey or a passkey in Microsoft Authenticator. I agree for regular users, but as I’ve said a million times already: For your admins I would use a FIDO2 security key you physically control instead of a synced passkey sitting in someone’s Google or Apple account.

What to do before October

Luckily none of this is heavy work. It is mostly checking things you already have (and should know).

1. Check if you have a Conditional Access policy on registration

This is the important one. MC1450133 says “no action required”, and then in the same notice recommends you review your Conditional Access policies for security information registration. So let’s assume a review is needed. 😉

Here is why it matters. After Phase 1, if nothing is gating registration, then a password alone is enough to put a passkey on an account that has no MFA registered. So go and look:

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Policies.
3. Look for a policy where Target resources is set to User actions > Register security information.

Found nothing? Roll up your sleeves and start working! I walked through building this policy properly in my February post on passkey onboarding, including the custom Authentication strength that accepts TAP, so I will not repeat all of it here.

One thing has changed since I wrote that, though. According to Protect security info registration with Conditional Access policy, this same user action has applied to Windows Hello for Business and macOS Platform SSO registration since July 6, 2026. So if you built your registration policy before the summer, it now covers more than it did when you wrote it. Worth re-reading with that in mind.

2. Check your Authentication strengths

MC1450134 recommends this and it takes two minutes. If you have custom Authentication strengths in production, open each one and confirm Windows Hello for Business and platform credential are selected wherever you want them to count.

1. In the Entra admin center, go to Protection > Authentication methods > Authentication strengths.
2. Open each custom strength and review the selected methods.

From October your users will legitimately be presenting those credentials at step-up, and a strength that excludes them will start blocking people for doing exactly what you asked them to do.

While you are in there, one behaviour from the Authentication strengths article that will generate helpdesk calls: If a user signs in with a password first and the strength requires Windows Hello for Business, they are not prompted to switch. They have to start over and pick a qualifying method under “Sign-in options”. Tell your service desk before they get the calls, not after.

3. Rewrite your onboarding routine and documentation

Yes, I am sure you all enjoy writing and updating routines and documentation as much as I do. 😉 However this change is in the very beginning of passkey onboarding, so if they are following a guide or routine to get passkeys up and running then that guide needs to be updated. Remember: Suddenly the pre-requisite of an existing MFA method is obsolete.

🗓️ The deadline for that work is October, not February.

About those users who never registered anything

🤔 Now for the part I keep thinking about. 🤔

Every tenant has them. Accounts that are enabled, licensed, have a password, and have never registered a single authentication method. The user on parental leave or the summer temp from last season. Perhaps it’s those three test accounts someone created in 2022. The contractor who is “coming back in the spring” etc etc. In addition we also have the ones we create on purpose: Users synced from on-premises weeks before their first day, or staged in a target tenant during a migration project so mailbox and OneDrive data has somewhere to migrate to in the target tenant.

By the way: None of this is anything new at all. It has been there for years, and I see it again and again with my customers. 😖

Let’s do a thought experiment: Think about an account with a Conditional Access policy requiring MFA and no MFA methods registered. What happens when someone signs in with just the password? They are not blocked. They get “More information required” and are asked to set a method up. Microsoft’s own MFA tutorial describes it plainly: You are prompted to use MFA, or to configure a method if you have not yet done so.

Read that as an attacker. Username and password gets you to a registration screen, you register your own second factor, and the MFA requirement is now satisfied by something you control.

The MFA requirement never stopped you, but simply asked you to bring your own second factor.

So what changes in October?

Up until now that was bad, but it was recoverable. Say the attacker got SMS or an authenticator app onto the account, and you could take it straight back off again. You may think that we simply click Require re-register MFA. Methods wiped, user starts over, sorted.

Well, in case you rely on that button in Entra (which you should not be relying on it blindly), it does not remove any passkeys registered on the account. Those have to be removed manually! It’s very easy to confirm:

This is the before-state, SMS, Authenticator and passkey is present.

We click “Require re-register multifactor authentication“

The passkey is still there while the other methods were removed.

Not that this should come as some huge shock. If you suspect an account has been compromised, clicking Require re-register MFA and assuming that’s the end of it was never good enough on its own. So this isn’t really a crisis because I choose to think that any responsible admin would actually check the list of MFA methods manually.

But it is one more reason that after Phase 1, a hijacked registration can end with something sitting on the account that satisfies your strongest Authentication strength, survives a password reset, and outlives the one remediation step many people may reach for first. THAT is a scary thought! 😱

So how many accounts without MFA do you really have?

You don’t need to build a report for this, because I already built one for you! 😁

I.D.E.A. #004 – MFA, you say? scores every account by what’s actually registered on it, Critical through Secure, and “Critical” is exactly the population we’re talking about: No MFA registered at all. Point it at your tenant, sort the output, and you’ve got your list without writing a line of PowerShell.

While you’re in there, don’t stop at Critical. The tool separates Good from Secure for a reason: An account with FIDO2 and SMS both registered comes back Good, because the strong method is present, but the SMS is still sitting there as a fallback. That’s not the account you’re worried about today, but it’s exactly the kind of thing that turns into a problem the day someone gets clever with account recovery.

Sort on admin status first, same rule as always. An admin account showing up as Critical is an incident by all intents and purposes.

The rest of it isn’t really a technical job, and I think that’s where most of the value is hiding. Get someone in a room who’s actually allowed to make decisions about these accounts, because I’d guess a decent chunk of them shouldn’t exist any more and deleting those costs you nothing at all.

• The genuinely dormant ones
• People on parental leave
• Seasonal staff
• The contractor who might be back in the spring

I’d block sign-in on those until somebody needs them again. It takes about half a minute to switch an account back on the day the user actually returns and needs to sign in.

Whoever’s left on the list gets onboarded properly.

“Onboarded properly” means a Temporary Access Pass, handed to someone whose identity you’ve actually verified, not just sent to the mailbox you’re trying to protect.

🚨Now, to avoid any confusion about what actually closes off this vulnerability: It’s NOT the TAP on its own. Issuing a TAP doesn’t stop anybody signing in with the password. Microsoft spells it out in The Temporary Access Pass article: Users can continue to sign in by using their password, because a TAP doesn’t replace a user’s password.

What actually does the job is the registration policy from earlier in this post, the one requiring an Authentication strength that only accepts TAP and passkeys. I walked through building that exact policy in my February post on passkey onboarding, so if you set it up back then, this is where it pays for itself. Microsoft’s own documentation on how authentication strengths work confirms that a policy scoped to Register security information takes precedence over an all-resources policy during the registration interrupt. So a password-only user hitting any resource gets redirected to registration, and it’s your TAP-only strength that governs what they’re allowed to do there, not whatever’s protecting general access. In practical terms: Password is no longer enough to register the first MFA method, you must have the TAP code to proceed!

If you build those policies then a user or attacker with the password genuinely can’t register anything without having the TAP code. If you don’t build them, only a password is needed by an attacker to register an MFA method and walk in through the front door, so to speak.

Wrapping up

I think this is a good change all in all. Making people register a weaker method on the way to a stronger one never made much sense, and most of the tenants I look at are still carrying the SMS registrations that requirement created.😣

But be clear about what Microsoft has actually done here: They’ve removed a prerequisite, but nobody has added a control to replace it. So whether registration is protected in your tenant comes down entirely to the CA policies you’ve written, or haven’t. So do you prefer a couple of hours of work this month, or is an incident in November more your liking?

Start with the I.D.E.A.004 report. I’d put money on the number being higher than you expect. 😉

Once again, thank you so much for reading our blog! I hope you find this useful. Take care!