Skip to main content
Identity Authority
Category: FIDO & Passkeys

Client to Authenticator Protocol

Also known as: CTAP, FIDO CTAP, CTAP2
Simply put

CTAP is a protocol that lets a computer, phone, or browser talk to a separate authentication device, such as a security key you plug in or tap. It defines how those two components exchange messages so the external device can help verify who you are during sign-in.

Formal definition

CTAP is a FIDO Alliance application-layer protocol that specifies communication between a client or platform (for example, a browser or operating system) and an external or roaming authenticator (such as a hardware security key), typically over transports like USB, NFC, or Bluetooth. It is a companion specification to WebAuthn within the broader FIDO2 framework: WebAuthn defines the web-facing API between a relying party and the client, while CTAP defines the client-to-authenticator interface used to invoke credential creation and assertion operations on the authenticator. CTAP has evolved across published versions (including 2.0, 2.1, 2.2, and 2.3 as reflected in FIDO Alliance specification drafts and releases); specific features, capabilities, and transport support depend on the CTAP version and the authenticator implementation. Note that CTAP addresses the message exchange for authentication ceremonies and does not by itself constitute an identity federation or authorization protocol.

Why it matters

CTAP is one of the two protocols that make hardware-backed, phishing-resistant authentication practical across the web and operating systems. Within the FIDO2 framework, WebAuthn defines how a relying party's web application talks to the client, but that alone cannot reach an external security key plugged into USB or tapped over NFC. CTAP fills that gap by specifying how the client or platform communicates with a roaming authenticator, so that credential creation and assertion operations can actually be invoked on the device holding the private key. Without an agreed client-to-authenticator protocol, hardware authenticators from different vendors would not interoperate with browsers and operating systems in a consistent way.

For security architects and IAM engineers, CTAP matters because it underpins the interoperability that lets an organization deploy security keys and passkeys without locking into a single vendor's proprietary stack. Because specific features, capabilities, and transport support depend on the CTAP version (published versions include 2.0, 2.1, 2.2, and 2.3 as reflected in FIDO Alliance specification drafts and releases) and on the individual authenticator implementation, understanding CTAP is essential when evaluating which authenticators satisfy a given requirement. A capability assumed from one authenticator may not be present in another that implements an earlier CTAP version.

It is equally important to scope CTAP correctly. CTAP addresses the message exchange for authentication ceremonies between a client and an authenticator; it is not, by itself, an identity federation or authorization protocol. Treating it as a substitute for federation standards or authorization frameworks would be a category error. In practice CTAP sits below the WebAuthn API and complements, rather than replaces, the broader identity and access infrastructure an organization already operates.

Who it's relevant to

Security architects
Architects designing phishing-resistant, hardware-backed authentication need to understand how CTAP and WebAuthn divide responsibilities within FIDO2. Because supported features and transports vary by CTAP version and authenticator implementation, architects should specify version and capability requirements when selecting authenticators rather than assuming interoperability across all devices.
IAM engineers
Engineers integrating security keys and passkeys work directly with the WebAuthn API on the relying-party side, while CTAP governs the client-to-authenticator exchange beneath it over transports such as USB, NFC, or Bluetooth. Knowing this boundary helps engineers isolate where a problem lives during troubleshooting and set accurate expectations about what a given authenticator can do.
Compliance and audit teams
Teams evaluating authentication controls should recognize that CTAP is scoped to the message exchange for authentication ceremonies and is not an identity federation or authorization protocol. Its capabilities depend on the CTAP version and authenticator implementation, so evidence of a specific feature should be tied to the actual devices deployed rather than to the protocol in general.
System administrators
Administrators rolling out hardware authenticators need to account for the fact that transport support and features differ by CTAP version and by device. Verifying that the chosen authenticators, client platforms, and browsers support the required CTAP version helps avoid interoperability gaps during deployment.

Inside CTAP

CTAP2
The version of the protocol used in the FIDO2 stack, enabling a client (such as a browser or platform) to communicate with an external or roaming authenticator. CTAP2 is the version most commonly referenced in modern WebAuthn deployments; earlier CTAP1/U2F semantics differ and support varies by authenticator and platform.
CTAP1 (U2F compatibility)
The legacy protocol layer, historically aligned with the U2F model, that some authenticators and clients continue to support for backward compatibility. Its capabilities are narrower than CTAP2, and availability depends on the specific device and client implementation.
Client (platform) role
The software component, typically a browser or operating system, that mediates between the relying party's WebAuthn calls and the authenticator. The client invokes CTAP operations rather than performing the cryptographic authentication itself.
Authenticator role
The hardware or platform component that holds the cryptographic keys and performs the credential creation and assertion operations. Roaming authenticators (for example security keys) are a primary use case for CTAP, since platform authenticators may communicate through internal interfaces.
Transport bindings
The physical or logical channels over which CTAP messages travel between client and roaming authenticator, such as USB, NFC, and BLE. Which transports are supported depends on the authenticator hardware and the client's capabilities.
Relationship to WebAuthn
CTAP is one of the two complementary specifications that together form FIDO2; WebAuthn is the web API between the relying party and the client, while CTAP is the protocol between the client and the authenticator. The two operate at different layers and are not interchangeable.

