For Divvent’s own team. It is generated from the operations document in our repository, which is the one to edit. If you use Divvent, the help centre is for you.
4a. A portal account's second factors: the operator's reset
For somebody who cannot sign in to the portal with anything they hold — no passkey they can use, no authenticator app, no recovery code (DESIGN.md §10, decided by Ant 2026-09-26). It is break-glass: a grant over the person, asked for and approved by two operators, then used once. Try the person's own ways back first: a recovery code typed after their password (Lost your passkey? on /security), or, with an authenticator app, a backup code at the code step.
| # | Who | Action |
|---|---|---|
| 1 | Operator A | Sign out of the console (/cdn-cgi/access/logout) and in again with the Access second factor (§6f). Console → Break-glass → A portal account's second factors → their sign-in address → Look up. It answers with their member id, what they hold and their accounts |
| 2 | Operator A | Within ten minutes of that sign-in: Why — how the request reached you — → Ask to reset their second factors |
| 3 | Operator B | Signed in within ten minutes: look the same address up → the grant → Approve. The person and every owner of every account they are on are emailed now, before anything is reset |
| 4 | Operator A (or B) | Signed in within ten minutes: How you know it is them → Reset their second factors. The answer says what was removed and how many notices went |
| 5 | The person | Signs in with their password, which is unchanged, and lands on Your sign-in (the header's Account link): nothing else opens until they set up a passkey or an authenticator app. A first passkey shows ten recovery codes once — save them before I have saved them |
What the reset does, in one write: every passkey, the authenticator app and its backup codes, and the portal's recovery codes deleted; every session ended; the person marked recovered, so what they enrol in the next day cannot confirm an erasure or a handover until the day is out; an audit row on every account they are on, naming them by member id with the reason and the grant. Then the grant is spent (revoked), so one approval is one reset, and the person and their accounts' owners are emailed again. A failed send does not undo it — it is on the audit log.
Refused, each with the sentence that says what to do: no grant, one not yet approved, one over somebody else or an application, an expired one; a sign-in older than ten minutes at any of the three steps; a requester approving their own; a reason under ten characters. On AGENT_NEVER: an agent can neither ask for one nor use one.
Two operators are needed, on staging as in production: the approver must be a different Access identity from the requester (§9.0).
---