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 application developers code against. CTAP is the protocol used to communicate with external security keys - handled by the OS, browser or a user-space library like libfido2 depending on platform. Platform authenticators like Face ID or Windows Hello do not use CTAP. The diagram below illustrates how the 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 or plugs in a USB token, the relying party communicates uniformly via WebAuthn. The CTAP translation to the hardware is handled by the platform - on Windows/macOS typically by the OS, on Linux often by the browser itself or a user-space library like libfido2. For platform authenticators (Face ID, Windows Hello), CTAP is not involved at all - the OS communicates with the secure element via internal APIs. 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:

1. 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.
2. 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.

5. What is CTAP?#

CTAP is the binary protocol between a client device (laptop, phone) and an external roaming authenticator such as a USB security key or NFC smartcard. It is transported over USB HID, NFC and BLE. CTAP does not govern communication with platform authenticators (Face ID, Windows Hello, Android biometric Keystore) - those use internal OS APIs to access the hardware security module (HSM) directly.

The CTAP host role - the component that sends CTAP commands to the hardware - is implemented differently depending on the platform. On Windows and macOS, the OS platform services typically handle it. On Linux, the browser (Chromium has a built-in FIDO implementation) or user-space libraries like libfido2 manage CTAP transport directly, often requiring udev rules for USB HID access.

App developers rarely touch CTAP. It is the domain of OS vendors, browser vendors and hardware security key manufacturers. If you are a security key or smartcard manufacturer, CTAP is what you implement in firmware: the CTAP2 command handler (authenticatorMakeCredential, authenticatorGetAssertion etc.), cryptographic operations on the microcontroller (key generation, ECDSA signing), credential storage management, PIN/UV handling and the USB HID or NFC transport layer. Open-source examples include SoloKeys and Nitrokey.

5.1 CTAP Versions#

CTAP has evolved significantly. The biggest leap was from CTAP1 to CTAP2, which introduced passwordless authentication. The timeline below shows the progression and what each version unlocked.

For reference, the key capabilities per version:

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 with a roaming authenticator (e.g. USB security key). For platform authenticators (Face ID, Windows Hello), steps 3-4 are replaced by internal OS communication with the secure element - CTAP is not involved.

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, Android Keystore). They communicate with the secure element (e.g. Apple Secure Enclave, TPM) via internal OS APIs - CTAP is not involved. 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. The comparison below summarizes the key differences.

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. When a roaming hardware key is involved, CTAP is handled by the platform - the OS on Windows/macOS, the browser or libfido2 on Linux. The app 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. On mobile (iOS/Android), there is no practical way to bypass the OS credential manager for standard apps - you always go through ASAuthorizationController or Android Credential Manager. Direct CTAP via libraries like libfido2 is primarily a desktop/server-side pattern - used in SSH tools, disk encryption or custom desktop apps. On mobile, the only exception is embedding a specialized vendor SDK (e.g. for NFC smartcard authentication in banking apps) that opens a direct NFC/BLE channel to a specific hardware token, deliberately bypassing synced passkeys for compliance. 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 protocol for communicating with roaming authenticators (security keys, smartcards) - handled by the OS, browser or libfido2 depending on platform. Platform authenticators (Face ID, Windows Hello) do not use CTAP at all.

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

Frequently Asked Questions#

How does a FIDO2 authentication ceremony work end-to-end when using a security key?#

During authentication with a roaming authenticator, the relying party sends a challenge and rpID to the client app, which calls the WebAuthn API on the platform. The OS, browser or libfido2 then sends a CTAP authenticatorGetAssertion command over USB, NFC or BLE to the security key, which signs the challenge with its private key. The signed assertion travels back through the platform to the relying party, which verifies it using the stored public key.

When should I use direct CTAP integration instead of OS platform APIs for passkeys?#

Direct CTAP integration is warranted only in regulated, high-assurance environments, such as banking or government zero-trust deployments, that require hardware-bound credentials with no cloud synchronization. For standard consumer and enterprise apps, OS platform APIs cover 95% or more of use cases with lower implementation complexity and native OS dialogs. On mobile platforms, bypassing the OS credential manager is generally not possible for standard apps, making libfido2 a primarily desktop and server-side pattern.

What CTAP version does a security key need to support passkeys and passwordless login?#

Security keys must implement at least CTAP2 to support passkeys and passwordless authentication, since CTAP1 only enables second-factor login and cannot store discoverable credentials. CTAP2 introduced resident key storage and on-device user verification via PIN or biometrics, which are prerequisites for usernameless login flows. CTAP2.1 adds enterprise credential management features, and CTAP2.2 adds cross-device authentication via QR and BLE tunnels.

What is libfido2 and when would a developer need to use it?#

libfido2 is an open-source C library developed by Yubico that implements CTAP communication with USB and NFC security keys on platforms where the OS does not handle this natively, particularly Linux. Command-line tools, SSH agents, disk encryption utilities and custom desktop applications use libfido2 to interact directly with hardware authenticators, often requiring udev rules for USB HID access. Mobile and standard web apps do not use libfido2, since iOS and Android route all credential operations through their native platform APIs.