Passkey Enrollment: how to protect Passkey Creation

1. Introduction: the Problem moved from Login to Creation#

At the login itself, passkeys do their job. The private key is never shared with the server, the signature is bound to your domain and a look-alike site gets nothing out of it, which is why passkeys resist phishing where user training has always struggled.

That pushes attackers one step earlier in the flow. If they get into the account once, through an SMS OTP, a password or a support agent who wants to be helpful, they no longer need to steal a credential: they can register one of their own. From that point on they hold a login that is phishing-resistant, convenient and, from the server's point of view, entirely legitimate.

The question comes up in almost every banking project we run, and in August 2026 a Cornell study showed how much trouble users have once it has happened to them. The creation flow is usually built for adoption, which is the right goal, but few teams ask what that flow permits in the worst case.

2. Why an attacker Passkey is worse than a stolen Password#

A stolen password is a copy of your secret, and a reset makes that copy worthless. A passkey registered by an attacker is not a copy of anything. It is a second credential on the account, fully valid, with the private key sitting in the attacker's keychain.

Two consequences:

• A password reset does not remove it. The account still has the attacker's public key on file, so the attacker signs in again right after the reset.
• It looks legitimate in the logs. The login is a successful WebAuthn assertion with user verification. Fraud rules that look for password anomalies see nothing.

That changes the order in which you clean up. As long as the attacker holds a session that can manage credentials, deleting their passkey only means they register a new one a minute later. So lock the account and sign every device out in one move. Then remove the unknown authenticators, reset the password and the recovery factors and unlock the account at the end. Starting with the password reset is the common mistake, because the attacker's passkey is untouched by it.

In July 2026, security researchers described a campaign that did exactly this at scale. The attackers registered domains with "passkey" in the name, called employees claiming their account needed a passkey and walked them through a phishing panel that looked like the Microsoft enrollment. They took the password, relayed the MFA challenge in real time and had the user approve a passkey registration the attackers had started, which left an attacker-controlled credential inside a real Microsoft 365 tenant (The Hacker News). The victims went through the enrollment believing it made their account safer.

The Cornell study measured how far users get with the cleanup on their own. The researchers simulated a compromised Google, PayPal or LinkedIn account with an attacker's passkey on it and asked 31 participants to sort it out ("Maybe There's Only One Passkey?", USENIX Security 2026). Almost nobody recognized the login from the attacker's device without help, and most could not remove the foreign passkey, reset the password and sign the other devices out on their own. One participant saw two passkeys in the iCloud Keychain, their own and the attacker's, and read it as a single passkey covering two devices.

Users struggle to read the credential list, so the work sits with the notification you send at registration and with support running the cleanup, not with the account owner spotting the foreign key.

3. Four Questions before you allow a Passkey to be created#

Four questions cover most of the design work:

1. Who is asking? How strong was the authentication in this session, and is it strong enough for the credential you are about to hand out?
2. On which device? Is this a device that belongs to this user, or a browser that several people use?
3. What kind of credential is it? One that stays on the device in front of the user, or one on a security key they carry with them?
4. What happens afterwards? Does the user learn about it, can they see the credential and can you take it away again?

4. Check the Person: Step-up before Creation, not after#

A new passkey is at least as powerful as the strongest factor on the account, so the check before creating it has to be at least as strong.

NIST SP 800-63B-4 says the same in normative language. Section 4.1.2.1 requires the binding to be authenticated at the highest assurance level the account already offers, capped at the level the new authenticator will be used at, and the provider has to notify the subscriber over a separate channel. Most consumer flows do neither. They append a passkey to a session that started with an SMS OTP weeks ago and stay quiet about it.

In practice:

• Bind creation to a fresh, strong authentication. Not "the user has a valid session", but "the user authenticated with a strong factor in the last few minutes". A completed step-up or a payment authorization is a good moment for it.
• Step up when the session started weakly. If the login was an SMS OTP and nothing else, ask for a second factor before the passkey is created, not before the next payment.
• Verify the person where the stakes justify it. In regulated onboarding, a document check before enrollment removes the whole class of "who actually opened this account".
• Verify with a digital credential, then create the passkey. The user presents a credential from a wallet, an EUDI Wallet identity or a mobile driving licence, and the passkey follows only once that check passes. It binds the credential to a verified person instead of to whoever held the session. Few stacks can do this today. Our article on digital credentials and passkeys covers where the standards stand today.
• Treat recovery flows as enrollment. The recovery path is where an attacker will look first, so a passkey created directly out of an account recovery needs your strictest check. Our article on passkey fallback and recovery covers that side.

5. Check the Device: shared Environments and Kiosks#

The second case has nothing to do with attackers. A user signs in at a library terminal, an airport kiosk or a shared desktop in a branch, gets the friendly prompt, taps yes and leaves a working credential behind. Compliance teams in banking raise this before anything else.

The control is to classify the environment before you offer the prompt. Count how many distinct accounts have signed in from the same browser environment, and once more than two show up within 30 days, treat that environment as shared and either suppress the prompt or replace it with a warning. Where you have only seen a device a handful of times, it is better to wait: a few more weeks of observation cost less than a credential left behind on the wrong machine.

The rule only fires if people really do share devices, so check that before you build on it:

