Signing in, MFA and your own account

Three screens sit outside the console, and one page inside it is about you rather than about the platform.

Signing in

Two steps, deliberately.

1. Email and password.
2. If your account has an authenticator — and every staff account must — the form then asks for the authenticator code: “six digits from your authenticator app, or a recovery code.”

The code field appears only once the first step has been accepted. An always-visible MFA box that most sign-ins leave empty trains people to ignore it.

A wrong password and a missing code are reported as different errors, so you can tell them apart: being told “sign in failed” when your password was right and you had simply not been asked for a code yet is the kind of thing that generates a support ticket every single time.

Your session is sealed into an httpOnly cookie by the console’s own server; the tokens never reach the page.

First sign-in: enrolling an authenticator

MFA is mandatory for staff. An account without one cannot sign in, so /enrol-mfa is not a settings page that happens to be reachable — it is the second half of a first sign-in, and the session that reaches it can do nothing else. Every console route redirects there until enrolment is finished.

1. Scan the QR code with an authenticator app, or copy the secret.
2. Enter a code from the app.
3. Save the recovery codes. Each one works once.

Being made to change your password

/change-password works the same way: the console redirects there and nothing else is reachable until the password has been replaced. It sits outside the console layout because a page inside it would redirect to itself.

Your account → Authenticator and recovery codes

From the account menu. “Your own credentials. Nothing on this page needs a permission.”

Authenticator

“Mandatory for staff: an account without one cannot sign in.”

Field	Notes
Enrolled	When you set it up.
Recovery codes left	“Each works once. Losing your authenticator with none left needs an administrator reset, which is itself an approval.”
Signed in as	Your email.

Issue new recovery codes needs your password and a current authenticator code — “a recovery code is NOT accepted here.” Your existing codes stop working the moment the new ones are issued.

Act on the low-codes warning

The console shows a standing banner when your codes are nearly gone. Reaching zero without your authenticator means an MFA reset, which is one of the ten dual-controlled actions: two members of staff, an approval request, and a slow morning for both of them. Regenerating takes thirty seconds.

Your sessions

“Every live session for this account. Look for one you do not recognise.”

You can end a single session, or sign out of every session — “including this one. You will have to sign in again on every device, with your authenticator.”

An empty session list is a bug, not reassurance

The list should always include the one you are reading on. If it is empty, the read failed — it does not mean you are not signed in. The page says so rather than letting an empty state be misread.

Signed out automatically

After 15 minutes without activity. Activity means a click, a key, a scroll or a touch. A page polling for fresh data does not count, so leaving a queue open on screen does not keep you signed in. A minute before the limit, a dialog asks “Are you still there?” and counts down. Choose Stay signed in or Sign out now. All your open tabs share one clock, and signing out in one tab signs out the rest. The console’s server also checks the limit on every request. So a laptop that was closed, or a browser that restored its tabs after a restart, is signed out too. The sign-in page then says “You were signed out after a period without activity.”

When you close the browser. The session cookie has no expiry date, so it ends with the browser. A browser that restores sessions on restart is still covered by the idle limit.

The limit is SESSION_IDLE_MINUTES, set on the portal and console servers: anything from 5 to 60, and 15 if left empty.

Forgotten password

Forgot password? on the sign-in page opens Reset your password. Enter the address you sign in with and choose Send me a code. The page answers the same way for every address: “If that address belongs to a staff account, a code is on its way. Nothing here can confirm whether it does.”

Then, on Enter your codes:

Field	Notes
Code from the email	Case and hyphens don’t matter. Only the most recent code works. It lasts 15 minutes and works once.
Authenticator code	Six digits. Staff accounts need it as well as the email. Or use a Recovery code, which is then used up.
New password	At least 12 characters. Length is what helps; there are no composition rules. Typed twice.

On success every session is signed out, and you sign in with the new password. The reset is audited as user.password.reset.

What protects it:

• An email alone is not enough. The emailed code and your second factor are both needed.
• Five wrong second factors cancel the code, and they count toward the account lockout like failed sign-ins.
• At most three codes per account per hour, with further limits per address and per network. A request over the limit gets the same answer, and no email.
• Codes are stored hashed.

An account with no authenticator can’t use this. It is refused with mfa_not_enrolled (“Ask an administrator”). An administrator reissues the password instead; see Staff.

From the API: POST /v1/auth/password/forgot with { email } always answers 202 with the same words. POST /v1/auth/password/reset takes the code, the authenticator code or a recovery code, and the new password.

When a staff member is locked out

They have lost	What to do
Their password, but still have their authenticator	Forgot password? on the sign-in page, alone. Nobody else is involved.
Their authenticator	An administrator uses Rebind authenticator from their row in Staff.
Both	Both of the above: rebind the authenticator, and reissue the password.
A password on an account that never enrolled an authenticator	An administrator reissues the password.

Changes to a staff account need a second person, and the person being changed can never be that second person. A rebind or reissue is held until a colleague approves it in Approvals. When the locked-out account is next used, it enrols a new authenticator and gets fresh recovery codes.

The dual control is the whole point. A reset one person could perform alone is a reset an attacker can talk one person into performing, and it would undo the second factor for every staff account on the platform.

When there are only two accounts

When there are only two active accounts, there is nobody to approve a change to one of them except the other. For credential recovery only (password reissue and authenticator rebind), the administrator may then authorise it themselves. It takes effect at once and is recorded as self-authorised. This stops working as soon as a third active account exists.

1. The administrator reissues the colleague’s password, naming themselves in Authorised by.
2. If the colleague also lost their authenticator, the administrator uses Rebind authenticator and ticks Authorise it myself.
3. Or, if the colleague still has their authenticator, they reset alone with Forgot password?: the emailed code, their authenticator and a new password.

Step-up verification

Some decisions in the console ask for a current authenticator code at the moment you decide — approving a request, for instance. It is not a sign-in prompt and it is not a bug: it is proof that the person at the keyboard is the person the audit entry will name.

A recovery code is never accepted for step-up. Keep the authenticator to hand while you are working a queue.