Registering and Signing In
Registration and sign-in are both short. What matters is what people are asked to do at registration, because that is where lock-outs are prevented.
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
Registering
The user chooses to add a passkey, their device asks them to confirm with a fingerprint, face or PIN, and it is done. No password is chosen and nothing needs remembering.
Signing in
They pick their passkey and confirm on the device. There is nothing to type.
The reaction to expect is that it feels too easy to be secure. A short explanation — the device is proving it holds a key, and that key cannot be given to a fake site — prevents most of the resistance.
Register two, always
The single most important rule. One credential means one lost device is a lock-out, and devices are lost, replaced and dropped in water.
Two credentials on different devices makes that an inconvenience rather than a support call. Make it a requirement at enrolment rather than a suggestion — a suggestion produces a population with one each, and you find out when somebody's phone breaks.
Nickname the device
Users register several credentials, and without names they are indistinguishable. When somebody reports a lost phone, you need to know which one to remove — and if you cannot tell, the safe response is removing all of them, which locks them out entirely.
Prompt for a nickname at registration. It takes a moment and prevents that conversation.
Check the first sign-in works
Before the user leaves the screen. A credential registered but never tested is one they will discover is broken at an inconvenient moment.
What syncs and what does not
Some passkeys sync across a user's devices through their platform account; others are bound to one device — a hardware key, or a device configured not to sync.
That matters for recovery: a synced credential survives a lost phone, a device-bound one does not. Do not assume everybody's behaves the same way, which is another reason to insist on two.
Shared devices
A passkey belongs to whoever registered it. On a shared workstation that fits badly — a device-bound credential is effectively one person's. Portable security keys are usually the answer for shift-worked machines.
Worked example
At enrolment each user registers a laptop and a phone, names both, and signs in once with each before leaving the screen. Over the following year, four lost-phone reports are resolved by the user's second credential without any administrator involvement.
Recommendations
- Two credentials, enforced at enrolment.
- Require a nickname for each.
- Test the first sign-in before the user leaves.
- Issue security keys for shared workstations.