Client to Authenticator Protocol (CTAP) v2.3

Note

FIDO Alliance specification describing an application protocol for communication between a roaming authenticator and a client or platform, with its transport bindings (CTAP 2.3).

Summary

Purpose

The FIDO Alliance’s Client to Authenticator Protocol (CTAP), version 2.3, published as a Proposed Standard on 26 February 2026, organises the dialogue between a “roaming” authenticator, for example a smartphone, and the client platform, for example a PC, on which the user interacts with a relying party CTAP 2.3, Proposed Standard, February 26, 2026 CTAP 2.3, § 1. Introduction[](#intro):

For eIDAS 2, the relevant part is the hybrid transports. They separate the proof that the client device is physically close to the authenticator, provided by Bluetooth Low Energy (BLE) advertisements, from the channel that carries the messages. This channel goes either through a network service called a tunnel service, or through local communication (BLE, ultra-wideband, etc.) CTAP 2.3, § 11.5. Hybrid transports[](#sctn-hybrid).

Who it applies to

The text of Annex II to Implementing Regulation 2024/2982 itself names CTAP 2.3 only in two notes, worded with “should” Annex II. That annex also makes applicable, with adaptations, clause 6 of specification ETSI TS 119 472-2 V1.2.1 Annex II, which names CTAP in a requirement (see below). The notes accompany two requirements which, for their part, concern the wallet: in cross-device flows, it verifies, using the mediating API, that the interacting device is in close physical proximity. It does so through a secure, direct local communication channel that requires user action Annex II. The general obligation rests with wallet providers, who ensure support for the specifications in that annex Art. 5(1).

The notes concern other actors: operating systems, browsers, mediating APIs and any other layer outside the control of the wallet Annex II. What should be preferred over the use of CTAP Hybrid tunnel services is:

It is this local channel that these layers “should” use, both to check proximity and to transfer data between the two devices. According to the same notes, CTAP 2.3 makes it possible to use BLE for the proximity check and, where both devices implement it, to transport the data Annex II.

Key points

• In the text of the annex, a recommendation. Both notes use the verb “should” Annex II.
• In the ETSI specification made applicable, a requirement. The annex gives new wording to requirements OIDFVP-HAIP-ADD-API-01, -04 and -05 of clause 6.5.2, but does not modify requirement -06 Annex II. That requirement concerns browsers and operating systems:

The article that refers to the annex, for its part, places the obligation on wallet providers Art. 5(1).

• A change from the intermediate standard. In version V1.2.1 of specification ETSI TS 119 472-2, requirement OIDFVP-HAIP-ADD-API-05 required the wallet, where the browser and the operating system allow it, to use the CTAP 2.2 hybrid flow described in section 11.5 of the CTAP document it cites ETSI TS 119 472-2 V1.2.1, § 6.5.2 Additional requirements. Annex II gives new wording to this requirement: the proximity check through a local channel Annex II.
• References dated differently. The ETSI specification cites CTAP as a Review Draft of 21 March 2023 ETSI TS 119 472-2 V1.2.1, § 2.1 Normative references; the annex, which only adds other normative references, does not replace that one and says “CTAP 2.3”, without a date Annex II. Implementing Regulation 2026/1731, which added this annex, dates CTAP 2.3 to 26 February 2026 in a footnote to its recitals amending Implementing Regulations (EU) 2024/2977, (EU) 2024/2979, (EU) 2024/2980 and (EU) 2024/2982 as regards applicable standards and specifications. This is the version contained in the corpus CTAP 2.3, Proposed Standard, February 26, 2026.
• Gatekeepers. According to a recital of the same regulation, in online cross-device flows, a local communication channel as enabled by CTAP 2.3 “should be preferred by gatekeepers” to using CTAP Hybrid tunnel services amending Implementing Regulations (EU) 2024/2977, (EU) 2024/2979, (EU) 2024/2980 and (EU) 2024/2982 as regards applicable standards and specifications. A recital explains the act; it does not create an obligation on its own.
• The local BLE channel. In CTAP 2.3, a BLE transfer channel can be established in addition to the WebSocket channel; the specification recommends always keeping WebSockets as a fallback CTAP 2.3, § 11.5.1.1.2. Bluetooth Low Energy[](#hybrid-ble-channel).

Passages of the acts that relate to it

• Annex II: requirements ISO/IEC 18013-ADD-API-05 and OIDFVP-HAIP-ADD-API-05 and their notes; requirement OIDFVP-HAIP-ADD-API-06 of the ETSI specification, unmodified. Clause 5.4, from which the first requirement comes, appears in the annex; in ETSI specification V1.2.1, clause 5 ends at clause 5.3.3 ETSI TS 119 472-2 V1.2.1, § 5.3.3 ISO/IEC-mdoc EAAP Response profile. This annex was added by Implementing Regulation 2026/1731 Art. 4.

Links

• Related standards: OpenID4VC-HAIP OpenID4VC HAIP 1.0, ISO/IEC 18013-7 ISO/IEC TS 18013-7:2025.
• Intermediate standard: ETSI TS 119 472-2 ETSI TS 119 472-2 V1.2.1.
• Learning path: step 3, the European wallet.

Written by Asphalia.