FIDO2 is the open authentication standard that replaces the password with public-key cryptography and makes passkeys and phishing-resistant MFA possible. It is developed by the FIDO Alliance and the W3C, and by 2026 it is the technical foundation that Apple, Google, Microsoft and virtually every identity provider rely on to remove the shared secret, the weakest link in traditional authentication. When a user registers a passkey or taps a security key, FIDO2 is doing the work underneath.
This guide explains what FIDO2 is, its two components (WebAuthn and CTAP), how passkeys are built on top of it, why it is phishing-resistant compared with TOTP, SMS and push, which hardware security keys exist and how to run an enterprise rollout without getting stuck on account recovery.
Key takeaways on FIDO2
- FIDO2 is not a product, it is an open standard made of WebAuthn (the browser API) and CTAP (the authenticator protocol).
- It is based on public-key cryptography: the secret (the private key) never leaves the device or travels over the network.
- It is phishing-resistant because the signature is bound to the origin (domain), so it does not work on a spoofed domain.
- Passkeys are discoverable FIDO2 credentials, either synced across devices or bound to hardware.
- It aligns with NIS2, ISO 27001 A.5.17, ENS and AAL3 of NIST SP 800-63B, and it is the MFA that CISA recommends against adversary-in-the-middle attacks.
What FIDO2 is
FIDO2 is a passwordless authentication framework built on cryptographic key pairs. At registration, the authenticator (your phone, your laptop or a hardware key) generates a unique key pair for that service: the private key stays in the device, protected by secure hardware (Secure Enclave, TPM, the key's secure element), and the public key is sent to the server, which stores it against your account.
On every sign-in the server sends a random challenge. The authenticator signs it with the private key, after verifying the user (fingerprint, face or PIN), and returns the signature. The server validates it with the public key it stored. No reusable secret is ever transmitted, so there is nothing to steal in transit, nothing to leak in a database breach and nothing to replay in a credential stuffing attack.
This design is what separates FIDO2 from the password and from the traditional second factor: security does not depend on the user choosing a long secret or on the server storing it well, but on a mathematical property and on physical control of the device.
FIDO2 = WebAuthn + CTAP
FIDO2 is best understood as the sum of two specifications that work together.
WebAuthn: the browser API
WebAuthn (Web Authentication) is the W3C recommendation that exposes FIDO2 authentication to web applications. It is a JavaScript API (navigator.credentials.create() to register and navigator.credentials.get() to authenticate) implemented natively in Chrome, Safari, Firefox and Edge. The server (called the relying party in the spec) sends its parameters, the browser orchestrates the interaction with the authenticator and returns a signed assertion.
Here is the key to phishing resistance: WebAuthn binds each credential to the rpId, the relying party's domain identifier. The signature is only produced for the legitimate origin. WebAuthn supports two authenticator types: platform (built in, such as Touch ID, Windows Hello or the phone sensor) and roaming (external, such as a YubiKey over USB or NFC).
CTAP: the authenticator protocol
CTAP (Client to Authenticator Protocol), in its current version CTAP2, is the protocol that lets the browser or operating system talk to an external authenticator over USB, NFC or Bluetooth. It is what allows a hardware key plugged in over USB-C, or your phone used as a proximity key, to take part in the WebAuthn flow.
The mental model is simple: WebAuthn talks to the browser, CTAP talks to the authenticator. Together they form FIDO2. A platform authenticator can resolve everything internally without CTAP; a roaming authenticator needs CTAP as the bridge. Signatures use COSE algorithms such as ES256 (ECDSA with P-256) or EdDSA, negotiated during registration.
How passkeys are built on FIDO2
A passkey is, technically, a discoverable FIDO2 credential (formerly called a resident key): the key is stored on the authenticator along with account metadata, so the user does not need to type a username. The device already knows which credential to offer for each site.
Passkeys split into two families worth distinguishing in an enterprise design:
- Synced passkeys: replicated in encrypted form across the user's devices through iCloud Keychain, Google Password Manager or a manager such as 1Password or Bitwarden. Convenient for consumers and SMEs, because they survive the loss of a phone.
- Device-bound passkeys: the key never leaves the hardware. This is the model of hardware keys and the one high-security use cases demand, because the "something you have" factor is literal.
Each credential carries an AAGUID identifying the authenticator model, a credential ID and optionally an attestation proving which vendor it came from. Attestation is what lets a company require that only approved authenticators be registered, a decisive control in regulated environments.
Why FIDO2 is phishing-resistant
Traditional MFA adds a second factor, but many of those factors are still secrets the user can hand to an attacker by mistake. FIDO2 removes that possibility at the root.
| Factor | Shared secret | Vulnerable to phishing/AiTM | Bound to origin |
|---|---|---|---|
| SMS OTP | Yes (code) | Yes, plus SIM swapping | No |
| TOTP (Google Authenticator) | Yes (seed and code) | Yes, can be replayed into a proxy | No |
| Push approval | Yes (the approval) | Yes, MFA fatigue and AiTM | No |
| FIDO2 / passkey | No | No | Yes (rpId) |
Three properties explain the difference. First, there is no shared secret: there is no code the user can read and paste into a fake site. Second, the credential is bound to the origin: even if the user lands on a spoofed domain, the authenticator will not sign for that domain, so an adversary-in-the-middle kit like Evilginx gets nothing usable. Third, it is resistant to adversary-in-the-middle (AiTM) attacks that today defeat push and TOTP by stealing the session cookie, because there is no challenge a proxy can successfully relay to a different origin.
That is why CISA classifies FIDO2 as the only truly phishing-resistant MFA and ranks it above TOTP and push. It is also the natural way to implement strong verification in a Zero Trust architecture, where identity is the new perimeter.
FIDO2 security keys: the hardware
When the requirement is maximum security or strict compliance, the option is a FIDO2 security key: a dedicated physical device that acts as a roaming authenticator over CTAP2. The market references in 2026:
- YubiKey 5 (Yubico): the most widespread in the enterprise. USB-A, USB-C, NFC and Lightning form factors. Supports FIDO2/WebAuthn, plus PIV (smart card), OpenPGP and TOTP on the same device.
- Google Titan Security Key: FIDO2 over USB-C and NFC, good price-to-performance for broad rollouts.
- Feitian and Token2: competitive alternatives with biometric form factors and lower-cost variants for equipping large workforces.
For enterprise design, the practical rule is to issue two keys per critical user: one for daily use and one backup stored safely. This solves the recovery problem that usually derails projects before it starts. Keys are immune to endpoint malware (the private key never leaves the secure element) and to cloning, which makes them the strongest "something you have" factor available, comparable in assurance to a smart-card certificate backed by a PKI.
Enterprise rollout: roadmap and recovery
A FIDO2 rollout in an organisation rests on the identity provider. Microsoft Entra ID, Okta, Ping and Google Workspace support WebAuthn natively, and folding it into your identity and access management is usually a matter of policy, not re-engineering.
A realistic phased roadmap:
- Pilot with administrators and privileged accounts. They are the most valuable target and where an adversary-in-the-middle attack hurts most. Start with device-bound hardware keys.
- Registration with mandatory attestation. Configure the policy to accept only approved authenticators (by AAGUID) on sensitive accounts. Lean on the FIDO Metadata Service.
- Passkeys for the bulk of the workforce. Platform passkeys (Windows Hello, Touch ID) for daily work, with conditional access requiring a phishing-resistant factor on critical resources.
- Gradual retirement of weak factors. Remove SMS and, once coverage is enough, TOTP. Strong MFA sitting next to an SMS fallback drops to the level of the weakest link.
The point that sinks projects is recovery. If a user loses their only authenticator and the only recovery path is an SMS or a security question, you have reintroduced exactly the vector you meant to remove. Design recovery ahead of time: mandatory registration of two authenticators per user, custodied backup keys, and for edge cases a service-desk-assisted process with reinforced identity verification, not a simple reset email.
Frequently asked questions
Do passkeys replace passwords?
That is the direction, but the transition takes years. A passkey offers far greater security (no shared secret, phishing-resistant, device-bound) and a better experience, and on many services it can already be the only method. Passwords still coexist, though, due to legacy application inertia and recovery cases. The reasonable goal in 2026 is passkey first where possible and password only as a fallback where there is no alternative.
What is the difference between FIDO2 and WebAuthn?
WebAuthn is a part of FIDO2, not a synonym. FIDO2 is the full standard and is made of two pieces: WebAuthn, the API used by the browser and the web application, and CTAP2, the protocol connecting the client to an external authenticator. When someone says "sign in with WebAuthn" they mean the flow visible in the browser, but underneath, if a hardware key is involved, CTAP is also at work.
Is FIDO2 MFA?
Yes, and among the strongest. A FIDO2 authentication combines "something you have" (the authenticator with its private key) and "something you are or know" (the user verification through biometrics or a PIN that unlocks the key). That satisfies the definition of multi-factor in a single gesture and reaches AAL3 of NIST SP 800-63B, the highest level, something neither SMS nor TOTP achieves.
Is a synced passkey less secure than a hardware key?
It has a different threat model. A synced passkey is more convenient and survives the loss of a device, but its security depends on the cloud account that replicates it (iCloud, Google). A device-bound hardware key never syncs, so it demands a physical backup but removes the cloud-provider risk. For privileged accounts and regulated environments, device-bound hardware remains the recommendation.
Does FIDO2 work without a connection to the identity server at every step?
The authenticator operates locally: it generates and custodies the key and signs the challenge without depending on external services beyond the server that issues the challenge. This makes it robust against third-party service failures and removes dependencies such as receiving an SMS, which can fail due to coverage or SIM swapping.
Related resources
- What Is IAM: identity and access management for enterprise
- What Is Zero Trust: architecture, principles and practical implementation
- What Is Credential Stuffing: password reuse attacks
- What Is PKI (Public Key Infrastructure)
- What Is SAML 2.0: SSO flow, OAuth/OIDC and vulnerabilities
FIDO2 at Secra
At Secra we help B2B organisations design and deploy phishing-resistant authentication without breaking operations. We assess your identity stack, define the passkey and hardware-key model by criticality, solve recovery before it becomes a problem and align everything with your regulatory framework (NIS2, ENS, ISO 27001). If your organisation wants to retire SMS and TOTP and adopt FIDO2, get in touch with Secra or review our GRC consulting services.
About the author
Secra Solutions team
Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.

