Passkeys: rolling out passwordless

On a Monday morning, a chief financial officer takes a new phone out of its box. Her passkey came along, or it did not: it all depends on where it was created. If it did not, she calls the help desk, and that call, not the cryptography, decides how secure the account is.

What the sources say

The FIDO Alliance defines a passkey as an authentication credential based on FIDO standards, stored on a phone, a computer or a hardware security key, that lets a user sign in with the same gesture that unlocks the device: biometrics, PIN or pattern. Technically, it is a cryptographic key pair tied to the user's account on a website or application.

There are two types: synced passkeys are copied between the user's devices by a cloud service; device-bound passkeys never leave a single device, for example a FIDO security key. In its white paper for enterprises, the FIDO Alliance turns that into a table. For a low assurance need, both are sufficient. For moderate assurance, the device-bound passkey is sufficient and the synced passkey "may be sufficient". For high assurance, the synced passkey is insufficient and the device-bound passkey may be sufficient, depending on the authenticator and on regulatory requirements (FIPS 140, for example).

NIST reaches the same split in revision 4 of SP 800-63B, without using the word passkey: it speaks of "syncable authenticators". Its Appendix B, which is normative, allows them at AAL2 under precise conditions: keys copied to the sync fabric are stored there only in encrypted form, and the user's access to those keys is protected by AAL2-equivalent MFA. At AAL3 they are excluded, since syncing a key means it can be exported. For federal enterprise use, the appendix adds device management that prevents keys from being copied to unauthorized devices or services, and organization-managed accounts for access to the sync fabric.

The Canadian Centre for Cyber Security, in its ITSAP.30.033 publication of April 2026, describes passkeys as a strong and phishing-resistant authentication mechanism, then names two limits. The service cannot easily distinguish a device-bound passkey from one stored in a personal cloud account, and if that account is weakly protected, the passkey is more easily obtained. Above all, many systems retain passwords: if the passkey fails, the user, or a threat actor, falls back on them.

Why it matters

Because the risk moves from the sign-in to enrolment and recovery. NIST says so: the weak point in many authentication mechanisms is the process followed when a subscriber loses control of an authenticator and needs to replace it, and as soon as that process involves a human, social engineering becomes a risk.

Its answer comes down to four rules:

• permit several authenticators per account and encourage everyone to keep at least two, to minimize the need for recovery;
• require, before binding a new authenticator, authentication at the level where it will be used, within the limit of what the account already allows;
• notify the subscriber, through an independent channel, of every addition;
• frame recovery: at AAL2, two recovery codes obtained by different methods, or one code plus a single-factor authenticator already bound to the account, or repeated identity proofing.

Appendix B applies the same logic to synced keys. They are accessible through the cloud account's recovery processes, a potential weakness according to NIST. Revoking them centrally is challenging, since each key is specific to one service: NIST therefore recommends single sign-on and federation, which limit the number of keys to revoke in an incident.

What we think at Sentrix

A passkey rollout is a lifecycle project before it is an authentication project. In order:

1. Decide the type per population. Device-bound passkeys, on a security key, for administrators and privileged accounts; synced passkeys for everyone else, provided the sync account is managed by the organization.
2. Go through single sign-on. One passkey enrolled with the identity provider rather than in every application: fewer enrolments, and a single place to revoke.
3. Write the enrolment ceremony. Who proves what, to whom, before the first passkey? Two authenticators from day one, and a notice through another channel at every addition.
4. Write recovery before the first lost phone. Recovery codes issued at enrolment, identity verification imposed on the help desk, no shortcut for an "urgent" call.
5. Start with a small group. CISA observes that it may be impractical to train, enrol and support all users at the same time; it suggests the help desk and system administrators as a first phase, on the services that already support FIDO.
6. Close the back door. As long as the password is still accepted, the passkey mostly improves usability. Set a removal date per population and keep the list of exceptions.

The next step

Run the test on a single account: report the phone lost and follow the procedure to the end. Write down who was called, what was verified, and what a well-informed stranger would have obtained at the same counter. That path is what needs fixing before the first passkey is enrolled; our identity and access page takes it in that order.