Passkey Onboarding Is Still Flawed

Malcolm BroadBy Malcolm Broad - Feb 03, 2026

Simple Reason: You’re Trying to Escape Passwords Using… Passwords???


Passkeys are one of the best things that’s happened to authentication in decades.

They’re phishing-resistant by design, faster for users, and remove entire categories of failure we’ve normalised—password reuse, credential stuffing, and “human helpdesk theatre” during recovery. The FIDO Alliance has been unequivocal: passkeys are FIDO credentials built on public-key cryptography, intended to replace passwords with stronger security and better UX. 

And yet, in the real world, passkey onboarding is often flawed in a very specific (and very avoidable) way:

·       We try to bootstrap the passwordless future using the most breached credential pair in history: username + password.

That’s not just ironic. It’s a structural security failure.

Because the riskiest moment in any authentication journey isn’t the steady-state “sign-in with a passkey.” It’s the moments of transition—enrolment, device change, recovery, and account re-binding. Those are the “high-leverage” points attackers target, and the places many passkey programs quietly fall back to legacy proofs: passwords, SMS, email OTPs, or weak knowledge-based checks.

If you want to understand why passkey onboarding can be broken, you need to look at the threat model and the incentives:

  • Organisations want quick adoption, minimal friction, and low helpdesk load.
  • Users want convenience, not a new identity ritual.
  • Attackers want the cheapest path to impersonation—and that’s still credentials and recovery.

And we have very recent evidence that stolen credentials remain a dominant breach driver. Verizon’s 2025 DBIR highlights that stolen/compromised credentials remain a major initial access vector, and that basic web application attacks frequently involve stolen credentials.

So, when passkey onboarding still depends on passwords—even “just once”—you’ve kept the door open at the worst possible time.

 

The Passkey Promise (And Why FIDO Is Right)

Let’s ground this in what passkeys actually are. Passkeys replace shared secrets (passwords) with a cryptographic key pair: a public key stored by the service and a private key protected on the user’s device (or security key). Authentication becomes a cryptographic ceremony, not a memorised secret exchange. FIDO frames passkeys as phishing-resistant, designed to improve security and UX simultaneously.

FIDO has also invested in practical guidance on how to make passkeys usable: UX guidelines for creation and sign-in, and specific best practices for account recovery—because recovery is where good authentication goes to die.

On paper, it’s a clean break from password pain. In practice, the break is often incomplete.

The “Passwordless Bootstrap” Trap: How Passkey Rollouts Reintroduce Password Risk

There’s a pattern I see repeatedly in enterprise and consumer implementations:

  1. User signs in with username + password (sometimes plus MFA).
  2. They are prompted to “add a passkey.”
  3. The organisation celebrates “passkey adoption.”
  4. But the account’s root is still anchored in legacy credentials and legacy recovery.

Some platforms even describe this explicitly as “bootstrapping” an account using non-passkey challenges such as passwords. That phrase “bootstrapping” should set off alarms.

Because bootstrapping isn’t just a UX step. It’s a trust ceremony. It answers the question: “Why do we believe the person enrolling this passkey is the legitimate account holder?”

If your answer is “because they typed the correct password,” then you have not escaped the past. You have simply wrapped better crypto around a rotten foundation.

Why this is uniquely dangerous, Passwords are compromised at scale:

  • Breach dumps
  • Credential stuffing
  • Infostealers
  • Phishing kits that now look indistinguishable from real login flows

If the attacker has the password, then a passkey enrolment flow becomes something far worse than “a login risk.” It becomes an account takeover permanence mechanism.

Because once an attacker enrols their passkey (or binds their device), you can end up with:

  • The legitimate user locked out
  • The attacker holding a phishing-resistant authenticator (ironically)
  • Recovery processes that treat the attacker’s new passkey as “strong proof”

This is the nightmare scenario: phishing-resistant sign-in protecting the wrong person.

The Two Broken Moments: Enrolment and Recovery

