FIDO2 and Passkeys: Benefits, Options, and How to Assess Them

Every phishing kit sold on Telegram has one thing in common: it works because your users have a secret to give away. A password, a one-time code, a push they can approve under pressure — all of it is shared knowledge that can be relayed, replayed, or fatigued out of a person. FIDO2 breaks that model. This is a working guide to what FIDO2 and passkeys actually are, the options you have to choose between, and a concrete checklist for assessing them before you roll them out.

What FIDO2, WebAuthn, and CTAP actually are

“FIDO2” is an umbrella for two specifications that work together. WebAuthn is the W3C browser API that a website (the relying party, or RP) calls to register and authenticate an authenticator. CTAP (Client to Authenticator Protocol, from the FIDO Alliance) is the protocol that lets an external authenticator — a security key over USB, NFC, or Bluetooth — talk to the browser or operating system. A passkey is simply a FIDO2/WebAuthn credential used as a login factor, marketed under a friendlier name.

The mechanism is ordinary public-key cryptography, applied carefully. When a user registers, the authenticator generates a fresh key pair scoped to that one website. The private key never leaves the authenticator hardware; only the public key is sent to the RP and stored against the account. At login, the server sends a random challenge, the authenticator signs it with the private key, and the server verifies the signature against the stored public key. There is no shared secret in transit, at rest on the server, or anywhere a database dump could expose.

Why it is phishing-resistant, and OTP and push are not

The property that matters most is origin binding. The browser and authenticator bind every credential to the exact origin that created it — scheme, host, and port. A signature produced for login.yourbank.com is cryptographically useless to login-yourbank.evil.com, and the authenticator will simply refuse to produce one for the wrong origin. The user cannot be tricked into “handing it over” because there is nothing hand-over-able and the browser enforces the target for them.

Contrast the legacy factors:

• OTP (TOTP/SMS): a short-lived shared secret the user reads and types. A phishing proxy simply relays it to the real site in real time. The code is valid wherever it is entered.
• Push approval: vulnerable to MFA fatigue — bombard someone at 2 a.m. and one tap ends it — and to real-time relay of the prompt.
• FIDO2: no code to read, no secret to type, no prompt to approve against the wrong site. The signature is bound to the origin, so an attacker-in-the-middle has nothing to forward.

The benefits over OTP and push follow directly: genuine phishing resistance rather than phishing friction, no shared secrets to steal or leak, no fatigue-based social engineering, and a materially better user experience — a touch or a glance instead of a code copied from another device.

Option 1: platform authenticators vs roaming security keys

A platform authenticator is built into the device: Windows Hello, Face ID and Touch ID on Apple devices, and the Android biometric/screen-lock authenticator. It is convenient, always present, and unlocked by a biometric or PIN. Its weakness is that it is tied to that one device — lose or replace the device and the credential is gone unless it is synced.

A roaming authenticator is a separate hardware security key — YubiKey, Feitian, Google Titan, and similar — that connects over USB, NFC, or BLE. It is portable across machines, hard to clone, and can be issued and inventoried like any other asset. It is also an extra object to buy, distribute, and replace when lost. For high-assurance populations the roaming key is usually the right primary; for the broad workforce, platform authenticators drive adoption because there is nothing to carry.

Option 2: device-bound vs synced passkeys

This is the distinction that most often trips up enterprise buyers. A device-bound credential’s private key never leaves the authenticator that created it — classic hardware-key behaviour. A synced passkey is copied, end-to-end encrypted, into a cloud keychain (Apple iCloud Keychain, Google Password Manager, or a third-party password manager) so it appears automatically on the user’s other devices.

Synced passkeys are a huge usability win and the reason passkeys have gone mainstream: users no longer get locked out when they replace a phone. But the trade-off is real. The assurance of a synced passkey is only as strong as the cloud account and its recovery flow — and that recovery flow can, if you are not careful, become the phishable path you were trying to eliminate. Sync also means the credential can be shared (AirDrop, a shared password vault), which conflicts with “one identity, one key.” For your highest-risk accounts you generally want device-bound keys where you can prove the key lives in certified hardware and cannot be copied out.

Option 3: attestation and AAGUID