Common questions

Answers to the questions practitioners most commonly ask about CTAP.

Is CTAP the same thing as WebAuthn?
No. CTAP and WebAuthn are complementary components of the FIDO2 project, not synonyms. WebAuthn is the web API, standardized by the W3C, that a relying party's web application and the browser use to request and receive credentials. CTAP is the protocol that governs communication between the client platform (such as the browser or operating system) and an external or roaming authenticator (such as a security key). In a typical FIDO2 flow, WebAuthn operates between the relying party and the client, while CTAP operates between the client and the authenticator. Depending on the deployment, an authenticator built into the platform may not require CTAP at all, whereas an external authenticator generally does.
Does CTAP by itself authenticate the user?
Not on its own. CTAP is a transport and command protocol that carries requests and responses between the client and the authenticator; it enables the exchange in which an authenticator performs a cryptographic operation and, depending on configuration, verifies the user locally. The actual authentication assurance in a FIDO2 flow comes from the authenticator's use of public-key credentials and, where enabled, user verification (such as a PIN or biometric inherence factor) and user presence. CTAP defines how those interactions are requested and reported, but describing CTAP alone as the authentication mechanism conflates the transport with the verification and the broader ceremony that WebAuthn coordinates.
How do the CTAP versions differ, and which should we plan around?
The FIDO Alliance has published successive CTAP specifications; the earlier generation is commonly referred to as CTAP1 (historically associated with the U2F work) and the later, more capable generation as CTAP2, which supports features such as user verification with a PIN, resident/discoverable credentials, and richer command sets. Because exact feature availability depends on the specific specification revision and on what a given authenticator and client implement, verify support against the authenticator's certification and vendor documentation rather than assuming a version number guarantees a feature. Many current deployments target CTAP2-capable authenticators, but backward interoperability with CTAP1-style behavior may still matter for older keys.
Which transports does CTAP use to reach an external authenticator?
CTAP is defined to operate over multiple transport bindings so that roaming authenticators can connect to a client through different physical or wireless channels. Common transports discussed in the specifications include USB, NFC, and Bluetooth Low Energy, with the specific set supported determined by the authenticator hardware and the client platform. Practical implications include user experience differences and platform support gaps, so confirm which transports both your target authenticators and your client environments actually support before committing to a rollout.
How does PIN or biometric user verification fit into a CTAP-based deployment?
In CTAP2, user verification can be performed locally by the authenticator, for example through a PIN (a knowledge factor) or an on-device biometric (an inherence factor), and CTAP defines the commands used to establish and exercise that verification between client and authenticator. Whether user verification is required, preferred, or discouraged in a given ceremony is typically driven by the relying party's WebAuthn request policy, subject to what the authenticator supports. Because behavior varies by authenticator capability and configuration, define your user verification requirements explicitly and test them against the specific authenticators you intend to support rather than assuming uniform enforcement.
What should we test for interoperability when supporting external authenticators via CTAP?
Interoperability testing should cover the combinations that matter in your environment: the CTAP version behaviors of your target authenticators, the transports they use, the client platforms and browsers your users run, and whether discoverable/resident credentials and user verification methods behave as expected end to end with your WebAuthn relying party. It is also worth validating error handling and fallback paths for authenticators or clients that support only a subset of features. Given that exact behavior depends on vendor implementation, specification revision, and platform, prefer empirical testing and certification review over assumptions, and document known limitations for your support matrix.

Common misconceptions

CTAP and WebAuthn are the same thing.
They are distinct, complementary specifications within FIDO2. WebAuthn defines the browser/relying-party API, whereas CTAP defines how the client talks to the authenticator. A complete FIDO2 authentication flow typically relies on both operating at different layers.
CTAP performs user authentication by itself.
CTAP is the communication protocol that lets a client invoke operations on an authenticator; the authenticator holds the keys and produces the assertion. Authentication as experienced by a relying party involves WebAuthn, the client, and the authenticator together, not CTAP in isolation.
All authenticators and clients support the same CTAP version and transports.
Support for CTAP2 versus CTAP1/U2F, and for transports such as USB, NFC, and BLE, varies by authenticator hardware and by client. Practitioners should verify supported versions and transports for the specific devices and platforms in scope.

Best practices

Confirm which CTAP version (CTAP2 versus legacy CTAP1/U2F) your target authenticators and clients support, since capabilities and available operations differ between them.
Validate the transports (USB, NFC, BLE) required by your user population against the authenticators and client platforms you plan to support, as transport availability varies by device.
Treat CTAP and WebAuthn as separate layers when designing or troubleshooting flows, and isolate issues to the client-to-authenticator link versus the relying-party-to-client API.
Test roaming authenticators separately from platform authenticators, because their communication paths and CTAP interactions can differ in practice.
Document supported CTAP versions and transports per authenticator model in your deployment so support and audit teams can reason about coverage and limitations.
Where behavior is configuration- or vendor-dependent, verify against the specific implementations in scope rather than assuming uniform CTAP support across the ecosystem.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps