FIDO2 WebAuthn: How It Works and Where Passkeys Fit

Microsoft found that people sign in successfully with a passkey 98% of the time, compared with 32% for passwords, according to its passkey UX research. The same post reports that Microsoft blocks 7,000 password attacks every second. Enterprises are moving: in the FIDO Alliance’s State of Passkey Deployment in the Enterprise report, 87% of US and UK decision makers said they were deploying passkeys or in the middle of a rollout.

Every one of those passkeys runs on FIDO2 WebAuthn. So what is FIDO2, and what is WebAuthn? FIDO2 is the FIDO Alliance standard for passwordless, phishing-resistant sign-in, and it has two parts: WebAuthn, the W3C API that browsers and apps use to create and verify credentials, and CTAP, the protocol that lets a device talk to an external authenticator such as a security key. WebAuthn is a part of FIDO2, not an alternative to it.

This guide explains how FIDO2 WebAuthn works, how passkeys fit in, how to manage it in Okta and Microsoft Entra ID, and where it runs into trouble on shared devices.

What Is FIDO2?

What is FIDO2? It is the second generation of standards from the FIDO Alliance, built to replace passwords with public key cryptography. FIDO2 is made of exactly two specifications:

• WebAuthn (Web Authentication): the W3C standard API that websites and apps call to register and verify credentials.
• CTAP (Client to Authenticator Protocol): the FIDO Alliance protocol a phone or computer uses to talk to an external authenticator over USB, NFC, or Bluetooth.

FIDO2 grew out of two earlier FIDO protocols. UAF supported passwordless sign-in on mobile devices, and U2F added a hardware key as a second factor after a password. U2F lives on inside FIDO2 as CTAP1. CTAP2 extended it so a security key could handle passwordless sign-in on its own, with a PIN or fingerprint. Later CTAP versions added cross-device sign-in, where a phone can authenticate a login on a nearby computer.

What Is WebAuthn?

What is WebAuthn? It is the browser-side half of FIDO2: a standard JavaScript API, published by the W3C with the FIDO Alliance, that every major browser supports. A website, called the relying party, uses two calls:

• navigator.credentials.create() to register a new credential.
• navigator.credentials.get() to sign in with an existing one.

The relying party never handles a password or a biometric. It sends a challenge, receives a signed response, and checks the signature against a public key it stored at registration. Native apps use platform APIs on Windows, Android, and Apple devices that follow the same model.

WebAuthn vs FIDO2 vs CTAP: Key Differences

The WebAuthn vs FIDO2 confusion comes from vendors using the terms interchangeably. The pieces fit together like this:

The last two rows settle most WebAuthn vs FIDO2 questions. A developer adding passkeys to a website writes WebAuthn code. CTAP runs underneath when the user reaches for a FIDO2 security key or a phone, and the developer rarely touches it.

How FIDO2 WebAuthn Works

FIDO2 WebAuthn has two ceremonies: registration, which happens once per site, and authentication, which happens at every sign-in.

Registration

• The relying party sends a random challenge and its domain (the relying party ID).
• The browser calls WebAuthn, and the authenticator asks the user to verify with a fingerprint, face, or PIN.
• The authenticator creates a new key pair for that domain only and keeps the private key.
• The public key, plus optional attestation about the authenticator’s make and model, goes back to the server, which stores it with the user’s account.

Authentication

• The relying party sends a fresh challenge.
• The browser passes it to the authenticator along with the domain the user is on.
• After user verification, the authenticator signs the challenge with the private key for that domain.
• The server verifies the signature with the stored public key and starts a session.

The phishing resistance comes from step two. The browser, not the user, reports which domain is asking. A lookalike site has a different domain, so the authenticator has no credential for it and signs nothing. There is also nothing worth stealing from the server, because a public key can’t be used to sign in.

FIDO2 authentication does have a boundary. It protects the moment of sign-in. Once the server issues a session cookie, that cookie can still be stolen by malware on the device, which is why session security after login needs its own controls.

Platform vs Roaming Authenticators

FIDO2 credentials live in one of two kinds of authenticator, and the choice decides where identity is anchored.

Passkeys and FIDO2

Passkeys are FIDO2 credentials. The FIDO Alliance uses “passkey” for any FIDO credential that replaces a password, whether it syncs between devices or stays on one. That includes credentials on a FIDO2 security key, which have been supported since 2019.

The real decision is synced vs device-bound:

Organizations deploying passkeys used a mix of device-bound and synced passkeys. The tradeoff is control: with a synced passkey, part of the security model sits with Apple or Google, outside the organization’s view.

Cross-device sign-in covers the gap when the passkey is on another device. The computer shows a QR code, the user scans it with a phone holding the passkey, and Bluetooth confirms the phone is physically nearby. That proximity check stops a remote attacker from relaying the request.

FIDO2 WebAuthn in Okta and Microsoft Entra ID

Most workforce teams meet FIDO2 WebAuthn inside their identity provider rather than in code. Both major providers let admins decide which passkeys count.

Okta exposes FIDO2 as the FIDO2 (WebAuthn) authenticator. Admins can enroll a FIDO2 security key on a user’s behalf and block synced passkeys for the org. Each user can hold up to 10 WebAuthn enrollments.