Attestation is a signed statement, produced during registration, about the authenticator’s make and security properties. The AAGUID (Authenticator Attestation GUID) is a 128-bit identifier for the authenticator model. Together they let an RP answer “what kind of authenticator is this, and do I trust it?” — for example, allowing only certified hardware keys from an approved vendor list for privileged accounts, and blocking unknown or software authenticators. Note that many platform authenticators and synced passkeys return no meaningful attestation (or a privacy-preserving one), so an attestation-and-AAGUID restriction policy effectively becomes a hardware-key policy. Decide that deliberately.

Option 4: resident (discoverable) vs non-resident credentials

A resident or discoverable credential stores enough state on the authenticator that the user can be identified without first typing a username — this is what enables true usernameless, passwordless login. A non-resident credential stores nothing on the authenticator; the RP must supply the credential ID (typically after the user enters a username), and the authenticator merely signs. Discoverable credentials give the best UX and are required for passkey-style flows, but they consume limited storage slots on hardware keys and mean anyone with the unlocked key can enumerate accounts — so pair them with a PIN or biometric (user verification).

Assessment criteria: how to choose and deploy

Use this as a decision checklist when evaluating vendors, IdPs, and your own rollout plan:

• Attestation & key-restriction policy: can you require attestation and allow-list specific AAGUIDs for privileged roles? Confirm your IdP actually enforces it, not just collects it.
• Device-bound vs synced by population: mandate device-bound, certified hardware keys for admins, finance, and other high-assurance accounts; permit synced passkeys for the general workforce to drive adoption.
• Certification level (FIDO L1/L2): require at least FIDO Certified L1; prefer L2 (hardware tamper resistance) for keys protecting privileged access. Map the certification to the AAGUIDs you allow.
• Account-recovery strategy: this is where most passkey programmes fail. Never let recovery fall back to SMS, email magic links, or a knowledge question — that recreates a phishable path around your phishing-resistant factor. Register at least two authenticators per user, or use enterprise-managed recovery (help-desk with identity proofing, or a securely stored backup key).
• RP / IdP support: verify WebAuthn support across your IdP, critical SaaS apps, and VPN. Check whether federation (SSO) lets one strong login cover downstream apps, and where gaps force a weaker fallback.
• Enrollment & lifecycle: plan supervised enrollment (so you bind a key to a verified identity, not an attacker’s), self-service addition of a second key, and prompt de-provisioning on offboarding. Track keys as inventoried assets.
• Resident vs non-resident and user verification: require user verification (PIN or biometric) so a stolen key alone is not a credential; choose discoverable credentials where usernameless UX matters.
• Where to phase in first: start with the accounts an attacker wants most — domain and cloud admins, IT, finance, executives — then high-risk teams, then the broad workforce. A phishing-resistant factor on 200 admins beats a weak factor on everyone.

A pragmatic rollout order

Do not try to reach 100% coverage in one program. Prove the mechanics on your highest-value accounts with device-bound hardware keys and enterprise recovery, kill their phishable fallbacks entirely, then extend synced passkeys to the general population where the recovery risk is acceptable and the adoption benefit is largest. Measure success not by enrollment percentage but by how many accounts still have a phishable factor you could remove.

Frequently asked questions

Are synced passkeys safe enough for enterprise use? For most of your workforce, yes — they are dramatically stronger than passwords or OTP and they solve the lockout problem that stalls adoption. For high-assurance accounts (admins, finance, executives), prefer device-bound keys in certified hardware, because a synced credential’s assurance is bounded by the cloud account and its recovery flow.

What stops a phishing site from using a passkey? Origin binding. The browser and authenticator bind every credential to the exact origin that created it, and will not produce a signature for a look-alike domain. There is no code or secret to relay, so an attacker-in-the-middle proxy has nothing to forward to the real site.

Do I still need passwords or a fallback? The goal is to remove phishable factors, not add to them. Register two authenticators per user and use enterprise-managed recovery instead of SMS, email links, or security questions — those fallbacks recreate exactly the weakness you deployed passkeys to close.

What is attestation and when do I care? Attestation is a signed statement about the authenticator’s model and security properties, identified by its AAGUID. You care when you want to restrict privileged accounts to specific certified hardware keys; for the general workforce you can usually skip strict attestation to keep enrollment friction low.

Where should we deploy passkeys first? Start with the accounts attackers target most — domain and cloud administrators, IT, finance, and executives — using device-bound keys, then expand to other high-risk teams, then the broad workforce. Coverage of your most privileged users matters more than headline enrollment numbers.