Skip to main content
Identity Authority
Category: FIDO & Passkeys

Client to Authenticator Protocol 2

Also known as: CTAP2, Client to Authenticator Protocol 2
Simply put

CTAP2 is a protocol that lets a device such as a laptop or phone communicate with an external or built-in security key or authenticator so the user can prove their identity. It handles the conversation between the client (like a browser) and the authenticator that holds the credential. It is one part of the broader FIDO2 set of specifications used for strong, often passwordless, authentication.

Formal definition

CTAP2 is a component of the FIDO2 specifications that defines the communication between a client platform (for example a browser or operating system acting as a WebAuthn client) and an external or platform authenticator over transports such as USB, NFC, or BLE. It complements WebAuthn: WebAuthn defines the web-facing API between the relying party and the client, while CTAP2 defines the lower-level messaging by which the client instructs the authenticator to perform operations such as credential creation and assertion generation, typically including user presence and, where supported, user verification. As an inherence- or possession-based authentication mechanism, CTAP2 concerns verifying the user or device to produce a signed assertion; it does not by itself define authorization or entitlement decisions. Note that specific version details, supported extensions, and transport behavior depend on the authenticator and client implementation and should be confirmed against the applicable specification.

Why it matters

CTAP2 is a foundational piece of the FIDO2 architecture that makes phishing-resistant, often passwordless authentication practical across devices. Because it defines how a client platform such as a browser or operating system communicates with an external security key or a built-in platform authenticator, it enables users to authenticate with hardware they possess rather than shared secrets that can be intercepted or replayed. For organizations moving away from password-based logins, understanding CTAP2 clarifies where the actual credential operations happen and why the model resists many common credential-theft attacks.

For identity architects and engineers, the distinction between CTAP2 and WebAuthn matters operationally. WebAuthn is the web-facing API between the relying party and the client, while CTAP2 handles the lower-level messaging between the client and the authenticator over transports such as USB, NFC, or BLE. Treating the two as interchangeable can lead to incorrect assumptions about where user presence and user verification are enforced, and about what transports and authenticator types a given deployment can support. Getting this boundary right is important when evaluating authenticator compatibility and planning rollouts.

It is also important to keep CTAP2 scoped correctly: it is concerned with verifying the user or device and producing a signed assertion, not with authorization or entitlement decisions. Specific version details, supported extensions, and transport behavior depend on the authenticator and client implementation, so claims about capabilities should be confirmed against the applicable specification rather than assumed.

Who it's relevant to

Security architects
Architects designing phishing-resistant or passwordless authentication need to understand where CTAP2 fits relative to WebAuthn, so they can correctly reason about which layer enforces user presence and user verification and which transports and authenticator types their design supports.
IAM engineers
Engineers implementing FIDO2-based login must account for how the client platform communicates with external and platform authenticators over USB, NFC, or BLE, and should confirm supported operations, extensions, and transport behavior against the applicable specification and the specific authenticators in scope.
System administrators
Administrators rolling out security keys or platform authenticators benefit from knowing that CTAP2 governs the client-to-authenticator conversation, which affects device and transport compatibility and how user verification (such as a PIN or biometric) is prompted.
Compliance officers
Those evaluating authentication controls should recognize that CTAP2 addresses verifying the user or device to produce a signed assertion and does not by itself cover authorization or entitlement decisions, so control assessments must look beyond it for access decisions.

Inside CTAP2

Client to Authenticator Protocol version 2
CTAP2 is the protocol within the FIDO2 set of specifications that defines how a client platform (such as a browser or operating system) communicates with an external or roaming authenticator, for example a security key connecting over USB, NFC, or BLE. It complements WebAuthn, which handles the interaction between the client and the relying party.
Authenticator communication transports
CTAP2 typically specifies message exchanges over transports such as USB (HID), NFC, and BLE, allowing a roaming authenticator to be used across different client devices depending on the authenticator's supported capabilities.
makeCredential and getAssertion operations
CTAP2 commonly defines core operations used during registration and authentication, where the client requests the authenticator to create a credential key pair (registration) and later to produce a signed assertion proving possession of the private key (authentication).
User verification and user presence
CTAP2 authenticators can enforce user presence (a simple touch or tap) and, depending on the authenticator, user verification through an inherence or knowledge factor such as a biometric or a PIN, supporting possession-based authentication that can be combined into multi-factor flows.
Relationship to FIDO2, WebAuthn, and passkeys
CTAP2 and WebAuthn together make up FIDO2. CTAP2 governs the client-to-authenticator link, while WebAuthn governs the browser-to-relying-party link. Passkeys are FIDO2 credentials that may be used with CTAP2 when stored on a roaming authenticator; these terms are related but not interchangeable.

Common questions

Answers to the questions practitioners most commonly ask about CTAP2.

