FIDO2: What It Is and Why It Matters

FIDO2 is a phishing-resistant authentication standard that powers modern passkeys and many security keys. Instead of relying on shared secrets like passwords (or one-time codes that users can be tricked into typing), FIDO2 uses public-key cryptography so the private key stays on your device and can’t be reused or “stolen” by a phishing site.

If you’re new to passkeys specifically, start with: What is a passkey?

Definition: What is FIDO2?

FIDO2 is an open standard for strong authentication that enables passwordless and phishing-resistant sign-in using public-key cryptography, typically via:

• a passkey stored on a device (platform authenticator), or
• an external security key (roaming authenticator)

It matters because it replaces shared secrets (passwords and many OTP flows) with per-site cryptographic credentials that are not reusable across sites and are far harder to phish.

How FIDO2 works (WebAuthn + CTAP2)

At a high level, FIDO2 combines:

• WebAuthn: the web standard your browser/OS uses to create and use credentials
• CTAP2: the protocol used to communicate with authenticators (security keys, phones, platform authenticators)

The result is a standardized, interoperable way for a service (the “relying party”) to prove you control a private key—without ever receiving that private key.

1) Registration (enrollment)

When a user sets up FIDO2 on a site/app:

1. The service asks the browser/device to create a credential for that specific site/app.
2. The authenticator generates a new public/private key pair.
3. The public key (and metadata like credential ID; attestation depends on policy) is sent to the service and stored.
4. The private key stays on the authenticator, protected by local user verification (PIN, fingerprint, Face ID, device unlock).

Key property: the credential is scoped to the site origin. A credential created for login.example.com won’t work on login.evil-example.com even if the phishing page looks identical.

2) Authentication (sign-in)

Later, when the user signs in:

1. The service sends a random challenge to the device/browser.
2. The authenticator requests user presence/verification (touch the key, biometric, PIN, device unlock).
3. The authenticator signs the challenge (and context such as origin) with the private key for that site.
4. The service verifies the signature using the stored public key and grants access.

No password is transmitted; no OTP is typed into a webpage; there’s nothing “reusable” for an attacker to capture.

3) Why FIDO2 is phishing-resistant (practically)

FIDO2’s phishing resistance comes from three behaviors:

• Origin binding: WebAuthn ties credentials to the real site origin.
• No shared secret: there’s no password to steal and reuse; no OTP to relay.
• Device-/hardware-backed protection: private keys are protected by secure hardware (often Secure Enclave/TPM/secure element) or a dedicated security key, released only after user verification.

FIDO2 doesn’t eliminate all risk. Attackers may still target:

• session tokens (session hijacking),
• device compromise (malware),
• account recovery (social engineering / weak recovery paths).

Your rollout plan should treat recovery as part of the authentication control, not an afterthought.

Technical notes: simplified message flow

Registration:
Relying Party  -> Browser (WebAuthn) -> Authenticator (CTAP2)
challenge + rpId        createCredential()     generate keypair
Relying Party <- publicKey + credId + attestation (optional)

Authentication:
Relying Party  -> Browser (WebAuthn) -> Authenticator (CTAP2)
challenge + allowList     getAssertion()        sign(challenge, rpId)
Relying Party <- assertion (signature) + credId

Where you’ll encounter FIDO2

FIDO2 is increasingly present across consumer accounts, enterprise SSO, and regulated environments—often labeled “passkeys” or “security key” rather than “FIDO2.”

Consumer and workforce logins (Passkeys)

• Browsers: Chrome, Edge, Safari, and Firefox support WebAuthn.
• Platforms: iOS/macOS, Android, and Windows can store passkeys (platform authenticators). Some ecosystems sync passkeys for usability, which you should include in offboarding and risk modeling.

What to do: For high-risk roles (admins, finance, IT), require phishing-resistant methods and consider passwordless where feasible.

Enterprise SSO and SaaS

Many IdPs and SaaS apps support FIDO2/WebAuthn as:

• phishing-resistant MFA (as a second factor), or
• passwordless authentication (replacing the password factor), or
• step-up authentication for risky sign-ins

What to do: enforce FIDO2 for admin consoles and privileged access, and apply conditional access rules for high-risk sign-in patterns.

Windows, macOS, and endpoint access

• Windows: FIDO2 security keys can often be used for enterprise sign-in (config dependent).
• macOS: passkeys/WebAuthn are common for web app login; local device protections still matter because session theft and device compromise remain in scope.

What to do: keep endpoint security tight (patching, disk encryption, EDR), because FIDO2 reduces credential theft but does not prevent a compromised device from leaking an active session.

For vulnerability tracking and remediation discipline, see: Patch management best practices (practitioner’s guide)

Security keys in audits and compliance

FIDO2 is frequently the most straightforward way to meet “phishing-resistant MFA” expectations because it materially reduces:

• credential stuffing impact,
• SMS OTP risks (SIM swap, call center takeovers),
• OTP phishing/relay attacks.

What to do: document your enrollment, recovery, and revocation workflows. In practice, weak recovery controls are a common bypass for strong cryptography.

Deployment guidance (what to prioritize)

Start with the highest blast radius accounts

Prioritize FIDO2 first for:

• IdP admins and global admins
• cloud console admins
• finance/payments and payroll approvers
• security tooling administrators (SIEM/EDR/email security)

Plan for loss, replacement, and recovery

Your security posture is only as strong as your fallback path.

Recommended baseline:

• require two authenticators for admins (e.g., platform passkey + roaming key),
• restrict recovery to high-assurance options (helpdesk workflow + identity verification, or in-person where possible),
• log and alert on recovery events.

Use a password manager to operationalize passkeys

Passkeys can live on devices, but many organizations and power users benefit from centralized, managed storage and sharing controls in a password manager that supports passkeys.

If you’re standardizing tooling, consider a passkey-capable password manager like 1Password: Try 1Password →

FAQ: Is FIDO2 the same as passkeys?

Not exactly.

• FIDO2 is the overarching standard (WebAuthn + CTAP2) that enables phishing-resistant authentication.
• Passkeys are a user-friendly implementation of FIDO credentials, usually backed by platform authenticators and sometimes synced.

In other words: most passkeys you use today are built on FIDO2/WebAuthn.

Bottom line

FIDO2 materially reduces the most common cause of account takeover: stolen or tricked-out-of-users credentials. If phishing would be catastrophic for an account, prioritize FIDO2 now—then make sure your enrollment and recovery processes don’t undermine the control.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.