• Count the shared environments you already have. Group logins by client environment and count distinct user IDs per environment over 30 days. If nothing sits above one, either your users genuinely do not share devices or your environment identifier is too weak to notice.
• Check the identifier from the other side. The same person in the same browser has to produce the same environment across sessions. If one user shows up as five environments in a month, the shared-device rule will never fire and the device list in the account settings is noise as well.
• Seed a test. Sign two internal accounts in from one browser and confirm the flag flips. It is the quickest way to see whether the rule is wired up at all.

Three things distort that count in practice:

• Incognito. On iOS 10 to 15% of sessions run in private mode, and every one of them looks like a new device.
• Missing cleanup logic. Without it, browser updates turn one iPhone into fifteen entries in the device list, and nobody can tell a real second device from a version change.
• Fingerprinting does not solve it either. Those services test well on small groups and lose accuracy in a city full of identical iPhones on the same OS version.

On public terminals in kiosk mode, do not offer passkey creation at all. Make that decision server-side rather than in the client.

6. Restrict the Credential: what kind of Passkey are you creating?#

WebAuthn gives you more control over the credential itself than most implementations use.

• Require user verification at creation and at every login. userVerification: "required" at creation binds the credential to a biometric or PIN. It does not carry over to later logins on its own: if the assertion request asks for preferred or discouraged, possession of an unlocked device is enough again. Ask for required on both ceremonies and reject assertions whose UV flag is false.
• Decide between platform and roaming authenticators on purpose. authenticatorAttachment: "platform" keeps the credential on the device in front of the user, which is what makes adoption work. "cross-platform" points them at a security key or a second phone, slower but on something they carry with them. If you leave the field empty, the user makes the choice, which is fine on a personal device and less so on a shared one.
• Use attestation where you can. In workforce and regulated deployments it tells you which authenticator model was used, so you can restrict creation to models you trust. In consumer flows it is usually not worth the friction and often not even possible, because the credential managers behind synced passkeys return no meaningful attestation.
• Do not allow silent creation on weak sessions. Conditional create works well for adoption because it upgrades a password user in the background. Precisely because the user is not paying attention at that moment, it needs the same session check as any other creation.

7. Watch what happens after Creation#

After creation, someone has to be able to see the credential and take it away again.

• Notify on every registration. Send an email or a push with the device name, the time and a revoke link. It costs little to build and NIST expects it anyway.
• Show the credential list where users find it. If the list only exists in a settings page three levels deep, the notification has nowhere to lead. This is where the Cornell participants got stuck, so plain device names and a visible "this is not mine" action matter as much as the list itself.
• Keep server and credential manager in sync. The Signal API lets you tell the credential manager that a credential was revoked or renamed, so a deleted passkey stops showing up in the user's list.
• Alert on a few clear patterns. A registration right after a recovery, several registrations from one environment or a new credential from a country the account has never seen are simple rules and they catch the obvious cases.
• Consider a cooling-off period. Some banks hold high-value transfers for a period after a new authenticator is bound. It costs a little convenience and removes the immediate payoff of a stolen enrollment.

8. How Corbado can help#

Every control above ends in one decision at runtime: is this session, on this device, allowed to create a passkey right now? Most teams cannot answer that today, because they have very little data on the enrollment flow.

Corbado Observe makes the enrollment side measurable on top of your existing login, without a passkey programme in place:

See Login Funnel in Corbado Observe →

• Credential inventory: see which authenticators exist across your user base, which is the list you need before you can spot the one that does not belong.
• Enrollment funnel: follow the creation flow step by step and see where users drop out, so tightening the checks does not quietly cost you adoption.
• Environment and device data: the client environment behind each login is what makes shared-device classification possible, and what lets you check whether that rule fires at all.
• Per-user debugging: reconstruct a single user's history when support asks what happened on that account.

Corbado Connect is the other half, for teams that want the flow itself: it adds passkey creation and the step-up decision to an existing authentication stack, so the prompt appears when your risk rules allow it.

9. Conclusion#

Passkeys moved the phishing problem rather than removing it. With the login closed, the pressure sits on enrollment and recovery, and both are usually built for conversion.

None of the controls are complicated: authenticate properly before you bind a credential, know whether the device is shared, be deliberate about the kind of credential you issue and tell the user afterwards. What takes effort is asking, at design time, what the creation flow permits when the person on the other side is not the account owner.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

Frequently Asked Questions#

Why is passkey creation the new weak point?#

A passkey cannot be phished at login, so attackers move one step earlier. If they get into an account once through a phishable factor such as an SMS OTP, they register their own passkey and keep permanent access. Unlike a stolen password, that credential survives a password reset, because it is a legitimate credential on the account.

How do you stop a passkey from being created on a shared or public device?#

Classify the environment before you offer the prompt. If several different accounts have signed in from the same browser environment, treat it as shared and either suppress the passkey prompt or put an extra check in front of it. Where you have only seen a device a few times, it is better to wait: a few more weeks of observation cost less than a credential left behind on a library terminal, a call center desktop or a kiosk.

What does NIST require before an additional authenticator is bound to an account?#

NIST SP 800-63B-4 section 4.1.2.1 requires the binding process to authenticate at the maximum assurance level currently available on the account or at the level the new authenticator will be used at, whichever is lower. The credential service provider also has to notify the subscriber over a channel independent of the binding transaction.

In which order do you clean up an account after a suspicious passkey registration?#

Lock the account and sign every device out first, otherwise an attacker with a live session simply registers a new credential while you clean up. Then remove the unknown authenticators, reset the password and the recovery factors and unlock the account last. Starting with the password reset leaves the attacker's passkey in place, and that credential is enough to sign back in.