1) Enrolment: The “New Key” Problem

Passkeys are great at proving “this is the same device/private key as last time.” They are not, by themselves, a complete solution to “this is the right human enrolling the key for the first time.”

That’s why FIDO’s UX guidance includes user journeys for passkey creation and sign-in, and why recovery guidance exists as a first-class concern.

The enrolment moment is “new key issuance.” In identity terms, that’s equivalent to issuing a new credential. If you issue that credential based on a password, you’ve allowed any password holder to mint a stronger authenticator. And credentials are exactly what attackers most commonly abuse to get in.

2) Recovery: The “Weak Link”

That Undoes the Chain Recovery is where many passkey programs quietly regress to the lowest common denominator:

  • Email links (“click to verify”)
  • SMS OTP
  • Call centre KBA
  • “Trusted device” prompts with poor controls
  • Password fallback “just in case”

FIDO’s own account recovery best practices explicitly push organisations toward safer patterns, including using multiple authenticators to reduce recovery events and avoiding risky recovery that forces identity proofing unnecessarily.

But the real world is messy. People lose phones, change devices, travel, get locked out, forget what they did months ago.

So, if your recovery path is weaker than your sign-in path, attackers will camp there. Always.

Why Password-Based Passkey Onboarding Is a Breach Multiplier

Let’s translate this into attacker economics.

When passkeys are properly deployed, phishing kits and credential stuffing get massively less valuable. Great.

But if passkey onboarding starts with username/password, attackers don’t need to beat passkeys. They only need to beat the onboarding gate or the recovery gate.

And they already have industrial-scale tooling for that. Stolen credentials are still central to modern breach patterns.

So, what happens?

  • Credential stuffing succeeds on a subset of users (because passwords are reused).
  • Attacker logs in once.
  • Attacker enrols a passkey.
  • Attacker now has durable, phishing-resistant access.
  • The user later “can’t sign in” and starts recovery, which may not detect the enrolment attack.

You’ve turned a password compromise into a more persistent compromise.

That is the opposite of what passkeys are meant to do.

The Adoption Paradox: “Make It Easy” Can Make It Insecure

A lot of passkey onboarding is designed with good intentions:

  • Reduce friction
  • Avoid extra steps
  • Increase opt-in rates
  • Lower helpdesk calls

FIDO’s UX guidance exists for a reason: if you make passkeys feel alien, adoption stalls.

But organisations sometimes misread this as: “The easiest onboarding is: ask for password, then prompt for passkey.” It’s easy. It’s familiar. It will “work.” And it will embed the very risk you’re trying to remove.

So, the real problem isn’t passkeys.

The problem is the trust primitive you use for enrolment and recovery.

If that primitive is “something the user knows” (password), then your passkey rollout remains vulnerable to:

  • credential theft,
  • replay at scale,
  • account takeover during enrolment,
  • and recovery pathway abuse.

The Fix: Treat Onboarding Like Issuance, Not Like Login

Here’s the mental shift that changes everything: Passkey onboarding is not “enabling a feature.”

It is credential issuance and credential issuance must be anchored in strong proof of:

  • who the human is,
  • that they are entitled to that account,
  • and that the binding event is legitimate.

FIDO’s guidance across UX and recovery keeps circling the same truth: deployment success depends on handling those edge journeys correctly, not just the happy-path sign-in.

So, what should anchor issuance?

·       Not passwords.

·       Not email links.

·       Not SMS.

·       Not “your first pet’s name.”

You need a better trust primitive.

Enter Verifiable Credentials: A Better Trust Primitive for Enrolment and Recovery

This is where verifiable credentials (VCs) become the missing piece that makes passkeys operationally “enterprise-grade” without dragging the user through friction and helpdesk pain.

A verifiable credential is a cryptographically signed assertion about a subject (a person, a device, an employment relationship, an entitlement), issued by a trusted authority and presented by the holder from a wallet they control.

