Passkey Enrollment: how to secure 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 passkey is bound to your domain and the passkey can't be used on a look-alike site, 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 a phishable factor, e.g. 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. 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#

2.1 An unauthorized Passkey is a new Credential#

A stolen password is a copy of an existing secret. Resetting the password makes that copy worthless. A passkey registered by an attacker is different: it is a new authenticator bound to the account, with its own private key under the attacker's control.

That has two consequences:

1. A password reset does not remove it. The relying party still accepts the public key registered for the attacker-controlled credential.
2. Its use can look normal. The login is a successful WebAuthn assertion. Requiring user verification proves that someone unlocked the authenticator; it does not prove that the authenticator belongs to the legitimate account owner.

2.2 The Attack Pattern: phish once, persist with a Passkey#

The enrollment attack has a repeatable sequence: obtain a phishable factor or session, open the genuine credential settings, register a new passkey and use that passkey after the original session or password is invalidated.

Researchers described this pattern in a July 2026 Microsoft Entra campaign. Attackers called employees, framed passkey enrollment as a security upgrade, relayed the victim's password and MFA challenge and bound an attacker-controlled credential to the real tenant (The Hacker News).

The iAuthFlow v2 kit demonstrated the same persistence against a Google account. The victim's password and authenticator-app code were relayed through an attacker-controlled browser. That authenticated browser then opened the passkey settings and registered a new credential. In the seller's demonstration, changing the password ended the current session but did not remove the new passkey, so the operator signed in again (Abnormal AI). This was seller-provided demonstration material rather than evidence from a confirmed live attack, which should remain explicit in the article.

The diagram below separates the genuine WebAuthn ceremony from the decision that allowed the wrong person to start it.

2.3 CIAM and Workforce Enrollment need different Controls#

In CIAM, passkey enrollment is usually self-service: the user is the primary gatekeeper and the provider must secure creation through step-up authentication, risk checks, notifications and accessible recovery.

Workforce IAM adds an administrative control plane. In Microsoft Entra, organizations can restrict registration with Conditional Access and authentication-strength policies, monitor enrollment events and centrally revoke credentials. The July 2026 campaign therefore exposed an insufficiently protected self-service registration path, not an inherent weakness in Entra or passkeys.

Thanks to Emin Hüseynov for highlighting the important distinction between self-service CIAM enrollment and administrator-managed workforce environments, as well as the practical alwaysUv caveat.

2.4 A Passkey cannot protect a weaker Sign-in Route#

The Google account in that demonstration already had a passkey. The attacker did not break it. The victim used an authenticator-app code because that method was still available. The security of the account therefore remained bounded by its weakest accepted sign-in, recovery or support-assisted route.

Adding passkeys alongside passwords and one-time codes improves the passkey path, but it does not make the other paths phishing-resistant. Enrollment security ultimately includes reducing or retiring those weaker methods, especially for credential management.

2.5 Incident Response has a different Order#

If a passkey registration is suspicious, first stop account changes by restricting it and revoking active sessions and tokens. The sequence below shows what follows and why a password reset comes later.

2.6 Users need Product and Support Help#

The Cornell study simulated compromised Google, PayPal and LinkedIn accounts and asked 31 participants to recover them. Most participants struggled to identify and remove the foreign passkey and complete the other containment steps. One participant interpreted two iCloud Keychain entries as one passkey covering two devices (Cornell Chronicle).

The sample is small, so it should not support a universal claim that users "cannot" recover their accounts. It does support a narrower design conclusion: credential provenance, plain labels, independent notifications, a visible "not mine" path and support-assisted containment are part of the security control.

The mockup below turns those conclusions into a credential list a user can act on.

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 device that several people use?
3. What kind of passkey is it? Is it a synced passkey that will likely stay on the device or one on a security key they carry with them?
4. What happens afterwards? Does the user learn about it, can they see the passkey and can you take it away again?

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

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 append a passkey to a session that started with a password and the existing MFA in place (optional).

Recommendations:

• 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 a password or only an OTP and nothing else, ask for a second factor before the passkey is created. A passkey already sitting on the account tells you nothing about how the session in front of you was authenticated.
• 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 Endpoint: personal, shared, managed or unknown#

A passkey should not be stored in a platform credential manager on a public terminal or in a shared operating-system profile. Anyone who can unlock that profile may be able to use the passkey and signing out of the relying party does not remove it.

The difficult part is that WebAuthn does not expose a reliable "this device is shared" signal. An AAGUID identifies an authenticator type or model, not a unique device. The authenticator-attachment result distinguishes platform from cross-platform use and the backup flags describe whether a credential is eligible for backup and its current backup state. None of those values proves who owns the endpoint or how many people use it.

5.1 Classify with a hierarchy of evidence#

Use the strongest evidence available and treat the result as a risk classification, not a perfect device identity.

Instrument the classifier before enforcing it. Measure how often known personal devices split into several identifiers, how often one identifier joins unrelated users and what share of enrollment traffic remains unknown. Seed tests with two internal accounts on the same profile and with one account across browser updates and private mode.

5.2 Apply a policy for each environment#

The safer alternative is often to move the credential, not merely to reject the user. A phone-based cross-device registration or a hardware security key lets a person on a shared computer keep the private credential on something they control.

5.3 Communicate before a credential is created#

The warning must appear before the operating-system passkey dialog, while the user can still choose a different path.

On a known managed-shared endpoint, replace the warning with a decision:

User confirmation is useful, but it is not a substitute for managed-device policy or risk controls in high-assurance environments.

6. Restrict by the kind of Passkey you create#

WebAuthn gives you more control over the passkey itself than many implementations use.

