User Journey: Rescue access

"I want to get my colleague back into the system, or shut the account down." The administrator confirms the account and sends a single-use recovery link to its address, then locks or unlocks the account. The colleague sets their own password at the link, so the administrator never learns it. The journey is done when the link has gone and the account's state is right, or when the account is shut and the administrator has said why.

The tenant administrator: an account inside the tenant that holds iam::accounts:reset_password, iam::accounts:lock and iam::accounts:unlock. The trigger is a support call, because a colleague is locked out, or because a compromise is suspected. It starts when the administrator opens Rescue access for one account, and ends when the account is usable or shut.

This is the administrative half of the credentials topic. The member's own half is Protect my account, and the record of what happened is Audit sign-ins.

1. Find the colleague. The administrator opens the screen from the account list and reads the account: username, full name, type and email. The system resolves the account and shows its security state beside it.
2. Read the security state. The administrator reads whether the account is locked, the failed attempt count, the last sign-in and whether a password change is required. A run of failed attempts tells the administrator which story this is.
3. Send a recovery link. The administrator confirms the address on the account and sends a single-use, time-limited link to it. The system emails the link and records that it was sent, so the record says who asked and when. The administrator types no password.
4. The colleague sets their own password. The colleague opens the link and chooses a password the administrator never sees. Nothing on the administrator's screen forces this: the link is the whole mechanism, and the password-reset flag is not needed to make it happen.
5. Lock or unlock. The administrator locks an account that must be shut, or unlocks one that was locked by failed attempts. The system writes the lock flag on the login record, and clears the failed attempt count on unlock.
6. Leave. The administrator goes back. The account list shows the new state.

An account whose mailbox cannot receive is the one case the link cannot serve. It has no fallback on the screen: an administrator who types a colleague's password knows that password, and the platform has no way to record that, so the screen does not offer it. Decided 2026-10-01, when the build answered the question the prototype raised.

One screen. The account being rescued, its security state, the recovery action and the lock actions are panels of that screen, because the administrator thinks of them as one decision. The administrator types no password, and no fallback offers one.

Accepted by the product owner on 2026-09-30: variant B, diagnose then act. The prototype is merged into main and kept there as the record; the branch names the accepted state.

Accepted commit

3f974a113f, the tip of prototype/rescue-access, merged into main

Accepted variant

b

Source

doc/prototypes/credentials/rescue-access/index.html

Open

/OreStudio/doc/prototypes/credentials/rescue-access/ once the site is built, or the file directly

Design record

Task: Prototype Rescue access

The screen writes no password and reads none back, so password_hash, password_salt and totp_secret stay off it. The link goes to account.email, which the screen shows and does not edit. A recovery token is not an entity a screen shows: it exists for one delivery and one use, so nothing on this page displays one.

The write subjects are declared in ores.iam.account_messages. iam.v1.ops.lock_account needs iam::accounts:lock, iam.v1.ops.unlock_account needs iam::accounts:unlock, and iam.v1.ops.reset_password needs iam::accounts:reset_password. A tenant administrator who holds the role has all three, and the first two are the journey's writes. The third has no caller in this journey any more: the link flow replaced it, and the decision that the administrator never sets a password is recorded above.

1. No recovery path of any kind. Nothing lets a member who cannot sign in recover, and nothing lets an administrator start it for them. There is no request subject, no completion subject, no token store and no message path; and nothing in the tree sends an email, so even a token would have no way to reach the colleague. The candidate subjects are iam.v1.accounts.request-password-reset and iam.v1.accounts.complete-password-reset, over a token store and a mail path. Both are new platform capability rather than a credentials screen, and sign-up verification will want the same machinery.
2. No activate or deactivate. An account has no active flag. The only state an administrator can change is login_info.locked. A lock can be lifted, but an account cannot be retired and later restored.
3. The reset flag has no caller, and the link flow does not need it. password_reset_required exists on login_info, and account_operations_service::set_password_reset_required implements the write, but nothing calls it: no NATS subject, no ores.http route and no other service. The link flow retires this journey's need for the flag, because the colleague chooses their own password at the link, so the candidate subject that the journey used to want is no longer part of it. The method stays as the only way to flag an account whose password must change.
4. Locking does not end sessions. iam.v1.ops.lock_account writes the login record only. A session that is already signed in stays open until it expires. The candidate is the same session-end operation that Audit sign-ins needs.

• Protect my account — the member's own password change, when they can still sign in
• Audit sign-ins — the failed attempts and sessions that explain why this account is locked
• Bring someone in — create the account when the colleague in the support call has none
• Sign in — where the colleague's new password is first used

• Identity and Access Management
• How do I add a PlantUML diagram?
• Credentials journeys

• Menu structure — the area the Rescue access screen belongs to, and its breadcrumb
• User Journeys