What happens when the phone that holds your passkey is lost, stolen, or wiped in a factory reset? That question sits at the heart of every honest conversation about passwordless authentication. The technology is genuinely good at stopping phishing. It is not, however, a finished solution. Passkeys and hardware security keys remove the password from the login screen, but they push hard problems into account recovery, device management, and platform politics. This article walks through the real limitations, with practical detail on what works, what breaks, and what IT teams should plan for before flipping the switch.
What “Passwordless” Actually Means Matters
The word gets stretched. Magic links, emailed one-time codes, and SMS codes are sometimes sold as passwordless. They are not phishing-resistant. If an attacker can trick a user into typing a code into a fake site, the login method is only marginally better than a password. True phishing resistance comes from cryptographic credentials bound to a specific website origin, which is what WebAuthn and FIDO2 deliver.
That distinction matters because limitations differ by method. A magic-link system has all the weaknesses of email. A synced passkey has the weaknesses of a cloud account. A hardware key has the weaknesses of a physical object. Before complaining about passkeys, teams should be clear about which category they are deploying. For background on how multi-factor flows fit together, see this explainer on what multi factor authentication is.
Limitation 1: Account Recovery Is the Weak Link
Every passwordless system needs a way back in when the authenticator is gone. That recovery path is usually the softest target in the whole chain. If recovery runs through email, SMS, or a support desk that can be socially engineered, an attacker does not need to break the passkey at all. They simply go around it.
The FIDO Alliance has flagged this repeatedly: recovery flows can quietly undo the phishing resistance that made passkeys attractive. In practice, the organizations that handle this well follow a few rules:
- Treat recovery as a security-critical flow, not a helpdesk convenience.
- Require multiple independent proofs of identity before re-enrolling an authenticator.
- Log and alert on every recovery event, then review them weekly.
- Never let a single channel (email or SMS) restore full account access.
- Test the recovery path with red-team exercises, not just the happy path.
The most common mistake is bolting recovery on after launch. It should be designed first. If recovery is weak, the passkey is theater.
Limitation 2: Device Loss, Shared Devices, and Kiosks
Passwordless login assumes the authenticator is present. On a shared warehouse terminal, a public library PC, or a hospital workstation that rotates between nurses, there is no personal phone to tap. Device-bound passkeys simply do not fit these environments without extra hardware or fallback methods.
There are workarounds. Security keys can be issued per workstation, smart cards can be provisioned per shift, and some organizations use roaming authenticators stored in a lockbox. All of these add cost and operational overhead. A small business with fifteen employees on shared desktops will feel that overhead more than a bank with a dedicated IT team.
There is also the human factor. People forget keys. People leave them in laptops. People lend phones to colleagues. Any passwordless rollout needs a plan for the day someone shows up without their authenticator, and that plan usually involves a temporary credential that reintroduces the risk you were trying to remove.
Limitation 3: Ecosystem Lock-In and Portability
Synced passkeys live in a credential manager: iCloud Keychain, Google Password Manager, Microsoft’s vault, or a third-party manager. That is convenient until a user switches ecosystems. Moving passkeys between platforms has historically been awkward, and portability work is still maturing.
This creates a subtler problem than vendor lock-in. It creates trust concentration. A single cloud account now guards the keys to dozens of services. If that account is compromised, the blast radius is enormous. If the account is locked by a vendor error, the user may lose access to everything at once.
The practical advice here is to diversify. Users who rely on one ecosystem should keep a hardware security key registered as a backup authenticator on critical accounts. Organizations should document which credential managers they support and test cross-platform sign-in before mandating passkeys. The same principle applies when comparing password managers for team use, as covered in this breakdown of 1password vs proton pass.
Limitation 4: Legacy Systems and the Long Tail of Software
Most enterprises run software that predates WebAuthn. Legacy VPNs, older line-of-business apps, mainframes, and industrial control systems often have no passkey support and never will. The workaround is a federation layer or an identity provider that translates modern authentication into whatever the legacy system expects.
That translation layer is where things get messy. Some organizations end up maintaining a password vault purely to feed credentials into legacy apps, which means passwords never truly disappear. Others deploy a passwordless front door with a password back door, which is better than nothing but should be described honestly in security documentation.
A realistic rollout looks like a tiered migration. Consumer-facing and modern SaaS apps go passwordless first. Internal legacy systems follow as contracts allow. Some systems sit in a permanent exception list, and that is acceptable as long as the exceptions are tracked and reviewed.
Limitation 5: User Education and Support Burden
Passkeys are easier in daily use and harder to explain. Users who have spent twenty years typing a password will ask where it went. They will not understand why the login screen now shows a fingerprint prompt. They will call the helpdesk when a prompt appears on a device they do not recognize.
Support teams need scripts, and those scripts need to be specific. Generic advice like “just follow the prompt” fails when the prompt appears on a tablet the user borrowed. A few practical measures help:
- Publish a one-page guide per supported platform, with screenshots.
- Train the helpdesk on recovery flows before launch, not after.
- Run a small pilot with real users and collect the questions they ask.
- Keep a documented fallback for users who cannot enroll yet.
The support burden peaks in the first month and then drops. Budget for the peak. Organizations that skip this step often see adoption stall at the pilot stage, with users quietly reverting to passwords wherever the system allows it. The same pattern shows up with other new tech, as this piece on AI article generator features and limitations notes about tooling rollouts generally.
Limitation 6: Biometrics Are Convenient, Not Magic
Fingerprint and face unlock make passkeys feel seamless, but they are a local convenience layer, not a security guarantee. A fingerprint sensor on a cheap phone can be spoofed. Face unlock on some devices has been defeated by photographs. Biometric templates also cannot be changed if compromised, unlike a password.
This is why the strongest deployments pair biometrics with a hardware-backed secure enclave and treat the biometric as a local unlock for a cryptographic key, not as the key itself. For a deeper look at where biometrics fit, see what is biometric authentication. The takeaway: biometrics reduce friction, they do not replace the need for secure hardware and sound recovery design.
Limitation 7: Regulatory and Audit Friction
Regulators move slower than browsers. Auditors often ask for evidence of “something you know” even when the authentication is stronger without it. Financial services, healthcare, and government contractors frequently face frameworks written before passkeys existed.
The good news is that guidance is catching up. NIST’s digital identity guidelines have moved toward recognizing syncable authenticators and phishing-resistant methods, and various national digital identity programs now reference passkeys explicitly. The bad news is that internal audit teams may still want a password on file for compliance reasons. Security leaders should prepare a written justification that maps passkeys to the relevant control framework, and get it signed off before the rollout, not during an audit. (NIST Cybersecurity Framework)
Limitation 8: Adoption Data Is Thin
Vendors love to quote adoption numbers, but independent data on how many people actually use passkeys in daily life is sparse. Many accounts have a passkey registered but still allow password login, which means the passkey is optional and often unused. Optional security features tend to be ignored.
If an organization wants real adoption, it has to remove the password option for at least some user groups. That is a policy decision, not a technical one, and it requires executive backing. Without that backing, passkeys become a checkbox on a compliance form.
A Practical Comparison of Passwordless Methods
| Method | Phishing resistant | Works on shared devices | Recovery risk | Best fit |
|---|---|---|---|---|
| Synced passkeys | Yes | No | High (cloud account) | Consumer apps, remote staff |
| Hardware security keys | Yes | Yes, with per-device keys | Medium (physical loss) | Admins, high-value accounts |
| Platform biometrics only | Partly | No | High | Low-risk consumer logins |
| Magic links and OTP | No | Yes | High | Low-risk, temporary access |
| Smart cards | Yes | Yes | Medium | Regulated enterprises |
The table is a starting point, not a verdict. Most organizations end up mixing methods, and the mix should be documented so support staff know which fallback applies to whom.
Conclusion: Passkeys Are a Big Step, Not the Last One
Passwordless authentication solves the problem it was designed to solve: it makes credential phishing dramatically harder and removes the weakest link in most breaches. But it does not eliminate the need for careful identity design. Recovery flows, shared devices, legacy systems, ecosystem dependence, and audit friction all remain real limitations that require planning, budget, and honest documentation.
The organizations that succeed treat passkeys as one layer in a broader identity strategy. They design recovery first, pilot with real users, keep a hardware key as backup, and accept that some legacy systems will lag for years. The ones that struggle usually skipped those steps and expected the technology to manage itself. For a step-by-step view of enabling stronger login methods today, this guide on how to enable two factor authentication is a sensible starting point before going fully passwordless.
Frequently Asked Questions
Are passkeys really more secure than passwords?
Yes, for phishing resistance specifically. Passkeys use cryptographic keys bound to a website’s origin, so a fake login page cannot capture them. Passwords can be phished, reused, and leaked in breaches. The caveat is that passkey security depends heavily on how account recovery is designed. A strong passkey with a weak recovery flow is only as secure as the recovery flow.
What happens if I lose the device holding my passkeys?
It depends on the credential manager. Synced passkeys stored in a cloud account can usually be restored on a new device after signing in to that account. Device-bound passkeys are gone unless a backup authenticator was registered. This is why security teams recommend registering at least two authenticators per account, ideally one hardware key kept in a safe place.
Can passwordless authentication work on shared computers?
It can, but not with personal passkeys alone. Shared environments typically rely on per-device hardware keys, smart cards, or roaming authenticators issued per user. Some organizations use a short-lived fallback credential for shared terminals. Each option adds cost and administrative work, so shared-device support should be scoped early in any rollout.
Is passwordless authentication the same as two-factor authentication?
No. Two-factor authentication adds a second proof to a password. Passwordless authentication removes the password entirely and relies on the authenticator alone, sometimes with a local biometric unlock. Many passwordless systems still involve two factors in practice, because the device is unlocked by a PIN or fingerprint before the cryptographic key is used.
Do passkeys work across different platforms and vendors?
Increasingly, yes, but portability is still maturing. Cross-ecosystem export and import of passkeys has been limited, and industry work on standard exchange formats is ongoing. Users who switch between ecosystems should register backup authenticators on critical accounts and confirm that their chosen credential manager supports the platforms they actually use.
Why do some organizations still keep passwords for certain systems?
Legacy applications, older VPNs, and some regulated systems predate modern authentication standards and cannot accept passkeys. Rather than replace those systems immediately, many organizations keep a password path for a defined exception list while migrating everything else. The key is to track those exceptions, review them regularly, and avoid letting the exception list quietly become the default.
