Skip to main content
Free plan Two-step sign-in asks for a code from an authenticator app after your password. Anyone can turn it on for their own account. An org admin can also require it for the organization’s members, with a grace period so nobody is locked out the day the requirement starts.

​
Set up an authenticator

1

Open the Security section

Go to Account and find Security: two-step sign-in. Click Set up an authenticator app.
2

Scan the code

Scan the QR code with an authenticator app such as 1Password, Authy, Google Authenticator or Microsoft Authenticator. If you cannot scan, type the key printed beside the code and choose time-based codes.
3

Confirm with a code

Enter the 6-digit code the app shows and click Confirm and turn on. Nothing is turned on until a first code is accepted.
4

Save your recovery codes

Ten recovery codes appear once. Copy or download them, then click I saved them. They are not shown again.
The key is stored encrypted and is never shown again. A code that was accepted once is refused a second time, so after signing in wait for the next code if you need to confirm something else.

​
Recovery codes

Each recovery code is 10 characters and works once, in place of an authenticator code. Use one when your phone is lost. SRE Agent keeps only a scrambled form of each code, so nobody can read them back to you. Treat them like a password.
  • Signing in with a recovery code emails you and shows a reminder to make a new set.
  • Generate new recovery codes replaces the whole set. Every unused code you have stops working. It asks for a current code first.
  • You can make 6 new sets an hour.
  • Removing your last authenticator deletes the recovery codes too.

​
Sign in

Sign in as usual with your password, GitHub, Google or single sign-on. If you have an authenticator, the Two-step verification page asks for a code. Use a recovery code instead switches to a recovery code. A correct code finishes the sign-in. A verification lasts for the life of the session. A session kept by Remember me asks again once its last verification is more than 30 days old. A sign-in waiting for its code expires after 10 minutes, and 5 wrong codes end it. Every failure reads the same, whether the code was wrong, already used, or blocked.

​
Too many wrong codes

Wrong codes lock the second step, and a locked step refuses every code, including a correct one. The level starts over after 24 hours without a lock. The 20th wrong code in 24 hours also writes the next lock, however slowly the guesses were spaced. A correct code does not wipe the 24 hour count, so signing in does not clear someone else’s guessing. A lock can be ended early by resetting your password from the sign-in page, or by an admin resetting your two-step sign-in.

​
Require it for your organization

Org admins open Settings, Security, switch on Require two-step sign-in for members and choose a grace period of 0 to 30 days. The default is 7.
  • During the grace period a member without an authenticator keeps working. A banner on every page counts the time down and links to the setup. Members without an authenticator are emailed when the requirement starts.
  • After it a member without an authenticator is sent to Account to set one up before using the organization. Their other organizations and their Account page stay reachable.
  • A grace period of 0 holds members without an authenticator out at once.
  • Members with an authenticator are asked for a code once per session.
  • Guests are not held to the requirement.
  • Several organizations. A person is held only in the organization that requires it. Another organization of theirs that does not is reached freely.
The Security tab lists every member as set up, in their grace period until a date, or needing to set one up. It never shows a secret. Switching the requirement on or off and changing the grace period are recorded in Audit Logs.

​
Parent and child organizations

A parent organization’s requirement covers its child organizations. A child can add a requirement of its own, such as a shorter grace period, and can never switch the parent’s off. The stricter one applies, meaning the one whose grace period ends first, and the child’s Security tab says which.

​
Single sign-on

A single sign-on sign-in can count as the second step when your identity provider says it performed multi-factor authentication. Under Integrations, SSO, each provider has a Multi-factor authentication setting: A provider’s assertion counts only for the organization that set the provider up, and for its child organizations. A sign-in with GitHub, Google or a password never counts as the second step by itself.

​
Reset a member’s authenticator

When a member loses their phone and their recovery codes, an org admin removes their second step from Settings, Security. Click Reset on the member’s row, enter a reason that is kept in the audit log, and click Confirm reset. The member is emailed.
  • You can reset a member of an organization you administer, as long as that person is not an admin in any organization. Resetting another admin is a platform administrator’s action after an identity check outside the app, so the row says so instead of offering Reset. Contact SRE Agent support for it.
  • Nobody resets their own authenticator with only a session. You can remove your own from Account with a current code or a recovery code.
  • A reset removes the authenticator and recovery codes, signs the person out of every browser and the mobile app, and clears any lock. Where the organization requires the step, their grace period starts again, at most once every 30 days.
The person signs in with their password and sets up a new authenticator.

​
What is not covered

Two-step sign-in protects interactive sign-in. These stay as they were, so you can plan around them:
  • API keys, MCP tokens and mobile tokens keep working when a requirement starts and are not asked for a code when used. Existing ones are not tied to their creator’s status.
  • Creating a key or token in the app needs a sign-in that meets the requirement. Creating one with an existing API key through the API is not checked, because a key has no sign-in. Key expiry, last-used display and an address allowlist are planned.
  • Slack and Telegram. A person acting from Slack acts as the account their Slack user is linked to, and links in emails you approve from your mailbox work from the mailbox. These are outside two-step sign-in.
  • A page that is already open is checked again the next time it loads or reconnects. When a requirement changes, a member is reset, or a grace period ends, the affected person’s open pages are dropped to be checked again, but a page that never loads or reconnects keeps working until it does.
  • Someone who knows your password can delay your sign-in by guessing wrong codes until the second step locks, for up to 24 hours. It does not let them in. Resetting your password or an admin reset ends the wait.
Passkeys and security keys, re-confirming before sensitive actions, session lists and new-device alerts are not part of this release.

​
What is recorded

Each event records who, whom and which organization, and never a secret, code or hash. Members are emailed when an authenticator is added, when a recovery code is used, when their second step is reset, and when a requirement starts a grace period for them. Every compliance evidence bundle carries mfa/requirement.json (the requirement now, its source and the grace end), mfa/policy_history.jsonl (every change in the period) and mfa/members.jsonl (each full member: whether they set one up, their status and when the grace ends). Guests are not listed. History is capped at 500 entries and the member list at 5,000, and the requirement file says when a cap cut a list.

​
Read it over MCP and the API

update_organization_settings takes mfa_required and mfa_grace_days from an org admin’s user token. An API key is refused, so an unattended key cannot switch the requirement off, and the configuration API only reads these fields.