FIDO2 is an open authentication standard that replaces or strengthens passwords with public-key cryptography, combining the W3C Web Authentication (WebAuthn) API with the FIDO Alliance’s Client to Authenticator Protocol (CTAP). In cybersecurity, and specifically in identity and access management, it provides phishing-resistant authentication: a security key, phone or laptop proves possession of a private key bound to one specific website, and no shared secret ever travels to the server.
FIDO2 can serve as a strong second factor in MFA or as a complete passwordless login, when the authenticator also verifies the user locally with a PIN or biometric. Passkeys, the consumer-facing name for discoverable FIDO2 credentials, are built on exactly this standard.
How FIDO2 authentication works
FIDO2 relies on a unique key pair for every account on every service. During registration, the authenticator generates a new private key that never leaves the device and sends only the public key and a credential ID to the website, called the relying party. During login, the site sends a random challenge, and the authenticator signs it with the private key.
| Step | Ceremony | What happens |
|---|---|---|
| 1 | Registration | Relying party sends a challenge, its RP ID and user details |
| 2 | Registration | Authenticator verifies the user and creates a key pair for that RP ID |
| 3 | Registration | Server stores the public key, credential ID and optional attestation |
| 4 | Authentication | Server sends a fresh challenge and acceptable credential IDs |
| 5 | Authentication | Authenticator checks presence or verification and signs the data |
| 6 | Authentication | Server verifies the signature, origin, RP ID hash and flags |
The signed data includes a hash of the client data, which contains the challenge and the web origin reported by the browser, plus authenticator data with the hash of the RP ID and flags for user presence (UP) and user verification (UV). Because the browser, not the user, supplies the origin, a look-alike phishing domain receives a signature that the real server will reject.
WebAuthn, CTAP and the FIDO2 components
FIDO2 is a combination of two specifications that cover different links in the chain. WebAuthn connects the website to the browser or operating system; CTAP connects the browser or operating system to an external authenticator over USB, NFC or Bluetooth.
| Component | Maintained by | Role |
|---|---|---|
| WebAuthn | W3C | JavaScript API for creating and using credentials |
| CTAP2 | FIDO Alliance | Protocol between client and roaming authenticator |
| CTAP1 (U2F) | FIDO Alliance | Older second-factor protocol, still supported |
| Relying party | The service operator | Stores public keys and verifies assertions |
| Authenticator | Device or platform vendor | Generates keys, verifies the user, signs |
Authenticators come in two forms. Roaming authenticators, such as USB or NFC security keys, move between devices. Platform authenticators are built into a laptop or phone and protect keys with a TPM or secure enclave, unlocked by Windows Hello, Touch ID or an Android screen lock. A phone can also act as a roaming authenticator for a nearby computer through the hybrid transport, which pairs over a QR code and confirms physical proximity via Bluetooth.
Credentials can be discoverable (resident), stored with the user handle on the authenticator so that login works without typing a username, or non-discoverable, where the server must supply the credential ID first. Common signature algorithms are ES256 (ECDSA with P-256), EdDSA and RS256, identified by COSE algorithm numbers.
FIDO2 compared with other authentication factors
The defining advantage of FIDO2 is resistance to phishing and server breaches. Codes and push approvals can be relayed by a real-time phishing proxy, and stored password hashes can be cracked after a leak; a FIDO2 public key is useless to a thief and a signature is valid only for the correct origin.
| Method | Phishing resistant | Server breach impact | Main weakness |
|---|---|---|---|
| Password only | No | Hashes can be cracked | Reuse and guessing |
| SMS code | No | Low | SIM swapping and interception |
| TOTP app | No | Shared seeds can leak | Real-time phishing relay |
| Push approval | Partly, with number matching | Low | Prompt bombing fatigue |
| FIDO2 security key | Yes | Public keys only | Loss of the device |
| Synced passkey | Yes | Public keys only | Depends on cloud account security |
Hardware-bound FIDO2 authenticators with user verification can meet the highest assurance level (AAL3) in NIST SP 800-63B guidance, while synced passkeys are generally treated as strong but less tightly controlled, because the private key is copied between devices through a provider’s cloud.
Deploying FIDO2 in an organization
A successful rollout depends less on cryptography than on enrollment and recovery processes. Identity providers for SSO, operating systems and major browsers support FIDO2 natively, so the main decisions concern authenticator types, policies and fallback paths.
| Situation | Recommended choice | Reason |
|---|---|---|
| Administrators and privileged roles | Two hardware security keys each | Device-bound keys and a backup |
| General workforce on managed laptops | Platform authenticators | No extra hardware to distribute |
| Shared or kiosk workstations | Roaming keys with PIN | Credentials move with the person |
| Strict supply-chain control | Require attestation from approved models | Blocks unknown or cloned authenticators |
| Consumer accounts | Synced passkeys | Usability and built-in recovery |
The weakest point is often the account recovery path. If a lost key can be replaced through a help desk call answered with personal details, attackers will target that process instead. Organizations should require at least two registered authenticators and make recovery as strong as the primary login.
Common pitfalls and misconceptions
- FIDO2 does not send biometrics to the server; fingerprints and faces only release the key locally.
- The RP ID must be set deliberately, because credentials registered for one domain do not work on an unrelated one.
- Signature counters can stay at zero for synced passkeys, so servers must not treat a static counter as cloning.
- Keeping a password fallback for every account leaves the old phishing path open.
- User presence is not user verification; a tap proves a human is present, while a PIN or biometric proves who it is.
FIDO2 also protects only the authentication step. Session cookies issued after login can still be stolen by malware, so phishing-resistant sign-in should be combined with short session lifetimes and device security.
The short version
With FIDO2, a person logs in with a device instead of a secret word: a small USB key, a phone or the fingerprint reader on a laptop. The device holds a private key made for that one website and proves it has it without ever revealing it.
Because the key works only for the real website, a fake page that looks identical gets nothing useful. It is like a house key that refuses to turn in any lock except the one on the owner’s own front door.
Where it makes a difference
A mid-sized engineering firm suffers repeated account takeovers. Attackers send convincing login pages that relay both passwords and six-digit app codes in real time. The security team decides to make FIDO2 mandatory for all 600 employees through the company identity provider.
Staff on managed laptops register platform authenticators with Windows Hello, while administrators receive two hardware security keys each, one kept in a safe. Password-plus-code login is disabled after a three-month transition. In the following year, several phishing campaigns reach inboxes, and some employees even click the links, but no account is taken over, because the fake sites cannot produce a valid signature for the firm’s real domain.