Crucially:

  • It’s not a shared secret.
  • It’s not something you can “reuse” across sites like a password.
  • It can be verified cryptographically in seconds.
  • It can be scoped to purpose and risk.
  • It can be revoked/expired.

And the FIDO ecosystem has explicitly explored the relationship between passkeys and verifiable digital credentials as a harmonised path for secure digital identity—particularly for recovery and wallet scenarios.

So instead of “prove you are you by typing a password,” you can do: “Prove you are you by presenting a cryptographically verifiable credential that you control.” That’s a fundamentally stronger and more modern onboarding model.

How VO Fixes the Broken Passkey Onboarding Loop

VO’s approach (and where it becomes best-practice security in the passkey era) is simple in concept: Replace password bootstrap with verified credential bootstrap.

In other words:

  • Stop using username/password as the root of trust.
  • Use verified credentials to bind identity at onboarding, at step-up, and at recovery.
  • Let passkeys do what they’re best at: fast, phishing-resistant authentication.
  • Let verifiable credentials do what they’re best at: high-trust proof of identity/entitlement for risky flows.

What that looks like in a real journey


1) First-time enrolment (new user or first device)

Instead of:

  • username + password → “add a passkey”

Do:

  • user presents a verified credential (e.g., employee credential, student credential, customer KYC credential, device binding credential)
  • service verifies it cryptographically
  • service issues/binds passkey to the legitimate account holder

Now an attacker who stole a password can’t mint a passkey, because they can’t present the credential from the legitimate user’s wallet.


2) High-risk actions (step-up)

Passkeys are good for sign-in, but many breaches occur during high-risk actions:

  • password reset
  • MFA reset
  • payment detail changes
  • device rebind
  • helpdesk impersonation

VO uses verified credentials as the step-up proof:

  • “present your VC” → cryptographic verification → action proceeds

 

3) Recovery and re-binding (lost device / new phone)

Instead of:

  • “email link / SMS / answer questions / call helpdesk”

Do:

  • recover using a verified credential (and/or multiple authenticators, aligned with FIDO recovery guidance about reducing recovery events via multiple authenticators)
  • re-bind device/passkey only after cryptographic proof of entitlement

 

This closes the loop attackers exploit most.

Security Outcome: You Eliminate the Most Breached Credential From the Most Dangerous Moment

When you remove username/password from onboarding and recovery, you directly reduce exposure to the breach patterns that keep repeating.

You’re no longer saying:

  • “If you know the password, you can become the account.”

You’re saying:

  • “To become the account, you must control a cryptographically verifiable credential issued by a trusted authority.”

That’s a different security world. It’s also how you make passkeys safe to scale.

UX Outcome: Less Friction, Higher Adoption, Better NPS

Here’s the part many teams miss: Better security can also mean better user experience, if you choose the right primitives.

Passkeys already improve UX when they work: no password typing, no MFA hoops, fast sign-in. FIDO explicitly positions passkeys as both stronger and easier.

But onboarding friction is what kills adoption:

  • confusing prompts
  • device compatibility issues
  • “wait, where did my passkey go?”
  • “why do I still need a password sometimes?”
  • recovery pain

When you use verified credentials for onboarding and step-up, the flow becomes more coherent:

  • The user proves who they are once, in a modern way.
  • The passkey becomes the everyday experience.
  • The helpdesk stops playing detective.
  • The user stops being punished for forgetting secrets.

In VO deployments, the shift from “password rituals” to “verified proofs” has translated into significantly improved user sentiment, often reported as NPS in the 77+ range, because users experience fewer lockouts, fewer resets, and less friction at the exact moments they care about (access now, not later).

And importantly: this isn’t “make security invisible.” It’s make security intelligible: “show a credential, get verified, move on.”

 

What FIDO Would Call “Best Practice” in a Passkey World

