Passkeys are phishing-resistant, hardware-bound credentials that replace passwords entirely. For an AI control plane — a system where a single compromised operator account could direct dozens of autonomous agents — eliminating the password as an attack surface is not optional, it is architectural. WebAuthn is the browser and platform standard that makes passkeys work, and understanding the ceremony behind it helps you evaluate any platform claiming to support it. Passkeys sit within a broader authentication stack that also includes MFA for AI control planes: TOTP and backup codes and security policies covering passwords, sessions, and IP restrictions.

What makes passkeys different from passwords

A password is a shared secret. You know it, the server knows it (hashed), and an attacker who intercepts your traffic or compromises the server's credential store can extract it. Phishing exploits this: trick a user into typing their password on a lookalike site and the attacker has a working credential.

Passkeys break this model at the root. When you create a passkey, your device generates a public/private key pair. The private key never leaves your device — not even to the server. The server stores only the public key. When you authenticate, your device signs a challenge issued by the server, and the server verifies the signature against the stored public key.

Because the private key is bound to the device and never transmitted, there is nothing for a phishing site to steal. Even a perfect replica of your login page cannot capture a credential that is never entered. Origin binding, a core part of the WebAuthn specification, means the browser or platform enforcer checks that the Relying Party ID in the challenge matches the actual domain. A lookalike site gets a different origin check and the ceremony fails before the user even notices.

The WebAuthn ceremony in plain terms

WebAuthn defines two ceremonies: registration and authentication.