• Require user verification (UV) 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. On compatible CTAP2 authenticators, alwaysUv adds authenticator-level defense in depth by requiring local verification even when the relying party does not. It does not replace userVerification: "required", is not universally supported and can cause interoperability or recovery problems. Test the supported platform matrix and provide a rollback path before enabling it across a managed fleet.
• Decide between platform and roaming authenticators on purpose: authenticatorAttachment: "platform" keeps the passkey in the platform authenticator on the device, 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. Detection, Communication and Containment after Passkey Creation#

Step-up prevents an unauthorized binding. A notification detects one that still got through. Credential inventory, monitoring and revocation contain it. These controls use the same enrollment event, but should not depend on one delivery path.

7.1 Notification for every Binding and observable Invalidation#

Send a security notification whenever a passkey is created: in settings, during onboarding, after a sign-in, after recovery or through an automatic upgrade. Every new passkey is a new authenticator, so the notification itself should not depend on a risk threshold.

NIST SP 800-63B-4 requires a notification through a mechanism independent of the transaction that bound the authenticator. Its account-notification requirements also call for notifications to all stored non-postal notification addresses and clear instructions for disputing the event. An in-session banner is useful confirmation, but it is not an independent security notification.

Notify when a passkey is removed through a path you can observe, including self-service deletion and fraud-team revocation. You cannot observe a deletion performed only inside iCloud Keychain, Google Password Manager or another passkey provider because it does not report that event to the relying party.

7.2 Channel Choice follows the Threat#

For high-security deployments, send both push and email. Protect the destination as part of the control: notify the old and new addresses when contact details change, do not let users disable credential-security alerts and treat a contact change followed by passkey creation as one high-risk sequence.

7.3 Separate Copy for deliberate and automatic Creation#

Use different copy for an action the user deliberately started and for conditional or automatic creation that the user may not recognize.

Suppressing the second notification avoids false alarms in the short term, but removes the account owner's detection control. Different wording is the safer answer.

7.4 Recognizable Details in every Message#

Put the event in the first line and include:

• the passkey provider or authenticator label when you can resolve it with enough confidence
• the browser and operating system
• the date, time and timezone
• the location only if the product already derives and displays it consistently
• clear instructions for what to do if the user does not recognize the event.

Do not call the AAGUID a device name. It identifies an authenticator model and is not provably authentic without attestation. Do not expose credential IDs, public keys, raw handles, full account numbers or marketing content.

FIDO's general communication templates include links to account settings and support. For high-security or phishing-sensitive audiences, a stricter policy is defensible: tell users to open the known app, type the normal address or call a published phone number. That keeps the alert from training users to follow links in security messages. It is a threat-model choice, not a universal standards requirement.

7.5 Visible Credentials and accurate Revocation#

Show passkeys in an easy-to-find account-security list. Label them by provider or provenance, number several entries with the same provider label, show creation and last-used context where available and provide a visible "This wasn't me" path.

When the relying party removes a passkey, say that it was removed from the account and can no longer sign in. Do not claim it was removed from the user's device or passkey provider. Those are separate records.

The WebAuthn Signal API can reduce stale entries, but it is a client API, not a server push channel. After user-initiated deletion in a compatible browser, signal the complete list of credentials the server still accepts. After a fraud team revokes a credential server-side, revoke it immediately and send the updated accepted list during the next suitable client interaction. Use signalUnknownCredential only when the server conclusively rejects an assertion because the credential ID is unknown.

7.6 Fraud Monitoring and Containment#

The registration event should reach three destinations:

1. the user: for independent detection
2. fraud or SIEM systems: for real-time correlation
3. a tamper-evident audit store: for investigation and regulatory evidence.

Useful correlations include passkey creation shortly after recovery, a notification- address change, a new country, a shared-device classification or several registrations in a short period. Each signal should trigger review or an additional control, not count as proof on its own.

For high-risk contexts, consider temporarily preventing a new passkey from authorizing sensitive changes or high-value transactions. Google documents that some newly created passkeys may take up to seven days to become available for sign-in and separately disables passkeys it assesses as suspicious pending confirmation (Google Account Help). A cooling-off policy is a useful reference pattern, but it is not a WebAuthn requirement. Calibrate it to the service's risk and recovery model.

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.

Can WebAuthn tell whether the current Device is shared?#

No. WebAuthn exposes properties of the authenticator and credential, not a reliable shared-device signal. An AAGUID identifies an authenticator model, authenticator attachment distinguishes platform from cross-platform use and backup flags describe whether a credential can be backed up. None proves who owns the endpoint or how many people use it.

Does userVerification: "required" prove that the Account Owner created the Passkey?#

No. User verification proves that the authenticator locally verified a person through a PIN, biometric or similar method. It does not prove that this person is the legitimate account owner. The relying party still needs strong authorization before it binds the new passkey and must validate the UV flag.

Can a Relying Party tell which physical Device holds a synced Passkey?#

Not from WebAuthn alone. The backup-eligibility and backup-state flags describe properties of the credential, not a provider's device inventory. A synced passkey may become available on several devices without a new registration event reaching the relying party.

Should a Passkey Security Notification contain an Action Link?#

It depends on the threat model. FIDO's general communication templates include links to account settings and support. High-security services can avoid action links and instead tell users to open the known app, type the normal address or call a published number, so the alert does not train users to follow links in security messages.

What happens if a Passkey is removed from the Account but remains in a Credential Manager?#

The server-side revocation makes the passkey unusable immediately, but the user may still see a stale entry in their credential manager. In a compatible client context, the WebAuthn Signal API can provide the complete list of credentials the relying party still accepts so the credential manager can reconcile its copy.