Passwords are the cockroaches of the internet: you can spray all you want, they keep coming back. And they keep getting people hacked, mostly through phishing and the eternal bad habit of reusing the same login everywhere.
That’s why passkeys are suddenly everywhere. They’re the consumer-friendly face of a bigger push led by the FIDO Alliance and baked into web standards (WebAuthn via the W3C) to stop treating “hunter2” like a security strategy. The pitch is simple: public-key cryptography plus the strong authentication already sitting inside your phone and browser.
But ripping out passwords isn’t a toggle. In real organizations, you’ve got existing login flows, directories, compliance rules, and the messy truth that people lose devices, upgrade phones, and sign in from a zoo of laptops, browsers, and locked-down corporate machines. This turns into an architecture fight: how do you combine FIDO2, SSO, and identity standards without creating fresh blind spots?
How passkeys actually work: WebAuthn in the browser, CTAP2 to the device
The guts of passkeys are two standards working as a tag team:WebAuthn(the browser API) andCTAP2(how the browser talks to an authenticator, your phone, a hardware security key, or a built-in module, over USB, NFC, or Bluetooth).
Here’s the flow without the marketing fog. When you enroll, the website generates a cryptographic challenge. Your authenticator creates a key pair: aprivate keythat stays protected on the device and apublic keythat gets stored by the service. When you sign in later, the service sends a new challenge, the device signs it with the private key, and the server verifies the signature using the stored public key.
The practical win is huge: the private key never leaves the device, and the signature is tied to the legitimate domain. That domain-binding is what makes phishing dramatically harder, fake lookalike sites can’t just “steal” something reusable the way they do with passwords and one-time codes.
Passkeys are WebAuthn credentials packaged for normal humans: quick sign-in triggered by Face ID/Touch ID, Android biometrics, Windows Hello, or a device PIN. And because Apple, Google, and Microsoft now sync passkeys across devices inside their ecosystems, adoption gets easier. It also gets messier: one user can have multiple passkeys on multiple devices, and your product needs clean ways to name them, manage them, and revoke them when a phone goes missing.
Implementation details matter. Aplatform authenticator(built into a phone or laptop) doesn’t carry the same risk profile as an external hardware key. Security teams chasing high assurance often prefer certified hardware keys because they reduce exposure to software compromise. Either way, WebAuthn integrations live or die on correct configuration: origin checks, relying party ID, attestation policy, and secure storage of public keys and metadata.
FIDO2 at work: hardware keys vs. phones, and why “easy” can bite you
In the enterprise, FIDO2 isn’t a shiny UX upgrade, it’s a security policy weapon. The goal is to cut down account takeovers, phishing-driven compromises, and the support costs that come with them. When authentication is cryptographic and bound to the real service, a big chunk of credential-reuse and phishing risk gets chopped off at the knees.
The first fork in the road:hardware security keys(USB/NFC) versusmobile authenticators. Hardware keys are tangible and controllable, you can inventory them, assign them, replace them, and require them on shared workstations. Phones are already in everyone’s pocket and come with built-in biometrics, which users tolerate far better. But phones drag in dependencies: MDM policies, device refresh cycles, and the uncomfortable reality of backups and synced credentials living in consumer ecosystems.
The second fork: assurance level. You might demand phishing-resistant authentication for admins, VPN access, finance tools, and cloud consoles, while letting lower-risk apps use something less strict. That split has to be explicit and documented. Treating your payroll system like the cafeteria menu is how you end up in incident-response hell.
And then there’s the part everyone tries to hand-wave away:recovery. Lost key. Smashed phone. New laptop. Employee departure. If you don’t have a real process for each scenario, people will “solve” it with weak resets, sloppy backup codes, or a help desk that can be sweet-talked. The smarter play: require a second strong method at enrollment, lock down support-driven resets, and log identity events so your detection team can spot weird behavior.
Where passkeys fit with SSO: they don’t replace SAML or OIDC, they replace passwords
Most web apps don’t authenticate users in isolation. They sit behindSSO, where an identity provider (IdP) handles login and then vouches for the user to other apps. Two protocol families dominate:SAML 2.0(common in older enterprise setups) andOpenID Connect(OIDC, built on OAuth 2.0, the default for modern apps and APIs).
Passkeys don’t replace SAML or OIDC. They replace thelogin methodused by the IdP (or by the app if it runs its own authentication). The cleanest, most defensible model is passkeys at the IdP: authenticate once with WebAuthn, then the IdP issues SAML assertions or OIDC tokens to downstream apps. Centralized policy, centralized logging, fewer homegrown auth implementations to screw up.
The other model, common in consumer products, is the app integrating WebAuthn directly and managing passkeys itself. You get tighter control over UX and less reliance on an external IdP. You also inherit the hard stuff: account lifecycle, fraud detection, compliance, recovery flows, and maintaining security libraries over time. If your team can’t operate identity as a long-term discipline, this path gets expensive fast.
Also: strong login doesn’t save you from sloppy session security. If cookies aren’t protected, tokens live too long, or you don’t detect compromised devices, attackers will just steal sessions instead of passwords. Migrating to WebAuthn without tightening session policies is like installing a steel front door and leaving the back window open.
The product reality: enrollment timing, account recovery, and the metrics that tell the truth
Passkeys succeed or fail in the product details. Enrollment has to happen at the right moment, usually after a successful sign-in, explained in plain English: what’s stored, where it lives, and how the user gets back in if they switch devices. Don’t force it too early. But don’t bury it, either.
You also need multi-device hygiene: allow multiple passkeys per user, let people label devices, and make revocation dead simple when something is lost.
Recovery is the classic faceplant. Plenty of “passwordless” systems quietly fall back to email or SMS, and that’s where attackers go hunting. SMS is vulnerable to hijacking; email is only as secure as the inbox. A sturdier approach is requiring a second passkey, a backup hardware key, or a tightly controlled recovery process with identity verification matched to risk. In corporate settings, that often means an ITSM workflow with identity checks and manager approval for sensitive accounts.
Compatibility is another landmine. WebAuthn support isn’t uniform across every environment, especially on older browsers or locked-down machines. You may need a fallback during transition, but keep it on a leash. A common approach: keep passwords temporarily, require WebAuthn for the most critical access first, then phase passwords out as support tickets and device compatibility stabilize.
If you don’t measure it, you’re guessing. Track passkey activation rates, the share of logins done via WebAuthn, account reset volume, average help-desk resolution time, and failure rates by browser and platform. Those numbers help you balance usability and security, and they can tip you off to attacks, like a sudden spike in failures tied to a region or a recovery flow.
Hard truths: attestation trade-offs, social engineering, and the portability problem
WebAuthn’s domain-binding gives you structural anti-phishing benefits, but configuration still matters.Attestationis a touchy one: requiring hardware attestation can help enterprises restrict which authenticators are allowed, but it can also complicate UX and raise privacy concerns. Many services choose a looser attestation policy and lean on metadata lists and IdP-side controls instead.
And no, passkeys don’t magically stop fraud. They won’t prevent a user from approving a malicious action if the UI tricks them, and they won’t stop malware from abusing an already-open session. Attackers adapt: if login phishing gets harder, they’ll hammer recovery flows or con the help desk. Security stays layered, session protection, anomaly detection, device controls, and extra friction around high-risk changes like swapping an email address or phone number.
Portability is another headache. Synced passkeys make life easier for users, but they rely on ecosystem-specific backup and sync systems. For organizations, that’s a control question: what happens when an employee leaves, changes devices, or mixes personal and work accounts? The strictest shops push managed authenticators or require passkeys tied to corporate profiles.
The organizations that pull this off have a doctrine: which accounts go first, which flows must be phishing-resistant, what recovery methods are allowed, and what proof is required to recover access. Without that, “passwordless” turns into a pile of exceptions, and the password you meant to kill sticks around forever.