Registration starts when a server generates a challenge — a random, server-side nonce with a short expiry window. The server sends this alongside options describing the Relying Party (your application's domain and name) and acceptable authenticator types. The browser calls navigator.credentials.create(), which hands the request to the platform or a roaming authenticator (a hardware security key). The user confirms presence via biometric (Touch ID, Face ID, Windows Hello) or PIN. The authenticator signs the challenge with a freshly generated private key and returns an attestation object containing the public key and a credential identifier. The server verifies the attestation, validates the origin and RP ID, and stores the public key and an initial counter value.

Authentication starts with another server-generated challenge. The browser calls navigator.credentials.get(), naming the credential ID to use. The authenticator prompts the user for presence confirmation, signs the challenge, and returns an assertion. The server verifies the signature against the stored public key, checks the counter (to detect cloned authenticators), and issues a session.

The counter is a subtle but important detail. Each time an authenticator signs, it increments an internal counter. If the server sees an assertion with a counter that does not advance as expected, it signals a possible clone attempt worth investigating.

Why AI control planes specifically benefit from WebAuthn

Traditional web applications are user-facing. The account that logs in controls content — social posts, documents, preferences. The blast radius of a compromised credential is largely contained to that user's data.

An AI control plane is different. An authenticated operator can provision agents, configure guardrails, set spending budgets, modify routing rules, and read audit logs spanning the entire organization. In a multi-tenant architecture, the operator's permissions are bounded by role, but the roles themselves are powerful. A compromised admin account at the platform level could silently alter agent behavior across dozens of workflows, approve its own budget increases, or export sensitive audit data before anyone notices.

This threat profile makes the strength of the authentication mechanism a direct risk multiplier. Phishing-resistant authentication limits the damage an attacker who does not control a user's physical device can do, regardless of how convincing their social engineering is.

Hardware-bound credentials also matter for compliance posture. Regulations requiring strong authentication increasingly distinguish between possession factors (something you have) and knowledge factors (something you know). A passkey stored in a platform secure enclave satisfies possession in a verifiable way, whereas a TOTP code — generated from a seed that could be extracted from an insecure backup — offers weaker guarantees. Compliance frameworks that mandate strong authentication for AI systems, such as those described in SOC 2 for AI platforms, increasingly treat hardware-bound authentication as best practice rather than optional.

Authenticator types: platform vs roaming

WebAuthn supports two authenticator categories.

Platform authenticators are built into the device: the Secure Enclave on Apple silicon, the TPM on Windows machines, the Android Keystore. They use biometrics or device PIN as local confirmation. Credentials are synced across devices via the platform's cloud keychain (iCloud Keychain, Google Password Manager), so a credential registered on a MacBook is available on an iPhone using the same Apple ID. This sync is encrypted end-to-end; the private key is not supposed to leave the secure enclave boundary, though the exact guarantees depend on the platform vendor's implementation.

Roaming authenticators are external hardware security keys (FIDO2 keys). Not tied to a single device, they work on any machine with USB, NFC, or Bluetooth. The private key cannot leave the key's secure element and there is no cloud sync. The trade-off is logistics: users must carry the key, and losing it means you need a recovery path.

For most operators, platform passkeys offer a good balance of security and usability. For accounts with the highest privilege levels — organization owners, billing administrators, compliance officers — requiring a hardware key is a defensible policy choice. For how these role distinctions are defined and enforced, see RBAC and Custom Roles for AI Operations.

Credential management: registration, listing, and revocation

Passkeys are only as safe as your ability to manage them. Registration is the easy part. The harder operational questions are: how do your users know which credentials are active on their account, what happens when a device is lost or stolen, and how do you force re-authentication after a credential is revoked?

A sensible implementation maintains a per-user credential registry: each passkey has a server-side identifier, a recognizable label (device name and registration date), and a last-used timestamp. When a user reports a lost device, they locate the credential by label and delete it. The server stops accepting assertions from that credential immediately.

Replay protection matters too. The server-generated challenge must be single-use and expire quickly — five minutes is a common window. Storing it server-side and deleting it on first use (success or failure) prevents an intercepted challenge from being replayed.

How Praesidia is designed to approach passkeys

Praesidia is designed to incorporate passkey registration as part of the account security surface, alongside TOTP-based MFA and backup codes. The design holds to WebAuthn's fail-closed principles: a registration or authentication attempt that cannot be cryptographically verified is rejected, never silently accepted. Challenges are single-use and time-bounded, and authenticator counters are tracked per credential to support clone detection.

The credential management interface gives users visibility into which devices have registered passkeys and allows individual credential deletion without affecting other registered authenticators. This makes revocation surgical — you can remove a lost device without disrupting access from other registered devices.

The broader identity architecture integrates passkeys alongside RBAC, audit logging, and the platform's MFA policies, so operator accounts can layer multiple authentication factors according to the sensitivity of their role. For how all these identity controls compose together, see how to authenticate AI agents.

Common questions

Do passkeys replace TOTP or can both coexist? They address the same goal — proving possession — but through different mechanisms. TOTP uses a shared seed stored on both server and authenticator; passkeys use asymmetric cryptography with the private key never leaving the device. A well-designed platform allows both to coexist, so users who cannot use a passkey (no compatible device, enterprise policy restrictions) can fall back to TOTP. The two factors are not additive in the same session; they are alternatives within the same authentication step.

What happens if a user loses all their passkeys and backup codes? Account recovery is the hardest problem in passwordless authentication. Options include admin-assisted recovery (helpdesk verifies identity out-of-band and clears the affected credentials), email-based recovery flows gated behind step-up checks, or organizational recovery keys held by an account administrator. Each approach trades usability against the risk of social engineering the recovery path. There is no zero-risk answer, which is why some high-security deployments require hardware keys: they are harder to claim to have lost.

Is platform passkey sync a security concern? Platform keychain sync means a credential created on one device may be available on others linked to the same account. This is intentional and improves usability, but it extends the trust boundary to the platform vendor's sync infrastructure. For most use cases, this is an acceptable trade-off. For accounts handling highly sensitive operations, roaming hardware keys provide a stronger isolation guarantee, since the credential cannot leave the physical device.

Evaluating passkey support in any platform

When a platform advertises WebAuthn or passkey support, the questions worth asking are: does it enforce origin binding (RP ID correctly validated)? Does it store and check authenticator counters? Are challenges single-use and time-bounded? Does it provide credential management with revocation? And critically, does a verification failure result in a rejected attempt rather than a degraded or partial success?

The cryptographic properties of WebAuthn are only as strong as the server-side ceremony implementation. A system that skips verification steps to improve availability has not implemented WebAuthn — it has built a WebAuthn-shaped credential store with none of the phishing resistance. Understanding the ceremony gives you the vocabulary to ask the right questions of any platform you evaluate.

For more on how authentication integrates with the broader access control and governance model, see single sign-on for AI agent management: SAML and OIDC.