Control objective
A passkey is a WebAuthn discoverable public-key credential. The authenticator keeps a private key and the relying party stores the public key. Authentication signs a challenge and binds the response to the relying party identifier and origin. The private key is not sent to the server.
Ceremony and binding
During registration, the relying party creates a challenge and requests a credential for its relying party identifier. The authenticator creates a key pair after user verification or presence as required. During authentication, it signs the challenge and context. The relying party validates the signature, challenge, origin, relying-party binding, and credential state.
Phishing resistance
The authenticator binds use to the legitimate relying party. A credential registered for one domain cannot authenticate to a look-alike domain. This blocks the common real-time relay of a reusable password or one-time code when the browser and relying party apply the WebAuthn checks correctly.
Failure and residual risk
Synced passkeys depend on the security and recovery of the credential provider account. Device-bound passkeys need replacement and recovery planning. A passkey does not stop application authorization errors or theft of an existing session. Unsafe fallback authentication can remove the benefit.
Pomerium boundary
Pomerium can use an identity provider that supports passkey authentication. The provider performs the WebAuthn ceremony. Pomerium receives the federated result, not the private key. The operator must evaluate provider enrollment, sync, recovery, fallback, and assurance behavior.
Evaluation checklist
- Is registration initiated by the intended account and relying party?
- Does authentication validate challenge, origin, relying-party identifier, and signature?
- Is the credential synced or device-bound, and what recovery model follows?
- Can a weaker fallback bypass the passkey requirement?
- How is an authenticated session protected after the ceremony?