Microsoft Entra ID manages it through the Passkey (FIDO2) authentication method and passkey profiles. Each profile sets three rules: whether attestation is enforced, which passkey types are allowed (device-bound, synced, or both), and which authenticator models are allowed by AAGUID. Synced passkeys don’t support attestation, so an organization that requires attested hardware is limited to device-bound passkeys.

Two settings matter most. Enforcing attestation proves the authenticator is a known model. Key restrictions limit sign-in to approved FIDO2 security key models or apps. Both are worth applying to admin and privileged groups first.

Where FIDO2 WebAuthn Breaks on Shared Devices

FIDO2 WebAuthn assumes a familiar picture: one person, one laptop, one phone. Platform authenticators bind the credential to a device and its user profile. Synced passkeys bind it to a personal Apple or Google account. Cross-device sign-in needs a phone in the worker’s pocket. On a manufacturing line, a retail floor, or a warehouse, all three assumptions fail.

• The device can’t vouch for the worker: A kiosk signed in under one shared profile holds one set of platform credentials. Windows Hello on that kiosk proves the kiosk, not which of twenty workers is standing at it.
• Synced passkeys need a personal account: Many frontline workers have no company phone, and organizations rarely want work credentials stored in personal cloud accounts.
• Cross-device sign-in needs a phone: Phones are often banned on the floor or in clean rooms.
• Security keys get shared: A FIDO2 security key per worker solves identity on paper, but keys get lost, swapped between shifts, or left in readers, and typing a PIN with gloves on slows every handoff.

The FIDO Alliance notes that security keys can suit people without smartphones. For frontline teams, the stronger pattern pairs a credential each worker carries, like a badge tap or NFC credential, with a face or palm match. Add fast user switching and presence-based locking so sessions never pass from one worker to the next.

Phishing-resistant sign-in for shared devices. OLOID gives frontline teams passwordless device access with badge, NFC, face, and palm, with no phone required. Book a demo

How to Roll Out FIDO2 Authentication

A FIDO2 rollout succeeds or stalls on decisions made before the first user enrolls.

• Map users to authenticator types: Desk-based staff can use platform passkeys. Admins get device-bound passkeys or FIDO2 security keys. Shared-device workers need credentials tied to the person, not the terminal.
• Start with privileged access: NIST requires a phishing-resistant authenticator at its highest assurance level, AAL3, and admin accounts are where attackers aim first.
• Set passkey policy in the identity provider: Decide on synced vs device-bound per group, enforce attestation where hardware assurance matters, and restrict approved key models.
• Register a backup for every user: A second passkey or security key prevents lockouts when a device is lost.
• Harden recovery: If a lost passkey can be replaced with a phone call and an employee ID, the help desk becomes the weakest point. Require the same assurance for recovery as for sign-in.
• Remove phishable fallbacks: Leaving SMS or passwords enabled as a backup gives attackers a way around FIDO2 WebAuthn. Retire them once enrollment is complete.
• Measure adoption: Track the share of sign-ins using FIDO2 authentication, registration completion by group, and help desk tickets for lockouts.

Bring FIDO2-Grade Security to Frontline Teams With OLOID

FIDO2 WebAuthn set the standard for phishing-resistant sign-in, and passkeys have made it practical for most desk-based users. The harder problem is everyone else: workers who share terminals, carry no company phone, and change shifts every few hours.

OLOID is built for that environment. Workers sign in to shared devices and SSO apps with a badge tap, face, or palm, every session stays tied to one verified person, and access connects to Okta and Microsoft Entra ID. Book a demo to see phishing-resistant MFA running on your shared devices.

Frequently Asked Questions

1. What is the difference between WebAuthn and FIDO2?

WebAuthn is one of the two parts of FIDO2. FIDO2 is the full standard, made of WebAuthn and CTAP. In any WebAuthn vs FIDO2 comparison, WebAuthn handles the website and browser side, and CTAP connects external authenticators such as security keys.

2. Are passkeys the same as FIDO2 WebAuthn?

Passkeys are FIDO2 credentials created and used through WebAuthn. “Passkey” is the user-facing name, and FIDO2 WebAuthn is the standard underneath. Passkeys can be synced across devices or bound to one device or security key.

3. Is FIDO2 authentication phishing-resistant?

Yes. FIDO2 authentication binds each credential to the site’s domain, and the browser reports which domain is asking. A fake site can’t trigger a valid signature. FIDO2 does not stop session cookies from being stolen after sign-in.

4. Do I need a FIDO2 security key?

Not always. Built-in platform authenticators such as Windows Hello and Face ID work without extra hardware. A FIDO2 security key is the better choice for admins, regulated access, and anyone without a personal device to hold a passkey.

5. What is the difference between FIDO and FIDO2?

FIDO refers to the original protocols, UAF and U2F. FIDO2 is the later standard built on WebAuthn and CTAP. U2F continues inside FIDO2 as CTAP1.

6. Can FIDO2 WebAuthn work on shared devices?

It can, with care. Platform and synced passkeys tie identity to a device or a personal account, which breaks down when many workers share one terminal. Shared devices work best with credentials tied to each worker, such as a badge or security key paired with a biometric.