PXP: Proximity Exchange Protocol for Passkeys & IDs

1. Introduction: What is the Proximity Exchange Protocol#

The Proximity Exchange Protocol (PXP) is the FIDO Alliance's name for the protocol behind passkey sign-in with a QR code: a website on a laptop shows a code, a phone scans it and unlocks with a fingerprint or face, and the laptop is signed in with a passkey that lives on the phone.

Until 2026 that protocol was a chapter inside the Client to Authenticator Protocol (CTAP), the FIDO specification that describes how a browser talks to a security key. The chapter was called the hybrid transport, and engineers still call it caBLE, after the older "cloud assisted BLE" name that survives in some header fields. In July 2026 the FIDO Alliance published the chapter as a separate Working Draft called the Proximity Exchange Protocol. The CTAP 2.3.1 Working Draft of May 2026 already replaces its own hybrid transport chapter with a pointer to PXP.

This article covers four questions:

1. Why does the protocol matter for anyone who is not writing a browser or a phone OS?
2. How does PXP work, in plain terms?
3. What is the difference between PXP and cross-device authentication (CDA), and what changed against the CTAP hybrid transport?
4. Where does the specification stand, and what is the timeline?

2. Why do we need the Proximity Exchange Protocol?#

Three groups have a reason to follow this specification and none of them implements it.

• Everyone who runs passkeys has a cross-device path. A user who registered a passkey on their phone, opens the site on a desktop that has no passkey and picks the phone option lands in the QR code flow. That flow adds steps compared with a local passkey and fails for its own reasons, often around Bluetooth. Its transport is now being reworked underneath, and a relying party cannot opt in or out. The changes show up in login success and login duration without any release on the relying party's side.
• Everyone who will verify ID wallets across devices will use the same channel. When a browser at a car rental counter asks a customer's phone for a mobile driver's license or an EU wallet credential, the request travels over PXP. A wallet on the same device as the browser does not need it. For the cross-device case the protocol decides whether the flow works without the phone being online and how the two devices find each other.
• Everyone who reads the specifications now has to read three documents where there used to be one. CTAP 2.3 is the last Proposed Standard that carries the full hybrid transport chapter, CTAP 2.3.1 points elsewhere and PXP is where the flow now lives.

3. Problem: Why the QR code flow got its own specification#

The hybrid transport was written for one job: using a passkey on a phone, for registration or login, from a laptop that does not have that passkey. The phone stands in for a security key, and a Bluetooth advertisement that the laptop has to prove it received shows that the two devices are within radio range of each other.

Two things then happened to that design.

First, phones stopped being only passkey holders. They now carry mobile driver's licenses and EU wallet credentials, and a browser that wants to see one of those speaks the Digital Credentials API rather than the language of security keys. CTAP 2.2 (July 2025) bolted those requests onto the hybrid transport as a set of JSON messages, which left a protocol about authenticators carrying traffic that has nothing to do with authenticators.

Second, up to CTAP 2.2 all data of the exchange travelled through a relay server on the internet, called a tunnel service. Two devices sitting next to each other sent their traffic through a data center, and both of them needed to reach it. A guest checking in at a hotel terminal in the basement, where the terminal is on a cable but the phone has no reception, could not complete a flow that only needs thirty centimeters of air. CTAP 2.3 (February 2026) answered that with a direct Bluetooth data channel between the two devices, still inside the CTAP chapter.

PXP is the third step: it takes the whole chapter out of CTAP so that a protocol about proximity and channels no longer sits inside a protocol about security keys, and it adds an NFC tap as a way to start.

4. How PXP works in three stages#

The specification splits the exchange into invocation, channel negotiation and communication. The proximity check is the first part of the negotiation stage. The diagram below follows a QR code sign-in through all three.

4.1 Invocation: three ways to start#

The two central fields in the QR code are a public key that identifies the laptop and a random secret that only a phone which actually scanned the code can know. The rest of the exchange is built on those two values. Next to them the code carries housekeeping: which relay domains the laptop knows, a hint whether a registration or a login follows and the list of data channels the laptop supports. Its format is squeezed hard, because every character costs space in the QR code.

The code is a FIDO:/ URI. Every URI scheme a browser recognizes, https: and mailto: included, has an entry in a registry kept by IANA, the body that maintains the internet's naming lists. The fido scheme has held a provisional entry there since September 2021 and the draft asks for permanent status, which is the difference between an entry that can be withdrawn and one that implementers can rely on.

Two alternatives avoid the code entirely:

• Saved link: if the phone was linked during an earlier scan, the laptop reaches it through the remembered relay without showing anything. If the user has unlinked the device, the relay says so and the laptop forgets it. This existed in CTAP already.
• NFC tap: the user taps the phone against the other device, which hands over the same data the QR code would have carried. This entry point is new in the PXP draft.

