---
url: 'https://www.corbado.com/blog/webauthn-vs-ctap-vs-fido2'
title: 'WebAuthn vs. CTAP vs. FIDO2: Key Differences'
description: 'Learn how WebAuthn, CTAP and FIDO2 differ, how they work together for passkey authentication and when direct CTAP integration is needed.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-03-05T19:07:37.098Z'
lastModified: '2026-03-25T10:01:38.126Z'
keywords: 'webauthn vs ctap, fido2 vs webauthn, fido2 ctap webauthn difference, ctap protocol, fido2 passkeys'
category: 'WebAuthn Know-How'
---

# WebAuthn vs. CTAP vs. FIDO2: Key Differences

## Key Facts

- **FIDO2** is an umbrella framework combining **WebAuthn** (the app-layer API) and
  **CTAP** (the hardware communication protocol). App developers code against WebAuthn,
  not CTAP.
- WebAuthn enables passkey registration and verification via browser APIs. Credentials are
  domain-bound, making them inherently phishing-resistant against fake login pages.
- CTAP is a binary protocol (USB HID, NFC, BLE) used only for external **roaming
  authenticators**. Platform authenticators like Face ID and Windows Hello use internal OS
  APIs instead.
- Most passkey deployments never require direct CTAP integration. OS platform APIs cover
  95%+ of use cases, including both platform and roaming authenticators.
- CTAP evolved from CTAP1 (second-factor only) to CTAP2 (passwordless, discoverable
  credentials) to CTAP2.2, which adds cross-device authentication and payment extensions.

## 1. Introduction

