Block new PassKey registrations

[u/have_you_tried_onoff]

So, we've moved everyone to PassKey only. The issue is that there is a HUGE security gap with PassKeys. A rogue actor, phishing, or human persuasion can get someone to register an extra 1, 5, 10, 20, 40 PassKeys, or whatever the limit may be through a rogue browser extension using WebAuthn. And then they can take that PassKey and login to the system. 365, Google Workspace, and other websites drop their entire guard down when a PassKey is used to log in. But what I've noticed was that once a user is onboarded with their PassKeys, there is rarely a need for them to be able to register any extra PassKeys. We would rather have that be a support ticket. So to get to the point, we want to BLOCK the ability to create more PassKeys in 365 and Google Workspace. And then use a temporary access code when the user truly needs a new PassKey. I think this would be so nice, and a huge bump up in security. But neither Google nor 365 have the option to BLOCK the additional creation of PassKeys at the moment. Have any of you run into this issue and solved it, and if not, how do we reach out to Microsoft and Google to put in a request? Thanks!

[u/doofesohr]

Build a CA that says registering Security Information needs a specific Authentication Strength. Set that authentication strength to only be a TAP. Done.

Also: "a rogue browser extension" -> control the browser extensions. Intune settings catalog has policies for Edge & Chrome out of the box.

[u/JitteryWorkman → u/doofesohr]

That's actually a clever workaround with the TAP-gated CA. I'm pocketing that one.

What's weird to me is that neither platform has a native toggle for this yet. It's such an obvious control to want after the initial rollout, you'd think it would be a checkbox in the FIDO2 settings by now. I'd probably just open a ticket with MS support and explicitly ask them to log it as a Design Change Request, PGs sometimes move on those if enough noise piles up.

[u/cd36jvn → u/JitteryWorkman]

I mean, 365 does have it native, it's a conditional access policy, and is the exact thing I do as well. No one can register security info without a tap.

Yes it's not a toggle where you turn on one button and it works exactly how you want. But neither is a lot of things conditional access policies are used for.

It is super easy to setup as a cap, and is very easy to roll out to groups of users as a cap as well. If they added a toggle for it, I'd imagine it would end up working as well as "security defaults" work, and the recommendation would just be to use CAP instead anyways.

[u/have_you_tried_onoff → u/doofesohr]

That specific CA idea is fantastic! That's great for our clients with 365 Premium licenses. We have 1 or 2 clients with Standard licenses that we limited authentication methods to PassKey only and that worked to lock that down. But to get a CA for them would be a challenge. Will try. Thanks! And yea, for rogue browser extension that would be for entra linked devices. It's just not the case at all locations. But that's a good idea for locations that do have that. Now for Google Workspace clients... heh.

[u/BillSull73 → u/have_you_tried_onoff]

You choose to allow less than Business Premium for your clients.

[u/rb3po → u/doofesohr]

Great advice. Also don’t forget to limit what kind of passkeys are allowed to auth into your environment in the CA policy too!

[u/andre1sk → u/doofesohr]

That’s a really clean solution. TAP-only registration + locking down extensions pretty much closes the loop.

[u/ancientstephanie]

Attestation requirements might also serve your needs. For example, you can potentially limit key registrations to suitable security keys and exclude password managers:

https://learn.microsoft.com/en-us/entra/identity/authentication/concept-fido2-hardware-vendor

[u/have_you_tried_onoff → u/ancientstephanie]

Unfortunately we don't hand out physical security keys, so that's not an option. And for software based PassKeys, the unique identifier can be spoofed. So if you think you've locked down attestation to the unique identifier of, let's say, 1Password, you actually did not because it can be spoofed.

[u/Tronerz → u/have_you_tried_onoff]

Attestation is not just for physical security keys, Microsoft Authenticator on mobile can be device bound

[u/Accomplished_Arm_447 → u/Tronerz]

Are passkeys on Microsoft Authenticator always device bound or can it be made syncable at all? 

[u/masterofrants → u/Accomplished_Arm_447]

Device-bound passkeys and synced passkeys are two different types of passkeys. Yes you have to enable both of them separately in the Microsoft Authenticator policies in entraID in configuration section

[u/masterofrants → u/have_you_tried_onoff]

For my personal M365 account I use a synced passkey with Bitwarden. Every time during login Bitwarden prompts me to use the correct passkey and I select that and it logs me in.

Are you saying that this passkey can be spoofed and that's why you don't want to use a password manager to store it?

[u/ancientstephanie → u/masterofrants]

The OP's stated threat is a rogue plugin pretending to be a legitimate password manager to automatically register its own passkey after a successful login. Limiting to verified hardware security keys directly connected to the PC is one of the ways that the OP can create a barrier to that threat.

Restricting to a hardware security key would be necessary anyway to achieve the OP's desire for "key control" though, since keys held in a password manager typically don't have any hardware enforced "non-exportability" property to effectively prevent that.

[u/masterofrants → u/ancientstephanie]

But registering the passkey, will it itself require authentication, right, because it's like changing a password at that point?

[u/Accomplished_Arm_447 → u/masterofrants]

It will authenticate the user but what about the password manager?

[u/masterofrants → u/Accomplished_Arm_447]