4.2 Proximity: what the Bluetooth advertisement is for#

After scanning, the phone sends out a Bluetooth Low Energy advertisement: a short encrypted beacon, 20 bytes plus an optional suffix, that only a laptop holding the QR secret can decrypt and match. It carries no login data. The laptop has to prove in the following handshake that it received the beacon, which shows that the two devices are within Bluetooth range of each other. The diagram below shows what that buys.

Without the proximity check an attacker only needs a convincing page. With it, they need a Bluetooth radio near the victim.

The advertisement can carry one more thing: if the phone offers a direct Bluetooth data channel, it appends the port number for that channel to the beacon. That is where the proximity proof and the data transfer meet, and it is why Bluetooth plays two separate roles in PXP.

4.3 Communication: picking a channel#

Once proximity is settled, the two devices open an encrypted connection that only they can read. The cryptography here is unchanged since the early hybrid transport.

Before that handshake, the two devices agree on how the data should travel. The laptop lists the channels it supports in the QR code, the phone compares that list with its own and picks one. It may try more than one and keeps the first that connects. Two channels are specified, and the choice decides whether the flow survives without internet.

The relay channel is the one every hybrid flow has used since the beginning. The specification currently assigns exactly two relay domains, cable.ua5v.com and cable.auth.com. The direct Bluetooth channel arrived with CTAP 2.3: the phone opens a Bluetooth L2CAP server socket, announces its port in the proximity beacon, the laptop connects to it, and the two devices talk with no server in between. Ultra-wideband is named as a further candidate in both CTAP 2.3 and PXP, without a defined channel yet.

Whatever the channel, the payload is one of four things: a passkey registration, a passkey login or a Digital Credentials request for presenting or for issuing a credential.

Both sides should still support the relay. The draft says so explicitly, because the direct Bluetooth channel relies on L2CAP and extended advertising, two optional Bluetooth features that are not available on all devices.

5. PXP vs CDA and vs the CTAP hybrid transport#

The terms PXP and CDA sit on different levels, which the diagram below pulls apart.

Cross-device authentication is what the user does, signing in on one device with a credential that lives on another. PXP is the protocol that carries it. Asking whether PXP replaces CDA is like asking whether HTTP replaces online shopping.

Against its own history the picture is a staircase. The table lists what each revision brought, so that the PXP draft gets credit only for what it actually adds:

The handshake and the key derivation carry over unchanged through all three columns. The QR encoding gained one field in CTAP 2.3, the list of supported channels, and is otherwise the same. Anyone who has implemented the hybrid transport will recognize almost every line of the draft.

6. Advantages and limits#

6.1 What gets better, and which revision brought it#

• The phone no longer needs to be online (CTAP 2.3). The hotel basement works, and so does a warehouse or a guest network that blocks the relay. The laptop still needs to reach the website, since the sign-in itself happens there.
• No detour through a data center (CTAP 2.3). A direct Bluetooth connection removes the relay from the path. How much time that saves depends on the devices.
• A tap instead of a scan (PXP). NFC takes the camera out of the flow, which helps users who struggle with QR codes.
• ID requests get a proper home (PXP). Asking a wallet on another device for a mobile driver's license no longer rides on a specification about security keys.

6.2 What stays hard#

• The direct channel is optional. It needs Bluetooth features that are not available on all devices, so every implementation has to keep the relay as a fallback. Whether a given phone or browser offers the direct channel today is a platform decision the specifications do not track.
• Bluetooth is still the weak link. A common cause of a hanging QR code sign-in is Bluetooth being off, blocked by policy or flaky on one laptop model, and PXP keeps the proximity proof exactly as it was.
• It is a Working Draft. The document says it may change, has no official standing and is not a basis for implementations.
• The flow is still a fallback. Cross-device sign-in adds steps compared with a local passkey, and a rollout that leans on it will see it in the numbers.

7. Status and timeline of the specification#

PXP is not a finished standard. The FIDO Alliance publishes specifications in stages, from Working Draft through Review Draft to Proposed Standard, and PXP is at the first of them. The document's own status section says it "is not intended to be a basis for any implementations as the Specification may change" and that it "has no official standing of any kind and does not represent consensus of the FIDO Alliance".

The steps so far:

• CTAP 2.2, Proposed Standard, 14 July 2025. The hybrid transport is chapter 11.5. All data goes through the relay. The phone is called a Credential Provider Hosting Device. JSON messages for the Digital Credentials API are added in chapter 7.6.
• CTAP 2.3, Proposed Standard, 26 February 2026. Still chapter 11.5, now with the direct Bluetooth L2CAP data channel, ultra-wideband named as a further option and the phone renamed to Credential Manager Hosting Device.
• CTAP 2.3.1, Working Draft, 29 May 2026. Chapter 11.5 shrinks to one paragraph that says the hybrid channel "is now described by the Proximity Exchange Protocol". The JSON messages chapter says the same.
• PXP 1.0, Working Draft, 17 July 2026. The standalone document, with contributors from Okta and Google. New against CTAP 2.3: NFC-initiated transactions and the request to turn the provisional IANA entry for the fido scheme, which dates from 2021, into a permanent one.

