Passkeys

Nobody signs in with a password. Not "passwords are discouraged": no account has one, so there is no reset flow to phish, no hash to leak and no complexity policy to argue about. The only stored secret of that kind is the mail relay's password, which Cardinal needs to send notifications, sealed at rest with a key from the configuration file.

That is a real constraint and it is the one to weigh before anything else here: a deployment that needs password fallback for anybody cannot use Cardinal.

Nobody types a username either

Signing in is usernameless. The browser or security key offers the accounts it holds, you pick one, and the server names nobody until the authenticator has already proven it holds a credential. There is no account field to fill, and so nothing to probe: a sign-in page that let you type a name would tell anyone which names are real accounts. For that to work every passkey is resident, stored on the authenticator so it can be offered by name, which platform authenticators and modern security keys do by default. An older key that cannot store one is turned away at enrolment rather than registered as a credential you could never sign in with.

Two, not one

An account is not fully enrolled until it has registered a second credential, and the console says so on any account that has one.

One passkey on one laptop is one theft away from an account nobody can reach. A second, ideally a hardware key kept somewhere else, means most recovery events never happen at all, which beats any recovery mechanism.

Device-bound, and what policy does with it

Cardinal records whether a credential can leave its hardware, and policy reads it. The rule that ships refuses administration to anything that is not device-bound and used within the administrative window, fifteen minutes unless sessions.admin_window says otherwise:

forbid (principal, action in [AdministerDirectory, ManageUsers,
                              ManageApplications], resource)
unless { context has adminWindowSeconds && principal.deviceBound &&
         principal.authAgeSeconds <= context.adminWindowSeconds };

Both halves are load-bearing. Device-bound excludes a synced passkey, which is more recoverable but lives in a cloud account. Freshness excludes a working-day session somebody left open on an unlocked laptop.

Be precise about what device-bound means here. It is the WebAuthn backup-eligible flag, inverted: a credential that cannot sync to a cloud account counts. Cardinal does not verify attestation statements against a metadata service, so this is what the authenticator says about itself rather than something proven: good enough to separate a synced passkey from a hardware key, and not an AAL3 claim.

It is also why an access token cannot administer anything: a token is never device-bound, so this rule refuses it without ever mentioning tokens.

In the console

Access → Passkeys is where a person manages their own credentials and is told to keep at least two. Those routes require a device-bound credential themselves: the things that decide what may authenticate as you must not be reachable by something weaker.

A synced passkey first, and a device-bound one after

So a session signed in with a synced passkey cannot add a device-bound one: if it could, whoever holds the cloud account behind the synced passkey could add a key of their own. From Cardinal 0.7.0 the invitation covers it instead.

• Synced first: when the first passkey registered with an invitation is synced, the enrolment page explains the difference and offers to register a device-bound one next, with the same link.
• One more, device-bound only: the link then takes exactly that one more passkey, and only if it cannot be synced, until it expires or the person finishes.
• Administrators are told first: an account in an administrative group is told before its first registration that it needs a device-bound passkey.
• After enrolment: once the link is spent, adding a device-bound passkey to an account that only has synced ones is a recovery, which two administrators approve.

Limits

• No password fallback, and none planned.
• No TOTP, no SMS, and no email link as a way in. Notification email reports what happened; it is never a credential.
• No attestation verification, as above.