Recovery

Two mechanisms, in the order they should be used.

Recovery codes

Ten single-use codes, generated on request and shown exactly once.

A code redeems into an enrolment, not a session: it lets somebody register a new passkey and nothing else. That distinction is the design. Credential self-service requires a device-bound credential, and a recovery code is a string on paper, so a session minted from one would be unable to register the passkey it exists to let somebody register.

They live under Account in the console.

When those are gone too

Restoring an account takes two administrators. One opens the request, a second approves it, and only that second approval produces an enrolment link. Nobody can approve their own, and a request expires after 72 hours.

Dual control is here because the alternative is worse than it looks. Recovery can be run against an account that can already sign in, so it is a way to mint a credential on an administrator's account: an unguarded single-administrator recovery path is a way to become anybody in the directory, and it is one support-desk conversation away from being used that way.

It needs the broad tier, and two of them.

When there is only one administrator

An organisation with a single administrator cannot provide the two people dual control needs. Rather than leave it with no recovery but the database credential, Cardinal has a mode for exactly that case, off unless it is turned on.

Set recovery.single_administrator in the configuration, and while exactly one account holds the broad tier that administrator may recover someone else alone. The second person is replaced by three things together:

• a waiting period (recovery.single_admin_delay, an hour by default, between 15 minutes and a day) before the link can be issued, so the link does not exist during the wait, and there is nothing to leak or hand over early;
• mail to the person being recovered and to the administrator, when the recovery is requested and again when the wait is over, so one nobody asked for can be cancelled before it can do anything;
• the standing rules: it never recovers your own account, and the moment a second administrator exists dual control is back, with nothing to change in the configuration.

It is a deliberate statement that this deployment has one administrator and accepts one-person recovery of everyone else, with a delay and a warning as the check. An organisation that can field two people should use dual control.

In the console, and only there

Directory → Recovery is where a request is opened, approved and cancelled. The page requires fresh authentication before it shows anything, rather than firing requests that will be refused, which once produced an empty table under the words "Nobody yet.", a statement about the directory and a false one.

The CLI has no recovery commands, deliberately. It is the one flow where a second human being is the control, and a scriptable version of it is a way around that.

The real last resort

Neither of these is the bottom. Whoever holds the database credential can run cardinal invite <administrator> and get an enrolment link, which is why the project removed its offline break-glass key rather than maintaining a second credential of last resort reachable from any browser (ADR 0014).

Read that as it is: shell access to the database host is administrative access to the directory. Two ways in says what follows from that.