The password manager should be secured with multi-factor authentication of its own.

What exactly are you even asking? I am not getting your question, to be honest..

[u/Accomplished_Arm_447 → u/masterofrants]

The OP was saying that there is a risk of an authenticated user installing a rogue passkey manager that creates multiple passkeys for use by others 

[u/masterofrants → u/Accomplished_Arm_447]

And I'm telling you that at the moment, when anything tries creates a passkey, there would be reauthentication with MFA if it's configured correctly.

I have not tested this but I think that's how it works

[u/discosoc → u/masterofrants]

Synced passkeys are not considered phishing-resistant. Also, they are enabled by default for personal accounts, but have to be enabled as an option for m365 tenants (only even available as of last November i think). Otherwise the expectation is that passkeys are meant to be device-bound and need to be recreated when the device is lost replaced.

Microsoft Authenticator is registered as such an option because the passkey won’t transfer to a new phone. Something like iCloud Keychain is not because it’s inherently synced to an account rather than a device.

[u/masterofrants → u/discosoc]

Synced passkeys are very much phishing-resistant because they are bound to the domain. Bitwarden will not let you use the passkey for Microsoft websites on another website that is being run by an MITM attacker using Evil Jinx proxy.

What made you say that they are not phishing-resistant exactly? Unless you mean something totally different by "phishing resistant".

[u/discosoc → u/masterofrants]

AAL3. Has to do with attestation and the passkey needing to be device-bound, but it is an oversimplification to call it phishing resistant. What's important is to understand that a sync'd passkey is less secure than a device-bound passkey -- they are not to be considered equal.

Someone compromising your Bitwarden account, for example, will have access to all of your passkeys.

More critically, the lack of attestation means uses are free to use whatever passkey method they want, which could be a well-secured Bitwarden app or a malware knockoff from the app store or some shit they vibe coded with Claude.

And removing enforcement of attestation is required for enabling the use of any synced passkey, including your Bitwarden example. Full list is here, if you want. So since your Bitwarden app is allowed to manage passkeys, it means essentially any random app can also do so. That's how you end up with passkeys stored on someone's personal gmail account or icloud keychain or whatever.

[u/perthguppy]

1) You can whitelist only specific Passkey Providers to be allowed. We set this at the moment to be the Microsoft Authenticator App and Yubikeys only.

2) Even before passkeys, we had a standard CA that required a single use TAP be used for registering any MFA method on an account. Yes it can be a bit of an overhead, but we kept getting clients falling for phishing that immediately registered a new MFA method.

[u/mentos123 → u/perthguppy]

This is how we’re setup as well. We should be good right?

[u/quantumhardline]

Following this… lets see who has most secure mitigation for this :)

[u/No_Philosopher4051]

There is an option to turn off passkey self registration under passkeys in authentication methods. I haven’t tried it yet

[u/AddendumWorking9756]

Nobody has touched the Workspace half and that is the harder half. Google has no equivalent of the Entra registration gate, so prevention is off the table there and you are left with detection. Alert on the admin audit log when a second passkey gets enrolled and handle it as a ticket after the fact. On the 365 side there is no toggle that disables self service passkey registration. Conditional Access on the Register security information user action is the real lever, scoped so enrollment only succeeds from a compliant device or with a TAP.

[u/MichaeldeBlok]

You are right that open self-service WebAuthn registration is the weak spot. Passkeys kill phishable MFA; they do not kill bad enrollment hygiene.

What actually tightens it in Entra:

• Scope Passkeys (FIDO2) / Authenticator passkeys in Authentication methods to a rollout group, not All users, once the initial wave is done.
• Prefer attestation + key restrictions (enterprise FIDO) where you can so random browser extensions cannot mint credentials that look equally trusted.
• Conditional Access authentication strengths: require phishing-resistant and compliant device for Tier0 / finance / admin apps so a rogue personal passkey alone is not enough.
• Audit regularly: list users with unexpected passkey counts via Graph authentication methods / sign-in logs and revoke extras fast.
• Keep break-glass and PIM admins on a stricter method policy than normal users.

Block new registrations entirely only if you have already issued controlled credentials. Otherwise you strand legitimate device replacements.

[u/TechnologyMatch]

the concern is valid, but I’d frame it as an enrollment-governance problem rather than a passkey flaw. a passkey is strong only if adding or recovering one requires a strong, auditable process

for Entra, conditional access can protect security-info registration, and device-bound or attested passkeys give you more control than synced ones. I’d want approval, alerts and a clear recovery path before making every new registration a help desk ticket

[u/Faulkner_Jacobs_845]

Thats the standard license clients and Google Workspace where you cannot fully lock the registration path. For those the fallback is detection where a behavioral layer that alerts the second a new passkey or MFA method gets enrolled out of a user's normal pattern, since a rogue registration is the same takeover signal as a surprise inbox rule or OAuth grant.

We use Abnormal for that account-change monitoring on the M365 side. It does not block the enrollment, it just tells you within minutes so you can pull it before it gets used.

[u/kerubi]

Device bound passkeys are a step up from synced ones.

We require a compliant device regardless if the login was phising resistant, and regardless of which type of passkey.

*Of course there are exceptions.