Passkeys & WebAuthn

Passkey are phishing-resistant credentials backed by the WebAuthn standard. The user holds them on a device or in a password manager; the workspace never sees a shared secret. Sign-in is one tap; there is no password to intercept, no MFA code to phish. This page covers the user-side enrollment flow, the admin-side attestation policy (which authenticator families you allow), and the audit posture.

TL;DR — Users enroll passkeys from Account → Security → Passkeys. Admins decide which authenticators are acceptable from Settings → Security → Attestation policy — choices range from "any" through "hardware keys only". Passkeys satisfy the strictest MFA policy in one tap.

How passkeys work

The shape of a passkey, in three sentences:

• A private key lives on the user's device or syncs through their password manager (Apple iCloud Keychain, Google Password Manager, 1Password, Dashlane, Bitwarden, etc.).
• A public key is stored against the user's AxisSynapse account.
• On sign-in, the browser signs a fresh challenge from the platform with the private key; the platform verifies the signature against the public key. There is no shared secret to phish.

Each passkey carries an AAGUID that identifies which model of authenticator made it. Admins use AAGUIDs to allow, deny, or require specific families.

User-side: enrolling a passkey

The user flow lives at Account → Security; the steps below are the canonical happy path.

1. 1

   Open Account → Security → Passkeys

   Click the avatar in the top bar → Account → Security → scroll to Passkeys.

2. 2

   Click "Add passkey"

   A drawer asks for an optional Device label — left blank, AxisSynapse auto-names the passkey from the AAGUID family ("iCloud Keychain", "Windows Hello", "YubiKey", "1Password").

3. 3

   Verify the local authenticator

   The browser surfaces the native enrollment prompt: Face ID, Touch ID, Windows Hello, the device PIN, or a tap on a hardware key.

4. 4

   Confirm enrollment

   The new passkey appears in the list with its label, AAGUID family, and creation date. Subsequent sign-ins offer it automatically in the browser's autofill chrome.

Admin-side: the attestation policy

AxisSynapse enforces the attestation policy at enrollment time — if a user tries to register an authenticator that violates the policy, the enrollment is rejected with a clear message.

1. 1

   Open Settings → Security → Attestation policy

   The page shows the current mode + a preview of which categories would be accepted today.

2. 2

   Pick a mode

   Four modes available — see the table below. The picker shows the impact on user enrollment in plain language.

3. 3

   (If Allowlist mode) pick the AAGUID families

   The picker is organized by category — FIPS-validated YubiKeys, other hardware tokens, platform authenticators (Windows Hello / iCloud Keychain / Android), and synced password-manager passkeys. Tick the categories that satisfy your security posture.

4. 4

   (Optional) add custom AAGUIDs

   For authenticator families not in the catalogue, paste the AAGUID GUID into the Custom AAGUIDs field with a label.

5. 5

   Run a Test enrollment

   The Test card at the bottom simulates an enrollment of each AAGUID and confirms whether the current policy would accept it.

6. 6

   Click "Save"

   The new policy takes effect on the next enrollment. Already-enrolled passkeys are not retroactively revoked.

The four attestation modes

Every field, explained

What appears in the audit log

• ACCOUNT_WEBAUTHN_CREDENTIAL_ENROLLED / ..._REVOKED — passkey lifecycle.
• ACCOUNT_WEBAUTHN_CREDENTIAL_REVOKE_BLOCKED — the user tried to remove their last factor; the last-factor guard refused.
• ACCOUNT_WEBAUTHN_SIGNIN_SUCCESS / ..._FAILED — every passkey sign-in attempt.
• ACCOUNT_WEBAUTHN_COUNTER_REGRESSION — critical. A passkey returned a sign-counter that went backward, which suggests the credential has been cloned. Revoke the affected credential immediately and investigate.
• ACCOUNT_WEBAUTHN_ENROLL_BLOCKED_BY_POLICY — an enrollment was rejected by the attestation policy. Aggregate to see which families the workforce is reaching for so you can refine the allowlist.
• TENANT_ATTESTATION_POLICY_UPDATED — every policy change.

Common gotchas

• "Users on iCloud Keychain can't enroll." You picked DENY synced mode. Either switch to ALLOWLIST and add the password-manager category, or accept the trade-off.
• "My YubiKey appears as an unknown family in the audit log." The AAGUID isn't in the curated catalogue. Add it under Custom AAGUIDs with a friendly label so subsequent audit rows are self-explanatory.
• "A sign-in tried a passkey then fell back to password." The user has both enrolled. To force passkey-only, set the workspace MFA policy to Phishing-resistant only (see Multi-factor authentication policy).
• "The user's passkey disappeared after a device wipe." Synced passkeys live in the user's password manager and survive device wipes; device-bound passkeys do not. Encourage at least two enrolled passkeys per user.

Troubleshooting

| Error code | What it means | Fix | |---|---|---| | WEBAUTHN_ATTESTATION_DENIED | The attestation policy refused this enrollment. | Pick an acceptable authenticator family, or have an admin add the AAGUID. | | WEBAUTHN_COUNTER_REGRESSION | The sign counter went backward. | Revoke and re-enroll the credential. | | WEBAUTHN_USER_NOT_VERIFIED | The local verification step (PIN / biometric) was skipped. | Re-attempt and complete the local prompt. | | WEBAUTHN_TIMEOUT | The user took too long to respond to the local prompt. | Retry; ensure the authenticator is unlocked and present. |