Developers building [passwordless authentication](https://www.corbado.com/glossary/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

| **Term**     | **What it is**                                                                 | **Who interacts with it**                  |
| ------------ | ------------------------------------------------------------------------------ | ------------------------------------------ |
| **FIDO2**    | Umbrella standard combining WebAuthn + CTAP                                    | Nobody directly - it is the framework      |
| **WebAuthn** | API for creating and verifying public-key credentials                          | App developers (web and native)            |
| **CTAP**     | Binary protocol between client device and roaming authenticator (security key) | OS/browser vendors, hardware manufacturers |

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](https://github.com/Yubico/libfido2) depending on platform. Platform
[authenticators](https://www.corbado.com/glossary/authenticator) like [Face ID](https://www.corbado.com/faq/is-face-id-passkey) or
[Windows Hello](https://www.corbado.com/glossary/windows-hello) do **not** use CTAP. The diagram below
illustrates how the layers connect.

## 3. What is FIDO2?

[FIDO2](https://www.corbado.com/glossary/fido2) is not a protocol or API. It is an authentication framework
created by the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) and the W3C to replace passwords
with [phishing](https://www.corbado.com/glossary/phishing)-resistant, public-key cryptography.

[FIDO2](https://www.corbado.com/glossary/fido2) encapsulates two specifications:

- **WebAuthn** (Web Authentication): W3C standard defining the API relying parties use to
  interact with client devices
- **CTAP** (Client-to-[Authenticator](https://www.corbado.com/glossary/authenticator) Protocol):
  [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) protocol defining how a client device
  communicates with an [authenticator](https://www.corbado.com/glossary/authenticator)

The power of [FIDO2](https://www.corbado.com/glossary/fido2) lies in
[architectural decoupling](https://techcommunity.microsoft.com/blog/microsoft-security-blog/all-about-fido2-ctap2-and-webauthn/288910).
A [relying party](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://github.com/Yubico/libfido2). For platform
[authenticators](https://www.corbado.com/glossary/authenticator) (Face ID,
[Windows Hello](https://www.corbado.com/glossary/windows-hello)), CTAP is not involved at all - the OS
communicates with the secure element via internal APIs. As new
[authenticator](https://www.corbado.com/glossary/authenticator) types emerge, relying parties need no code
changes.

## 4. What is WebAuthn?

WebAuthn is the
[standardized API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_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](https://www.corbado.com/blog/webauthn-errors) and
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) apps.

### 4.1 Registration and Authentication Ceremonies

WebAuthn defines two ceremonies:

1. **Registration:** The [relying party](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/webauthn-server-implementation) guide.
2. **Authentication:** The relying party calls `navigator.credentials.get()`. The
   authenticator signs a [cryptographic challenge](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/phishing) site, the client refuses to use credentials generated for
the legitimate domain. This makes WebAuthn inherently
[phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/security-key) or NFC
smartcard. It is transported over USB HID, NFC and BLE. CTAP does **not** govern
communication with platform [authenticators](https://www.corbado.com/glossary/authenticator) (Face ID,
[Windows Hello](https://www.corbado.com/glossary/windows-hello), [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://github.com/Yubico/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](https://www.corbado.com/glossary/security-key) manufacturers. If you are a
[security key](https://www.corbado.com/glossary/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](https://docs.solokeys.dev/repo-readme/) and
[Nitrokey](https://github.com/Nitrokey/nitrokey-fido2-firmware).

### 5.1 CTAP Versions

CTAP has evolved significantly. The biggest leap was from CTAP1 to CTAP2, which introduced
[passwordless authentication](https://www.corbado.com/glossary/passwordless-authentication). The timeline below
shows the progression and what each version unlocked.

For reference, the key capabilities per version:

| **Version**     | **Key capability**                                                                                                                                                                                       | **Limitation**                               |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| **CTAP1** (U2F) | Second-factor auth with external keys                                                                                                                                                                    | No passwordless, no discoverable credentials |
| **CTAP2**       | Discoverable credentials, user verification on hardware, passwordless                                                                                                                                    | Limited credential management                |
| **CTAP2.1**     | Delete/update individual credentials, Enterprise Attestation, hmac-secret                                                                                                                                | -                                            |
| **CTAP2.2**     | Persistent PIN/UV tokens, cross-device authentication (QR + BLE), [payment extensions](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html) | -                                            |

### 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](https://www.corbado.com/passkeys-for-travel) over an encrypted cloud tunnel, not BLE itself

For more on transport handling see our
[WebAuthn transports](https://www.corbado.com/blog/webauthn-transports-internal-hybrid) guide.

## 6. Side-by-Side Comparison

| **Dimension**     | **WebAuthn**                               | **CTAP**                                   |
| ----------------- | ------------------------------------------ | ------------------------------------------ |
| **Domain**        | Application ↔ client device                | Client device ↔ authenticator              |
| **Maintainer**    | W3C                                        | FIDO Alliance                              |
| **Who uses it**   | App developers, identity providers         | OS/browser vendors, hardware manufacturers |
| **Core function** | APIs for credential creation and assertion | Binary protocol for hardware interaction   |
| **Data format**   | JSON, ArrayBuffers                         | Canonical CBOR, APDU (legacy)              |
| **Transport**     | HTTPS (client ↔ server)                    | USB, NFC, BLE (client ↔ hardware)          |

## 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](https://www.corbado.com/blog/how-to-enable-passkeys-android) Keystore). They communicate with the
secure element (e.g. Apple [Secure Enclave](https://www.corbado.com/glossary/secure-enclave), TPM) via internal
OS APIs - CTAP is not involved. Passkeys primarily use platform authenticators and can
sync across devices via [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) or
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager).

Roaming authenticators are external hardware
(USB/[NFC security keys](https://www.corbado.com/blog/best-fido2-hardware-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](https://www.corbado.com/blog/webauthn-public-key-credential-hints):
`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](https://www.corbado.com/blog/webauthn-errors),
`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](https://github.com/Yubico/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](https://www.corbado.com/passkeys-for-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.

| **Strategy**    | **OS Platform APIs (WebAuthn)**       | **Direct CTAP (SDKs/libfido2)**           |
| --------------- | ------------------------------------- | ----------------------------------------- |
| **Credentials** | Synced passkeys + hardware keys       | Hardware keys only                        |
| **Complexity**  | Low to moderate                       | Very high                                 |
| **UX**          | Native OS dialogs                     | Custom UI required                        |
| **Use case**    | Consumer and standard enterprise apps | High-assurance banking, strict zero-trust |

## 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](https://www.corbado.com/blog/webauthn-errors) 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](https://www.corbado.com/faq/gradual-rollout-support-passkey-adoption) 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](https://www.corbado.com/glossary/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.