PicoKeys Vault vs. CXP/CXF: why deferred recovery changes the trust model
Passkey portability is often described as a problem of moving a private key from one authenticator to another. That description is incomplete. The important design questions are:
- Must the destination authenticator already exist when the source exports?
- Can an intermediate storage or provider decrypt the credential?
- Is the mechanism designed for a device, or for host credential providers?
PicoKeys Vault and FIDO’s Credential Exchange Protocol and Format answer those questions differently.
The short version
Vault was designed for deferred recovery without trusting an intermediate provider. One enrolled Pico FIDO device can establish a Vault domain. A credential can then be exported to an opaque artifact, stored anywhere, and imported into a device that is purchased and enrolled later. Additional devices can join the domain afterward by sharing the Vault secret.
CXP/CXF was designed as an exchange layer between host credential providers. In a direct or indirect exchange, the importing provider prepares the request and cryptographic parameters before the exporter creates the response. A passive file or object store does not need to see the private key, but the final importing provider does. If an intermediate provider imports from A and later exports to B, it becomes a key-handling endpoint and must access the credential.
ARKG answers a different question: how can a party derive a corresponding private key for a public key generated elsewhere? It can support a new paired-key design, but it is not a complete recovery or credential-portability protocol.
The difference is not simply “both use encryption.” It is who must exist, and who must be trusted.
| Property | PicoKeys Vault | CXP/CXF direct | CXP/CXF indirect | CXP/CXF self | ARKG |
| Initial deployment | ✅ One device is enough; more can join later | ❌ A and B must participate | ❌ A and B, or prepared provider endpoints, must exist | ✅ One provider can create a backup; replacement is unspecified | — Not a backup deployment model |
| Destination exists before export | ✅ No | ❌ Yes | ❌ Yes, through B’s request or a prepared provider | ✅ No separate destination for backup creation | — Not specified as a replacement flow |
| Passive storage sees the private key | ✅ No by design | — Not the mode’s purpose | ✅ No; it only relays ciphertext | ✅ Storage need not have the secret | — Not a backup artifact |
| Intermediate provider sees the private key | ✅ No intermediate provider is required | ❌ Yes, if M imports and later exports | ❌ Yes, if M is a provider rather than passive storage | ❌ The self provider handles the credential | — Not provider migration |
| Long-lived shared secret | ❌ Required across Vault devices | ✅ No | ✅ No | ❌ Permitted, but its lifecycle is not defined | ✅ No shared secret; the private seed is retained by the delegating party |
| Recovery after A is gone and B did not exist | ✅ Supported | ❌ Not directly | ❌ Not directly | ❌ Replacement recovery is unspecified | ❌ Not generic |
| Existing credential recovery | ✅ Supported | ✅ If the credential is exportable | ✅ If the credential is exportable | ✅ If the credential is exportable | ❌ Not by itself; the ARKG relationship must exist at creation |
| Same credential at the RP | ✅ Reuses the credential material | ✅ CXF carries the credential material | ✅ CXF carries the credential material | ✅ Provider backup can retain the credential material | ❌ ARKG alone does not define the credential ID or RP record |
| Device-native CTAPHID path | ✅ Yes | ❌ No | ❌ No | ❌ No | — Not specified |
The symbols describe the security and deployment result for that row. They are not a claim that one mechanism is universally better.
Vault starts with one device
Vault treats the Vault domain secret as the recovery capability. The storage layer receives an authenticated encrypted artifact, not a credential that it can decrypt. It can be a local file, removable media, or an untrusted object-storage service. Its role is availability and delivery, not key custody.
This means a Vault deployment can begin with one device:
A establishes the Vault domain
-> A exports a credential artifact
-> storage retains the opaque artifact
-> A may be lost
-> B is purchased and enrolled later
-> B imports the credentialThe same domain can be extended later with more devices. They do not all need to be present during the initial export, and a future device does not need to generate a public key before the artifact is created.
The trade-off is deliberate: devices in the domain share a long-lived recovery secret. That secret must be protected. Vault removes the need to trust a storage or migration provider with the credential private key; it does not remove the need to protect the domain’s recovery capability.
CXP/CXF is a host-provider exchange layer
CXF describes credential data. For passkeys, its `key` field represents the private key as portable PKCS#8 data. CXP defines how exporting and importing credential providers negotiate and protect the exchange.
The current CXP draft is built around host/provider objects and file-oriented exchange. Its request and response documents use JSON. The credential payload is an archive containing separately encrypted JWE files, with DEFLATE defined as an archive algorithm. CXP deliberately does not assume a particular transport channel.
That makes CXP useful for provider migration, including offline and air-gapped workflows. It also means CXP/CXF is not a CTAP or CTAPHID-native credential protocol. PicoKeys Vault is implemented in Pico FIDO’s device-native FIDO vendor-command path, including CTAPHID vendor commands.
Direct, indirect, and self modes
Direct mode is the simplest exchange. B creates an export request, A encrypts the credential for B, and B decrypts and stores it. B is the importer and sees the private key as part of storing the credential.
Indirect mode changes how the files move, not who can decrypt them. B still creates the request. A creates a response that can be written to a filesystem or passed through object storage. The passive storage layer does not see the private key, but B later decrypts the response and does.
This distinction is easy to miss. Indirect CXP can avoid simultaneous connectivity, but it does not make the destination-independent. B, or a provider acting on B’s behalf, must exist and prepare the request before A exports.
Self mode is the closest CXP concept to an external backup artifact. The exporter and importer are the same provider, and the draft says that a symmetric key supplied by the credential owner or an Authorizing Party may be used to derive the response-encryption key. The draft does not define how that secret is generated, shared, stored, recovered, or bound to a replacement authenticator. Self mode is therefore a protocol hook, not a complete Vault-like recovery architecture.
What happens with an intermediate provider?
Consider this sequence:
A -> M -> BIf M is only a passive storage service, CXP can keep the credential encrypted while it passes through M. The actual CXP destination is B.
If M is a credential provider, M is the importer for A’s exchange. M decrypts and stores the credential. When M later exports to B, M becomes the exporter and must access the credential again. M is not a blind relay; it is a trusted key-handling provider.
Vault does not need M in either role. A writes an artifact for the Vault domain, storage carries it, and B joins the domain later. That is the core zero-trust property: the intermediary does not need to become a credential provider.
Where ARKG fits
ARKG is a cryptographic construction for deriving corresponding private keys from a retained seed and a key handle. It can support a paired backup-key design, but it is not a generic backup protocol for existing WebAuthn credentials.
In a new ARKG-aware design, a backup authenticator may receive a related or newly derived key. Making a relying party treat that as the same credential would require additional policy around the credential ID, public key, counters, attestation, and WebAuthn record. ARKG itself does not define those rules.
Choosing the architecture
Choose CXP/CXF when the requirement is standardized migration between host credential providers and the destination can prepare before export.
Choose ARKG when a new credential system can be designed around derived keys and retained seed material.
Choose Vault when recovery must work after the source is gone, the destination may not exist yet, and passive storage or an intermediate provider must not receive the credential private key. Vault is also prepared for and optimized around the device-native CTAPHID vendor-command path, rather than CXP/CXF’s host-provider JSON, JWE, and archive exchange.
The key architectural choice is not whether the artifact is encrypted. It is whether recovery is encrypted for a specific destination, or for a domain that a future destination can join.