If we take FIDO’s own published direction seriously—UX guidance, recovery best practices, and the broader push toward phishing-resistant authentication, then a best-practice passkey program should aim for:

  1. Passkey-first journeys (don’t treat passkeys as an optional add-on forever)
  2. Strong, well-designed recovery (reduce recovery where possible; avoid weak fallbacks)
  3. Minimise reliance on passwords and OTPs as the ultimate backdoor
  4. Treat onboarding and recovery as security-critical ceremonies, not mere UX screens
  5. Design for real-world device change (synced vs device-bound considerations, policy choices)

VO’s model complements this by giving you a practical way to strengthen the two hardest parts (enrolment and recovery) without falling back to passwords.

And the FIDO Alliance has explicitly explored passkeys alongside verifiable digital credentials as part of a harmonised approach to secure identity—especially relevant when wallets and recovery enter the picture.

 

The Executive Take: Passkeys Don’t Remove Password Risk If Passwords Still Issue the Keys

If you’re a CIO, CISO, Head of Identity, or Product leader, here’s the blunt truth: You don’t get the passkey security outcome unless you fix onboarding and recovery.

If your passkey rollout still depends on username/password at the critical trust moments, you’ve created a new attack path:

  • attackers don’t need to defeat passkeys,
  • they just need to enrol their own.

And in a world where stolen credentials remain a major breach driver, that’s a bet you don’t need to make.

So the real modernisation isn’t “passkeys instead of passwords.” It’s:

  • passkeys for authentication
  • verified credentials for issuance, step-up, and recovery
  • no shared secrets as the root of trust

That’s how you eliminate the most breached credential pair from the highest-risk workflows.

That’s how you get the security story and the adoption story. And that’s how you turn passkeys from “a promising feature” into a truly resilient identity control plane.

 

Practical Checklist: A Best-Practice Passkey + VO Onboarding Model

If you want something you can take straight into a program plan, use this:

Do this

  • Make passkey enrolment require strong proof of entitlement (not just “knows password”).
  • Use verified credentials as the bootstrap mechanism for first-time binding.
  • Require verified credential step-up for high-risk actions (resets, device rebind, payout changes).
  • Follow FIDO recovery best practices: reduce recovery by enabling multiple authenticators; design recovery as a secure journey, not a last-minute patch.
  • Use FIDO UX guidelines to keep prompts consistent and understandable.

Avoid this

  • “Password sign-in → add passkey” as your primary model.
  • Password fallback “just in case” as your permanent escape hatch.
  • Weak recovery that becomes the attacker’s preferred entry point.

 

References

FIDO Alliance. (2025, September 22). Passkeys and verifiable digital credentials: A harmonized path to secure digital identity [White paper]. FIDO Alliance. https://fidoalliance.org/passkeys-and-verifiable-digital-credentials-a-harmonized-path-to-secure-digital-identity/

FIDO Alliance. (n.d.). Passkeys: passwordless authentication. FIDO Alliance. Retrieved January 28, 2026, from https://fidoalliance.org/passkeys/

FIDO Alliance. (2024, August 29). Replacing password-only authentication with passkeys in the enterprise [White paper]. FIDO Alliance. https://fidoalliance.org/white-paper-replacing-password-only-authentication-with-passkeys-in-the-enterprise/

FIDO Alliance. (2026, December). Statistics sources [Web page]. FIDO Alliance. https://fidoalliance.org/statistics-sources/

Verizon. (2024). 2024 Data Breach Investigations Report (DBIR). Verizon Enterprise Solutions. https://www.verizon.com/business/resources/reports/2024-dbir-data-breach-investigations-report.pdf

Verizon. (2025). 2025 Data Breach Investigations Report (DBIR). Verizon Enterprise Solutions. https://www.verizon.com/business/resources/reports/dbir/

Verizon. (2025, September 30). Frequently asked questions on credential theft prevention and protection. Verizon Enterprise Solutions. https://www.verizon.com/business/resources/articles/s/frequently-asked-questions-on-credential-theft-prevention-and-protection/

Tags:
Malcolm Broad

Malcolm Broad

Chief Growth Officer


Latest articles