Wiki · Concept · Last reviewed June 25, 2026

Client to Authenticator Protocol (CTAP)

Client to Authenticator Protocol, usually shortened to CTAP, is the FIDO protocol layer that lets a browser, operating system, or platform client communicate with a FIDO2 authenticator.

Category: Concept Updated: June 25, 2026 Tags: CTAP, FIDO2, WebAuthn, passkeys, authenticators, identity, agents

Definition

Client to Authenticator Protocol (CTAP) is a FIDO Alliance protocol for communication between a client or platform and a FIDO2 authenticator. FIDO's specifications page describes CTAP as using USB, NFC, and BLE for communication between browsers or platforms and FIDO2 authenticators. As of this page's review date, that page listed CTAP 2.3 as a Proposed Standard.

CTAP sits below the visible web login ceremony. A person usually sees a browser prompt, a security key touch, a device unlock, or a passkey approval. Under that surface, the platform needs a way to create credentials, use credentials, report capabilities, and manage authenticators without inventing a new device protocol for each application.

How It Works

A relying party begins with a WebAuthn registration or authentication request. The browser checks origin and relying-party context, then the client or platform talks to an authenticator. CTAP defines the authenticator-facing commands and transport bindings for that conversation. The CTAP specification describes an application-layer protocol and transport-specific bindings, including USB HID, NFC, and Bluetooth Low Energy sections.

At a high level, credential creation asks an authenticator to make a new public-key credential for a relying party. Authentication asks the authenticator to produce an assertion over a challenge. The authenticator may require user presence, user verification, or a PIN/UV flow depending on policy and device capability. The private key is not handed to the browser or relying party; the relying party verifies public-key material and signed responses.

CTAP also carries capability and management questions, including authenticator information, credential management, configuration, PIN/UV, and transport behavior. Most people should not have to know those command names to sign in; the protocol keeps that machinery interoperable.

WebAuthn Boundary

WebAuthn and CTAP are often mentioned together because they divide the work. WebAuthn is the W3C web API that enables creation and use of scoped public-key credentials by web applications. CTAP is the FIDO authenticator-side protocol used by clients and platforms when they need to communicate with FIDO2 authenticators.

This boundary matters for passkeys and agentic browsers. A web application reasons about origins, relying-party IDs, challenges, credential IDs, attestation, and assertions. A platform implementer also handles authenticator discovery, transports, command framing, user verification, and device management.

Agent Context

CTAP is important in agent-era authentication because it helps keep the authenticator boundary concrete. A browser automation agent should not be given a reusable password or a copy of a private credential. It may ask the browser to initiate a login ceremony, but the decisive operation should still pass through a user-mediated authenticator path.

That does not make the agent trustworthy. CTAP can help preserve a hardware or platform boundary around a key, but it does not decide whether the agent should submit a tax form, move money, delete records, or approve a contract after login. The stronger the sign-in ceremony becomes, the more important it is to separate authentication from authorization, delegation, and later tool use.

Limits and Failure Modes

CTAP does not remove endpoint risk. Malware, a compromised browser profile, a malicious extension, or an over-permissioned automation tool can still act after a valid authentication event. The protocol protects the authenticator conversation; it does not make the surrounding session benevolent.

It also does not solve recovery. If account recovery falls back to weak email, SMS, help-desk override, or poorly governed passkey sync, a strong authenticator path can be bypassed. Device loss and authenticator replacement are product, support, and policy problems as much as protocol problems.

Attestation and authenticator policy can become brittle. Narrow device allowlists can exclude users, reveal device class, or make migrations harder. USB, NFC, and BLE also have different pairing, proximity, discovery, and user-experience failure modes.

Minimum Evidence Record

An agent platform that depends on CTAP-backed authentication should record the WebAuthn origin, relying-party ID, credential ID, authenticator attachment or transport when available, user-presence and user-verification outcome, challenge validation result, step-up event, session created, and agent action that followed. Logs should not retain private keys, biometric data, PINs, raw authenticator secrets, or unnecessary device identifiers.

Defense Pattern

Spiralist Reading

Spiralism reads CTAP as the small, technical passage where trust crosses from general-purpose software into a held or embedded authenticator. It narrows the claim "the user is here" into a local, cryptographic ceremony with defined transports and commands.

The warning is that stronger ceremonies can create a cleaner-looking mistake. A good authenticator proof says something limited about a credential operation. It does not say that every later automated action is wise, wanted, or authorized.

Sources

Return to Wiki