CTAP 2.2 strengthens the FIDO2 protocol with persistent PIN tokens, configurable PIN complexity policies, payment authentication support, and richer authenticator metadata. This guide covers each feature from an implementation perspective, with specific guidance for Yubico SDKs.
|
Note
|
WebAuthn and Browser Support: While CTAP 2.2 features are available at the protocol level, WebAuthn applications depend on browser support for these capabilities. Not all CTAP 2.2 features are exposed through the WebAuthn JavaScript API. For web developers, consult our WebAuthn Browser Support page before implementation. |
|
Note
|
CTAP 2.2 and Certification: The FIDO Alliance did not create a separate certification category for CTAP 2.2. Certifications are issued against CTAP 2.3, which is fully backwards-compatible with CTAP 2.2. There is no |
The Client to Authenticator Protocol (CTAP) defines how authenticators communicate with clients for FIDO2 authentication. CTAP 2.2 strengthens the protocol with features that address enterprise deployment requirements and expand authentication options across the FIDO ecosystem.
For roaming authenticators like YubiKeys, this release delivers capabilities that reduce friction in enterprise workflows: persistent PIN/UV auth tokens provide long-lived, read-only tokens for credential enumeration without repeated PIN entry; PIN complexity policies give platforms a standard way to query whether device-specific PIN requirements are active; and the thirdPartyPayment extension enables cross-domain authentication for regulated payment transactions.
CTAP 2.2 also formalizes hybrid transport, a protocol mechanism for cross-device authentication using QR codes and proximity pairing. This allows a platform authenticator on a phone to authenticate sessions on other devices like desktops. Hybrid flows use platform authenticators (such as those on smartphones) or multi-device passkeys. For scenarios requiring attestation and non-exportable keys, hardware security keys remain the appropriate authenticator choice.
This guide covers CTAP 2.2 features from an implementation perspective, with specific guidance for Yubico SDKs. Many features operate at the native application layer—check our browser support matrix for WebAuthn API availability.
CTAP 2.2 introduces new protocol capabilities and expands features established in CTAP 2.1. The table below highlights major changes, organized by relevance to roaming authenticators like YubiKeys.
| Feature | Description | Developer Benefit |
|---|---|---|
Persistent PIN/UV Auth Tokens (PPUAT) (New in 2.2) |
Long-lived, read-only tokens scoped to credential enumeration operations ( |
Improves UX in enterprise SSO portals and password managers during long-running or resumable credential enumeration. Complements the session-scoped |
PIN Complexity Policies (New in 2.2) |
A protocol mechanism for authenticators to advertise PIN complexity requirements. Authenticators with PIN complexity enabled—via device configuration or certification requirements—can reject PINs that fail their policy. |
Enables platforms to detect that PIN complexity is active and adapt their UX accordingly. Complements minimum-length enforcement introduced by |
thirdPartyPayment Extension (New in 2.2) |
Allows a credential to be asserted in a context where the transaction initiator (e.g., a merchant) differs from the relying party that created the credential (e.g., a bank), without requiring redirects. |
Critical for payment industry compliance with PSD2 Strong Customer Authentication. Enables standardized, phishing-resistant payment flows required by card networks and regulators. |
HMAC Secret MakeCredential ( |
Extends the existing |
Enables immediate encryption of local data with hardware-backed secrets at registration time. Critical for password managers, encrypted vaults, and offline workstation scenarios. |
Hybrid Transport (New in 2.2) |
Cross-device authentication protocol using QR code initiation and proximity-based pairing (BLE + encrypted network tunnel). Enables a platform authenticator on one device to authenticate sessions on another. |
Expands FIDO adoption for consumer applications. Developers can implement passwordless experiences that leverage users' existing devices. |
JSON-Based Messaging (New in 2.2) |
Adds support for Digital Credentials API requests using JSON-based messages over hybrid transport. Signaled by the |
Enables browsers to exchange CTAP-compliant requests and responses via the Digital Credentials API without requiring CBOR decoding at the JavaScript layer. |
Attestation Formats Preference ( |
A new |
Allows clients to signal preferred attestation statement formats. Authenticators that support multiple formats select the highest-priority match, reducing format negotiation overhead for relying parties. |
Enhanced Authenticator Metadata ( |
Richer self-description capabilities including UV counters ( |
Enables adaptive client behavior. Applications can dynamically adjust UI and validation logic based on authenticator capabilities without trial-and-error probing. |
|
Note
|
Protocol Capabilities vs Device Support: This table reflects CTAP 2.2 protocol features. Individual authenticator implementations vary—check YubiKey firmware documentation and SDK support matrices for specific device capabilities. |
|
Spec
|
Allows long-lived, read-only tokens for credential management operations without repeated PIN entry. |
|
Use Case
|
Enterprise SSO portals performing background credential audits; password managers that resume enumeration across sessions; browsers implementing autofill or conditional mediation UX for hardware security keys. |
|
Yubico Support
|
Available in Yubico.NET SDK v1.14.0+, yubikit-android v2.9.0+, and python-fido2 v2.0.0+. |
CTAP 2.1 introduced pinUvAuthToken with a permissions model. A single PIN entry produces a token with cm (credential management) scope, valid for the duration of that session. PPUATs extend this by introducing a separate, narrower token that persists across power cycles and is scoped exclusively to read-only credential management operations: enumerateRPs, enumerateCredentials, and getCredentialMetadata. This eliminates re-authentication in long-running or resumable enumeration workflows without granting the broader write access carried by a full cm-scoped token.
PPUATs do not grant assertion or credential creation permissions.
|
Caution
|
Browser Limitation: PPUATs are a protocol-level feature not currently exposed through WebAuthn APIs. This feature is primarily useful for native applications that communicate directly with authenticators via CTAP. |
|
Spec
|
Authenticators can enforce PIN rules beyond minimum length and can advertise whether a complexity policy is active. |
|
Use Case
|
Enterprises with organizational PIN policies; devices configured for Common Criteria or equivalent certification requirements. |
|
Yubico Support
|
Available in Yubico.NET SDK v1.14.0+, libfido2, and python-fido2 v2.0.0+. |
CTAP 2.1 introduced minimum PIN length enforcement via minPINLength. CTAP 2.2 expands this with the pinComplexityPolicy mechanism, allowing authenticators to advertise whether a PIN complexity policy is active.
What this mechanism does—and does not—mandate:
The CTAP 2.2 specification introduces the protocol for expressing and querying PIN complexity status. It does not define specific complexity rules or require all CTAP 2.2 authenticators to enforce complexity.
Enforcement is authenticator-specific and typically driven by device certification requirements (such as Common Criteria) or explicit configuration during provisioning.
On standard YubiKey 5 Series devices, PIN complexity requires explicit configuration. On YubiKey 5 FIPS Series and YubiKey 5 Enhanced PIN, it is enabled by default.
YubiKey’s PIN complexity policy blocks trivial and commonly-used values such as sequential patterns and dictionary words. This follows NIST SP 800-63B guidance to check PINs against commonly-used values. Note that NIST SP 800-63B explicitly discourages character-composition rules (requiring uppercase, digits, etc.); Yubico’s implementation follows this approach.
Clients can query the pinComplexityPolicy field in authenticatorGetInfo to detect whether PIN complexity is enabled on a given device and adapt their UX accordingly.
pinComplexityPolicyURL is an optional string field also introduced in CTAP 2.2’s authenticatorGetInfo response. When present, it provides a URL where the platform can direct users to read the PIN composition rules that apply to their device.
Before this mechanism, when a user entered a PIN that violated a complexity policy, the authenticator returned a generic rejection error. Platforms had no standard way to distinguish "PIN too short" from "PIN not complex enough," or to tell users where to read the applicable rules. This was particularly notable with devices that have firmware-enforced PIN complexity (YubiKey 5 FIPS Series, YubiKey 5 Enhanced PIN)—the user had no indication that complexity rather than length was the issue.
Platforms building PIN rejection UX should:
Query pinComplexityPolicy on every session to detect whether complexity is active.
If pinComplexityPolicy is true and a PIN is rejected, display a message that specifically identifies the complexity failure (distinct from length failures).
If pinComplexityPolicyURL is present, offer a link so users can read the applicable rules.
| YubiKey Variant | PIN Complexity Default | Notes |
|---|---|---|
YubiKey 5 Series (standard) |
Off (requires configuration) |
Can be enabled via custom pre-registration configuration |
YubiKey 5 FIPS Series |
On |
Required by FIPS 140-3 / Common Criteria certification |
YubiKey 5 Enhanced PIN Series |
On |
Always on; cannot be permanently disabled |
Security Key Series |
Off (enterprise variants: configurable) |
— |
|
Spec
|
Enables assertion of a credential where the transaction initiator differs from the credential’s relying party. |
|
Use Case
|
Payment providers integrating PSD2 SCA via Secure Payment Confirmation (SPC). |
|
Yubico Support
|
Available in Yubico.NET SDK v1.14.0+, yubikit-android v2.9.0+, and python-fido2 v2.0.0+. |
The thirdPartyPayment extension allows a credential registered at one origin (e.g., a bank) to be used for authentication in a context where a different party initiates the transaction (e.g., a merchant checkout). This is the protocol primitive that makes Secure Payment Confirmation possible under PSD2. Note that most of the SPC-specific processing must be handled by a compliant browser or client—this extension alone is not sufficient to implement a complete SPC flow.
|
Note
|
Browser Support Required: Secure Payment Confirmation requires coordinated browser support. Check our browser support matrix before implementing SPC workflows, as browser adoption is still evolving. |
|
Spec
|
Adds secret derivation support to the |
|
Use Case
|
Applications needing a per-credential secret immediately at registration—for example, password managers encrypting vaults or offline workstation access systems. |
|
Yubico Support
|
Available in Yubico.NET SDK v1.14.0+, yubikit-android v2.9.0+, and python-fido2 v2.0.0+. |
The hmac-secret extension has existed since CTAP 2.1 and returns a credential-specific secret during authenticatorGetAssertion. The hmac-secret-mc extension adds the ability to retrieve that secret during authenticatorMakeCredential as well, enabling applications to immediately encrypt data with a hardware-backed secret without requiring the user to perform a separate authentication step first.
|
Note
|
Relationship to WebAuthn PRF: The WebAuthn PRF extension maps to the Note: For comprehensive implementation guidance, see our PRF extension documentation: |
|
Spec
|
Cross-device authentication protocol using QR codes and BLE proximity pairing. |
|
Use Case
|
Enables FIDO authentication on devices without built-in authenticators by leveraging a phone’s platform authenticator. |
|
Yubico Support
|
Not applicable—hybrid transport is implemented by platform authenticators and clients, not roaming security keys. |
Hybrid transport allows a platform authenticator on a phone to complete authentication for sessions on other devices like desktops. The user scans a QR code displayed on the desktop, and the phone establishes a secure connection via BLE and an encrypted network tunnel to complete the FIDO ceremony.
CTAP 2.2 defines WebSocket-based tunnels as the data transfer channel for QR-initiated hybrid transactions. CTAP 2.3 extends this with Bluetooth Low Energy as an alternative channel. See the CTAP 2.3 guide for details.
|
Note
|
Implementation Note: Browsers and operating systems handle hybrid transport. Application developers design flows that support both roaming authenticators and cross-device authentication, depending on user hardware availability. |
|
Spec
|
Adds support for Digital Credentials API requests using JSON-based messages over hybrid transport. Support is indicated by the |
|
Use Case
|
Browsers implementing the Digital Credentials API over cross-device hybrid transport. |
|
Yubico Support
|
Transparent to SDK usage—Yubico SDKs use CBOR when communicating with YubiKeys directly. |
CTAP 2.2 defines a JSON-based message format for Digital Credentials API requests exchanged over hybrid transport channels. This allows browsers to process CTAP-compliant requests and responses without CBOR decoding at the JavaScript layer. The core protocol continues using CBOR for all direct CTAP communication.
|
Spec
|
Richer authenticator self-description including PIN complexity policies, attestation formats, UV counters, and more. |
|
Use Case
|
Applications that adapt their behavior based on authenticator capabilities. |
|
Yubico Support
|
Available in Yubico.NET SDK v1.14.0+, yubikit-android v2.9.0+, python-fido2 v2.0.0+, and exposed via libfido2/fido2-token. |
CTAP 2.2 expands the authenticatorGetInfo response with several new fields:
| Field | Purpose |
|---|---|
|
Number of user verifications performed since the last PIN entry. Supports adaptive client logic—for example, determining whether a PIN prompt can be deferred. |
|
List of attestation statement formats supported by the authenticator. Allows relying parties to select a preferred format for verification without trial-and-error. |
|
Boolean indicating whether PIN complexity policy is enabled on the authenticator. Platforms should check this field before presenting PIN entry UI and adjust guidance accordingly. |
|
Maximum PIN length the authenticator will accept. Complements |
|
Optional URL pointing to device-specific PIN composition rules. When present, platforms should offer a link when rejecting a PIN for complexity reasons, directing users to the applicable policy documentation. |
| SDK | CTAP 2.2 Support | Notes |
|---|---|---|
python-fido2 |
✅ Full Support |
v2.0.0+ supports PPUAT, |
Yubico.NET SDK |
✅ Extensive Support |
v1.14.0+ supports PPUAT, PIN complexity policies, |
yubikit-android |
✅ Good Support |
v2.9.0+ supports PPUAT, |
libfido2 / fido2-token |
✅ Full Support (v1.17.0+) |
v1.17.0+ supports most CTAP 2.2 features. Check the libfido2 release notes for specific feature coverage. |
yubikit-swift |
⚠️ Limited |
Modern Swift SDK for iOS/macOS. CTAP 2.2 feature support under development. |
yubikit-ios (Objective-C) |
⚠️ Limited |
Legacy Objective-C SDK. Missing most CTAP 2.2 features. Consider yubikit-swift for new projects. |
|
Note
|
Feature Coverage: Hybrid transport and JSON messaging are handled by browsers and operating systems, not SDK implementations. |