Is CTAP2 the same thing as WebAuthn?
No. CTAP2 and WebAuthn are two distinct components of the broader FIDO2 set of specifications, and they operate at different layers. WebAuthn is the web-facing API that a relying party's application uses through the browser or platform to request and receive credential operations. CTAP2 (Client to Authenticator Protocol 2) is the protocol that governs communication between the client platform (such as the browser or operating system) and an external or roaming authenticator (for example, a security key over USB, NFC, or BLE). In a typical FIDO2 flow, WebAuthn handles the relying-party-to-client interaction while CTAP2 handles the client-to-authenticator interaction. They are complementary, not interchangeable.
Does CTAP2 by itself authenticate the user?
CTAP2 is a transport and command protocol between a client and an authenticator; it defines how the client instructs the authenticator to create or use credentials and how the authenticator responds. The actual authentication assertion is produced by the authenticator and consumed and verified by the relying party via WebAuthn, as part of the overall FIDO2 flow. CTAP2 also enables mechanisms such as user verification (for example, a PIN or biometric handled locally by the authenticator) and user presence, but on its own it is one piece of the flow rather than the complete authentication decision. Treat CTAP2 as the client-to-authenticator layer within FIDO2 rather than as a standalone authentication protocol.
Which transports does CTAP2 typically use to reach a roaming authenticator?
CTAP2 is commonly used over USB, NFC, and BLE to communicate with external or roaming authenticators such as security keys. The specific transports available depend on the authenticator hardware and the client platform, so behavior varies by device and configuration. Platform authenticators integrated into an operating system may be reached through internal mechanisms rather than these external transports.
How does CTAP2 support user verification versus user presence in an implementation?
CTAP2 distinguishes user presence (typically a simple test that a human is present, such as a touch) from user verification (confirming the specific user through a factor handled locally by the authenticator, such as a PIN or biometric). In deployments requiring stronger assurance, relying parties can request user verification through WebAuthn, and the authenticator handles that verification locally via CTAP2 before producing an assertion. Whether a given authenticator supports user verification depends on its capabilities, so implementers should account for varying authenticator support rather than assuming it.
What should implementers consider about discoverable credentials when using CTAP2?
CTAP2 supports discoverable credentials (sometimes referred to as resident keys), which allow an authenticator to store credential information so the user can be identified without the relying party first supplying a credential identifier. This is relevant for usernameless or passwordless flows. Because discoverable credentials consume storage on the authenticator and support varies across devices, implementers should confirm authenticator capabilities and plan for capacity and fallback behavior depending on the deployment.
How does an application invoke CTAP2 in practice?
Applications generally do not call CTAP2 directly. A relying party's web application uses the WebAuthn API through the browser or platform, and the client platform then uses CTAP2 to communicate with the external authenticator over the available transport. This separation means most integration work focuses on the WebAuthn layer, while CTAP2 operates beneath it between the client and the authenticator. The exact division of responsibilities can vary by platform and browser implementation.
What role does CTAP2's PIN or client-managed verification play in enrollment and use?
CTAP2 defines mechanisms for a client to establish and use a PIN or similar verification with an authenticator so that user verification can be enforced locally on the device. This lets a roaming authenticator confirm the user during credential operations without exposing the secret to the relying party. Support, PIN policies, and retry or lockout behavior depend on the authenticator and platform, so implementers should document these behaviors for their chosen devices rather than assuming uniform handling.

Common misconceptions

CTAP2 is the same thing as WebAuthn, or the two are interchangeable.
They are distinct but complementary parts of FIDO2. WebAuthn defines the API between the client and the relying party, whereas CTAP2 defines the protocol between the client and an external authenticator. A roaming-authenticator flow typically uses both together.
CTAP2 authenticates the user directly to the application or relying party.
CTAP2 handles the client-to-authenticator exchange only. The authentication assertion it produces is relayed through the client to the relying party via WebAuthn; CTAP2 itself does not communicate with the relying party. Identification, authentication, and authorization remain separate steps in the overall flow.
Every CTAP2 authenticator provides the same factors and always performs multi-factor authentication.
Capabilities vary by authenticator and configuration. Some enforce only user presence (a touch), while others support user verification via PIN or biometric. Whether a given CTAP2 interaction contributes one or more factors depends on the authenticator and how the relying party requests verification.

Best practices

Treat CTAP2 and WebAuthn as parts of a single FIDO2 deployment, and validate that your chosen browsers, operating systems, and relying party libraries support the transports (USB, NFC, BLE) your authenticators use.
Decide explicitly whether flows require user verification or only user presence, since this determines whether the CTAP2 interaction contributes an inherence or knowledge factor in addition to the possession factor.
Confirm the specific capabilities of each authenticator model rather than assuming uniform behavior, because supported operations, verification methods, and transports differ across devices.
Keep authentication concerns handled by the FIDO2 flow separate from downstream authorization decisions, and document where identification, authentication, and authorization occur in your access flow.
Where roaming authenticators are used as passkeys, verify how credentials are stored and used on the authenticator and communicate the distinction between passkeys and the underlying CTAP2 protocol to stakeholders.
Test client-to-authenticator behavior across the transports and platforms your users rely on, since interoperability can depend on vendor implementation and configuration.
Promotional banner for the Pentest Readiness checklist download