So the answer to "is PXP the successor of the hybrid transport" is yes in the drafts and not yet in a published standard. The last Proposed Standard, CTAP 2.3, still carries the full chapter. At the time of writing no date for a PXP Review Draft or Proposed Standard has been published, and the draft lists no previous versions.

8. What this means for relying parties#

Nothing in PXP requires a change on the server. A cross-device ceremony arrives as an ordinary WebAuthn assertion, and the transport that carried it is not something a relying party chooses.

The change is in what to measure. Cross-device flows add steps that local ones do not have, they fail for their own reasons, and the share of logins ending up in them says how well passkeys are spread across a user base's devices. As phones and browsers pick up the direct channel and the NFC start, that share and its failure pattern will shift without any release on the relying party's side.

9. How Corbado can help#

Corbado Observe, the authentication observability layer, makes the cross-device path visible as its own population. It records the AAGUID, the transports and the backup state of every credential and resolves each AAGUID against the FIDO Metadata Service and a catalog of platform providers, so a credential reads as "iCloud Keychain" or "Google Password Manager" rather than as a hex string.

• Passkey Insights groups credentials by authenticator, transport and sync status over time. Transports are hints recorded at registration, not a measurement, so this gives a rough picture of how much of your credential base reports the hybrid transport at all, as opposed to how often the cross-device path is actually used.

  See Passkey Errors in Corbado Observe →

• Passkey Errors collapses failed ceremonies into flavors keyed on the subflow, the step, the error name and a duration bucket. Cross-device failures cluster on their own steps and durations, which separates them from a general dip in login success.

• Inventory reports which authenticator classes your user base carries, the input for deciding whether cross-device is a rare fallback or load bearing for you.

10. Conclusion#

PXP is mostly a tidy-up. Taking the QR code flow out of CTAP gives ID requests a transport that was not designed around security keys, and the NFC tap adds a way to start the flow without a camera. The technical change that matters most to users, the direct Bluetooth data channel, arrived one revision earlier with CTAP 2.3 and is carried over unchanged.

The practical impact is smaller than the new name suggests. The proximity proof and the cryptography are the same as before, the direct channel is an optional device feature, and the document is a Working Draft that says so on the front page.

For anyone running passkeys today, one number is worth pulling now: the share of logins that goes through the cross-device path. Every later change to the transport will be measured against it.

Frequently Asked Questions#

Is PXP a replacement for cross-device authentication?#

No. Cross-device authentication describes what the user does, namely signing in on one device using a credential that lives on another one. PXP is the protocol underneath that flow. Until 2026 it was a chapter inside CTAP called the hybrid transport. The Working Draft of July 2026 moves that chapter into its own document, so the QR code sign-in that browsers and phones ship today is the flow PXP describes.

Does PXP still need an internet connection?#

The phone does not necessarily. Up to CTAP 2.2 all data of the exchange went through a relay server on the internet, so both devices had to be online. CTAP 2.3 added a direct Bluetooth connection between the two devices and named ultra-wideband as a further option. PXP carries both over and still recommends the relay as a fallback, because the direct Bluetooth channel depends on device features that are not available everywhere. The device that shows the QR code still needs to reach the website it is signing in to.

Why does the QR code flow need Bluetooth at all?#

The Bluetooth advertisement is the proof of proximity. Without it an attacker could put a QR code on a phishing page and talk a victim into scanning it from anywhere in the world. Because the phone requires the laptop to prove it received the advertisement, the attacker would need a Bluetooth radio near the victim. Since CTAP 2.3 Bluetooth can also carry the data itself over a direct connection, but that is a second, optional use.

Can PXP carry more than passkeys?#

Yes. Besides passkey logins it carries requests for the Digital Credentials API, which is how a browser can ask a wallet on another device for a mobile driver's license or an EU wallet credential. The specification calls the phone a Credential Manager Hosting Device, because it can act as a passkey provider or as an ID wallet.

What is the status of the PXP specification?#

PXP 1.0 is a FIDO Alliance Working Draft published on 17 July 2026, with contributions from Okta and Google. The draft states that it has no official standing and is not intended as a basis for implementations because it may still change. The CTAP 2.3.1 Working Draft of May 2026 already points to PXP instead of carrying the hybrid transport chapter itself. No date for a Review Draft or a Proposed Standard has been published.