WebAuthn vs. CTAP vs. FIDO2: Key Differences

1. Introduction#

Developers building passwordless authentication frequently encounter three terms - WebAuthn, CTAP and FIDO2 - and confuse their boundaries. This article explains what each one does, how they relate and where each sits in the authentication stack.

The goal: after reading this, you should know exactly which layer you interact with as a developer and which layers the OS handles for you.

2. TL;DR: Key Takeaways#

The one-line summary: FIDO2 = WebAuthn + CTAP. WebAuthn is what you code against. CTAP is what the OS handles under the hood to talk to security keys and biometric modules. The diagram below illustrates how the three layers connect.

3. What is FIDO2?#

FIDO2 is not a protocol or API. It is an authentication framework created by the FIDO Alliance and the W3C to replace passwords with phishing-resistant, public-key cryptography.

FIDO2 encapsulates two specifications:

• WebAuthn (Web Authentication): W3C standard defining the API relying parties use to interact with client devices
• CTAP (Client-to-Authenticator Protocol): FIDO Alliance protocol defining how a client device communicates with an authenticator

The power of FIDO2 lies in architectural decoupling. A relying party does not need to know hardware details. Whether a user taps an NFC smartcard, plugs in a USB token or scans a fingerprint, the relying party communicates uniformly via WebAuthn. The OS handles CTAP translation. As new authenticator types emerge, relying parties need no code changes.

4. What is WebAuthn?#

WebAuthn is the standardized API through which applications request creation and verification of public-key credentials. Originally designed for browsers by the W3C, it now serves as the universal data model for FIDO2 credentials across all platforms - including native iOS and Android apps.

4.1 Registration and Authentication Ceremonies#

WebAuthn defines two ceremonies:

Registration: The relying party calls navigator.credentials.create(). The authenticator generates a public-private key pair bound to the relying party's domain. The private key never leaves the authenticator. The public key is returned to the server. For details on server-side handling see our WebAuthn server implementation guide. Authentication: The relying party calls navigator.credentials.get(). The authenticator signs a cryptographic challenge with the private key. The server verifies the signature using the stored public key - no shared secrets ever cross the network.

4.2 Phishing Resistance via Domain Binding#

Credentials are bound to the domain (rpID) that created them. If a user visits a phishing site, the client refuses to use credentials generated for the legitimate domain. This makes WebAuthn inherently phishing-resistant - something passwords and OTPs cannot achieve. For a deep dive on origin validation see our WebAuthn origin validation guide.

5. What is CTAP?#

CTAP is the binary protocol between a client device (laptop, phone) and a physical authenticator (security key, platform biometric module). It is transported over USB, NFC and BLE.

App developers rarely touch CTAP. It is the domain of OS vendors, browser vendors and hardware security key manufacturers.

5.1 CTAP Versions#

5.2 Transport Modalities#

• USB HID: most direct, lowest latency
• NFC: tap-to-authenticate, popular in fintech and smartcard deployments
• BLE: used in cross-device flows for proximity verification. The actual cryptographic payload travels over an encrypted cloud tunnel, not BLE itself

For more on transport handling see our WebAuthn transports guide.

6. Side-by-Side Comparison#

7. How a Passwordless Ceremony works end-to-end#

The following sequence diagram shows how WebAuthn and CTAP interact during a FIDO2 authentication. Each step handed off between the four entities.

WebAuthn and CTAP are not alternatives. They are sequential steps in the same chain.

8. Platform vs. Roaming Authenticators#

Platform authenticators are built into the device (Face ID, Windows Hello). No external CTAP transport is needed. Passkeys primarily use platform authenticators and can sync across devices via iCloud Keychain or Google Password Manager.

Roaming authenticators are external hardware (USB/NFC security keys, smartcards) - the exclusive domain of CTAP. Private keys cannot be synced, satisfying strict compliance requirements. They also serve as un-phishable backup for account recovery.

Relying parties control the form factor via the authenticatorAttachment property: platform for biometrics or cross-platform for hardware keys.

9. Common Misconceptions#

9.1 WebAuthn is only for browsers, CTAP is for native apps#

Both web and native apps use the WebAuthn abstraction. On Android, the Credential Manager API accepts WebAuthn-formatted payloads. On iOS, ASAuthorizationController does the same. The OS handles CTAP internally when a hardware key is involved. The developer writes zero CTAP code in either case.

9.2 FIDO2 and WebAuthn are the same thing#

FIDO2 is the umbrella; WebAuthn is one half of it. Saying "FIDO2" when you mean "WebAuthn" conflates the application-layer API with the full standard (which also includes CTAP).

9.3 You need CTAP to support passkeys#

Passkeys (synced discoverable credentials) primarily use platform authenticators where no external CTAP transport is involved. CTAP only comes into play with roaming hardware authenticators. Most passkey implementations never touch CTAP directly.

9.4 Direct CTAP integration gives better native UX#

The opposite is true for most apps. OS platform APIs provide consistent, familiar UI dialogs and enable synced passkeys. Direct CTAP bypasses the OS credential manager - losing cloud sync and forcing you to build custom UI and handle CBOR/APDU encoding. It is only justified in high-assurance environments (e.g. banking with hardware-bound-only credentials). The decision tree below helps determine which path fits your use case.

10. How Corbado can help#

Corbado operates as a passkey adoption and observability layer on top of your existing identity provider - without replacing it. In the FIDO2 architecture, Corbado sits between the relying party and end user, handling WebAuthn complexity across browsers, iOS and Android.

Telemetry on WebAuthn/CTAP flows:

• Enrollment funnel analytics: drop-off by device, OS, browser and nudge attempt
• Ceremony-level debugging: trace exactly which WebAuthn/CTAP step fails per user
• Cross-device journey tracking: understand how users move between platform and roaming authenticators
• Error classification: distinguish user aborts from real failures from device incompatibilities

Adoption intelligence: Device-aware enrollment timing, automatic credential healing, gradual rollout with kill switch and A/B testing. For a full overview see our passkey rollout guide.

11. Conclusion#

FIDO2 is the umbrella framework. WebAuthn is the API you code against for credential creation and assertion - across both web and native apps. CTAP is the hardware protocol the OS uses to communicate with authenticators - you almost never touch it directly.

Understanding these boundaries eliminates the most common implementation mistakes and lets you focus on what matters: building a frictionless, phishing-resistant login experience.