Cannot sign in with a passkey
The passkey prompt fails, never appears, or the account is refused — during enrollment or at a later sign-in.
Symptom
At the first-admin setup, at an invitation link, or on the ordinary login page, the browser's passkey dialog ends with an error, or the page says something went wrong. Sometimes no dialog appears at all. Sometimes the passkey works and the account is still turned away afterwards.
Check these first
- Note where it fails: during enrollment (setup or invite) or at sign-in. Enrollment failures are almost always configuration or device; sign-in failures are almost always the wrong device or an expired session.
- Try a normal window of an up-to-date Chrome, Edge or Safari on the same device. Private windows and old browsers are a frequent cause on their own.
- Have an admin check the user under People → Users: is the account enabled, and does People → Sessions show a session that just ended?
Possible causes
WEBAUTHN_RP_ID does not match the address (self-hosted)
How to tell: On your own server only. Registering the first admin at /setup, or any later enrollment, ends with a generic error such as Something went wrong, on every browser and every device.
Fix: A passkey is bound to a relying-party ID, and the browser refuses one that does not match the address bar. WEBAUTHN_RP_ID in .env must be the bare access domain, access.example.com, which is equal to or a parent of every host you open (manager.access.example.com included). Not manager.…, not the registrable domain alone. Correct it, restart the manager and retry (see deploy files and .env).
The passkey lives on another device
How to tell: Sign-in worked last week on the phone and fails today on the laptop. The dialog offers no matching passkey, or asks for a security key that was never used.
Fix: A passkey is stored by the device or its platform account, and reaches another machine only if that account syncs it (iCloud Keychain, Google Password Manager). Sign in from the device that holds it, or choose the browser's "use another device" option and scan the QR code with that phone. If TOTP recovery was set up, sign in with the code and register a second passkey on this device. Otherwise an admin can send a fresh invitation (see passkeys and recovery).
The invitation link has expired
How to tell: The vendor opens the invite link days after it was sent and the page says the invitation is invalid or expired, before any passkey dialog.
Fix: Invitations live for the lifetime set under Infrastructure → Policy and cannot be reused once spent. Send a new one from People → Invites; if SMTP is not configured, copy the one-time link from the invite row and pass it on yourself (see inviting the user and invite lifetime).
The browser or OS does not support passkeys
How to tell: No dialog appears at all, or it appears and immediately closes. Typical on an old browser, a Linux desktop without a platform authenticator, a locked-down corporate build, or a private window.
Fix: Use a current Chrome, Edge, Firefox or Safari in a normal window. Where the machine has no built-in authenticator (no Windows Hello, Touch ID or screen lock), register a hardware security key over USB or NFC, or use a phone as the authenticator through the QR option. There is no password fallback by design; the recovery path is TOTP, set up in advance.
The account is disabled or hit a session limit
How to tell: The passkey dialog succeeds, then the page refuses the account; or a working session ends abruptly in the middle of the day and asks for sign-in again.
Fix: Under People → Users, a disabled user cannot sign in regardless of credentials; enable the account or ask why it was disabled. A session that ends on its own is the Session controls on Infrastructure → Policy doing their job: idle timeout, maximum lifetime, or the concurrent-session cap when the vendor opened a second browser. Signing in again is the expected recovery; raise the limits only if they are wrong for your case (see session controls).
If it is still not solved
- Whether it fails at enrollment (setup or invite) or at sign-in
- Browser name and version, operating system, normal or private window
- The exact text the page shows after the dialog closes
- Self-hosted: the WEBAUTHN_RP_ID value and the address in the bar
- The matching Audit entries for that user