Passkeys

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.

Enabling Passkeys

Two settings govern passkeys. Both are worth understanding before switching either.

Where to find it

Architect Panel → Configuration:

• Site Settings — Enable Passkeys, and the prompt setting

Architect Panel → Security:

• Passkeys — registered credentials, their devices and last use

Enable Passkeys

Ships off. Turning it on makes passkeys available — users can register one and use it. It compels nobody and changes nothing for people who ignore it.

That is the right first step: enable, let people enrol, and see where you get to before considering anything stronger.

Prompt to Set Up a Passkey after Logon

Ships on. After signing in, a user without a passkey is invited to create one.

This is what actually drives adoption. Passkeys enabled with no prompt produces a feature almost nobody discovers — people do not go looking through their profile settings for authentication options they have not heard of.

The prompt is tracked per user

Worth knowing, because it is what makes the prompt tolerable. The platform records whether somebody has been prompted and when, so they are not asked on every single sign-in.

Somebody who declines is not nagged into resentment, and somebody who has never seen it still gets asked. That balance is the difference between a prompt that drives adoption and one that trains people to dismiss dialogs.

Prepare before you enable the prompt

The prompt will be the first most users hear of passkeys, so what they see matters. Send a short note first explaining what it is and why — a prompt arriving with no context is dismissed by people who assume it is optional noise.

One sentence works: your password may already be in a breach somewhere, and this means that does not matter.

Administrators first

Enable, ask administrators to register, and confirm the flow works on the devices and browsers your organisation actually uses. They are a small population, able to tell you what is awkward, and the accounts most worth protecting.

Decide recovery before you start

Somebody will lose their only credential. Work out now who can reset it, how they verify the caller, and what is recorded — before anybody is locked out.

Make that check at least as rigorous as the passkey it bypasses. An attacker who cannot phish a passkey will telephone your service desk instead, and a weak reset process quietly undoes the whole control.

Do not remove passwords yet

Enabling passkeys does not mean removing the alternative. Keep it until enrolment is genuinely complete and recovery has been tested with a real person.

Worked example

An organisation enables passkeys with the prompt on, having first sent a two-sentence explanation to all staff. Administrators register within a week. After a month, 60% of staff have registered at least one credential, entirely through the prompt — nobody had to be chased.

Recommendations

• Leave the prompt on — it is what drives adoption.
• Explain it briefly first, so the prompt is not a surprise.
• Design and test recovery before enabling.
• Keep passwords until enrolment is complete.

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.

Managing Credentials

Once passkeys are in use, the ongoing work is small: keeping the registered list meaningful, and removing what should not be there.

Where to find it

Architect Panel → Security:

• Passkeys — registered credentials, their devices and last use

Architect Panel → Activity:

• Activity Log — the record of a credential being added or removed

Architect Panel → Security:

• Permissions — who may manage other people’s credentials

What to review

• Users with only one credential. Each is a lock-out waiting to happen — chase them.
• Credentials unused for a long time. Usually a device that no longer exists.
• Accounts with none at all, where you expected coverage.

The last-used timestamp makes all three answerable without asking anybody.

Removing a lost device

Remove that credential promptly, and leave the others. This is where nicknames earn their place — without them you are guessing, and guessing wrong means either leaving a lost device registered or locking somebody out.

If the user cannot say which credential was on the lost device, removing all and re-enrolling is safer than leaving one you cannot identify.

Removal is an access request

Somebody asking you to remove a credential is asking you to weaken their account — which is exactly what an attacker would ask for. Verify them as rigorously as for a password reset, and record what you did.

Step-up re-authentication

Asking somebody to prove themselves again before something consequential, even though they are already signed in — changing bank details, exporting a large dataset, altering permissions.

It is a good control because it defends against the case ordinary authentication cannot: an unattended session, or somebody using a machine that was left signed in. Signing in an hour ago says nothing about who is at the keyboard now.

Use it sparingly

Applied to routine actions it becomes an obstacle people resent and click through without reading, which is worse than not having it — you have added friction and gained nothing.

Reserve it for actions that are consequential and irreversible, and be able to explain to a user why this particular action asked.

Passkeys make it painless

Re-authenticating with a password is enough of an interruption that people avoid designs requiring it. With a passkey it is a fingerprint — quick enough that it can be used where it genuinely helps.

Watch for repeated removals

An account whose credentials are removed and re-registered repeatedly is worth a look. It is usually somebody struggling with the technology, and occasionally something else.

Worked example

A quarterly review finds nine users with a single credential; all are asked to add a second and seven do. A lost laptop is reported and its named credential removed the same morning, leaving the user's phone working. Step-up re-authentication is required only for changing supplier bank details, where it is expected rather than resented.

Recommendations

• Chase single-credential users before they become lock-outs.
• Verify identity before removing anything.
• Reserve step-up for consequential, irreversible actions.
• Review unused credentials periodically.

Troubleshooting

Most passkey problems are a handful of causes, and most are resolved without removing anything.

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 → Activity:

• Error Log — technical failures around registration

Ask which device first

Nearly every report resolves faster once you know whether they are on the device that holds a credential. "It is not working" from somebody on a new laptop is a different problem from the same words on their usual one.

They are on a different device

The commonest cause by a distance. A device-bound credential exists on one machine, and a synced one requires being signed in to the same platform account.

The fix is usually to register a credential on the device they are actually using — which is also the moment to check they have a second one.

The browser does not support it

Older browsers, and some managed or restricted environments, do not offer the necessary interface. The symptom is the option not appearing rather than an error.

Check what they are using before assuming a fault, and keep an alternative sign-in route available for people you cannot move.

The device declined

A fingerprint not recognised, a PIN entered wrongly, or biometrics not set up on the device at all. The platform never sees why — it only sees that the device did not confirm.

The answer is on the device: check biometrics or a PIN are configured, then try again.

Registration appears to work but sign-in fails

Worth testing at registration for exactly this reason. If it happens, check the error log — this is the shape of problem that indicates a configuration issue rather than a user one.

They deleted the credential from their device

Users tidy up saved passwords and passkeys without realising what they are removing. The platform still holds the public half and the device no longer has the private one, so sign-in fails with no obvious cause.

Remove the stale credential and re-register.

Do not remove credentials as a first step

The instinct when something is not working is to clear it and start again. That turns a device problem into a lock-out if it was their only credential, and it discards the evidence.

Establish which device, which browser and what the device said, before removing anything.

The signature counter went backwards

Rare, and worth taking seriously — it suggests a cloned authenticator rather than an ordinary fault. Treat it as a security matter rather than a support ticket.

Worked example

A user reports passkeys "stopped working". They are on a replacement laptop, and their credentials are on the old one and their phone. They sign in with the phone, register the new laptop, and end with three credentials — resolved in two minutes and no credential removed.

Recommendations

• Ask which device before anything else.
• Never remove a credential first.
• Keep an alternative route for unsupported browsers.
• Escalate a backwards counter rather than clearing it.