Passkeys Overview
A passkey signs somebody in using a key held on their device rather than a password. There is nothing for them to remember and nothing for an attacker to steal from you.
Where to find it
Architect Panel → Security:
- Passkeys — registered credentials, their devices and last use
Architect Panel → Configuration:
- Site Settings — Enable Passkeys, and the prompt setting
Architect Panel → Security:
- Two-Factor Authentication — the alternative second factor
How it works
Registration creates a key pair on the device. The private half never leaves it — protected by the device's own biometric or PIN — and the platform stores only the public half. Signing in means the device proves it holds the private key.
What is stored here
- The credential identifier and the public key.
- A signature counter.
- An authenticator identifier — what kind of device or security key it is.
- Transports — how it can be reached: internal, USB, NFC, Bluetooth.
- A device nickname.
- Last used.
None of that is a secret. A breach of this table yields public keys, which are useless without private halves that never left users' devices — a materially better position than any password store, however well hashed.
Why phishing stops working
This is the substantive advantage and it is worth being precise about.
A passkey is bound to the site it was created for. Presented with a convincing replica on a lookalike domain, the device simply does not offer the credential — not because the user noticed, but because the domain does not match.
The most effective attack against passwords stops working, and it stops working without depending on anybody being alert. Two-factor authentication does not achieve this: somebody can be persuaded to type a one-time code into a fake site as readily as a password.
The signature counter
Each authenticator increments a counter as it is used, and the platform records it. A counter that goes backwards suggests a cloned credential — rare, and a real signal when it happens.
Passkeys or two-factor?
Passkeys are stronger, because they remove the password rather than adding to it. Two-factor remains the right answer for populations where passkeys are impractical, and the two can coexist while you move people across.
For administrators, passkeys should be the target.
They ship disabled
Nothing changes for anybody until you enable them, and enabling makes them available rather than compulsory.
Worked example
An organisation moves its twelve administrators to passkeys. Each registers a laptop and a phone. When a phishing campaign later targets them with a convincing lookalike domain, the credentials are not offered on the fake site and nobody can sign in to it — the attempt fails without depending on anybody spotting the domain.
Recommendations
- Start with administrators — the accounts worth phishing.
- Treat passkeys as the target, two-factor as the interim.
- Insist on two credentials per user from the start.
- Explain the phishing property — it is what justifies the change.