> ## Documentation Index > Fetch the complete documentation index at: https://docs.sreagent.app/llms.txt > Use this file to discover all available pages before exploring further. # Two-step sign-in > Protect your sign-in with an authenticator app and recovery codes, and require it for your organization. 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. | Lock | When | Lasts | | - | - | - | | First | 5 wrong codes within 10 minutes | 5 minutes | | Second | another lock within 24 hours of the previous one ending | 15 minutes | | Third | again within 24 hours | 1 hour | | Fourth onward | again within 24 hours | 24 hours | 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](https://docs.sreagent.app/guides/administer/parent-and-child-organizations.md). 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: | Setting | What it does | | - | - | | **Trust the provider's assertion (recommended)** | Counts a sign-in only when the provider's signed response names a multi-factor method. A password-only response does not count. | | **Always trust this provider** | Counts every sign-in through the provider. Choose it only when the provider enforces multi-factor authentication itself. | | **Never trust this provider** | Ignores the provider's claim and asks members for SRE Agent's own second step. | 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. | Event in Audit Logs | When | | - | - | | `mfa.enrolled` | An authenticator was confirmed. | | `mfa.removed` | An authenticator was removed. | | `mfa.challenge_failed` | A wrong code. A lock records its level and length. | | `mfa.recovery_used` | A recovery code was spent, and how many remain. | | `mfa.recovery_regenerated` | A new set replaced the old one. | | `mfa.reset_by_admin` | An admin, a platform administrator, the person with a recovery code, or support reset. | | `organization.mfa_policy_changed` | The requirement or the grace period changed, with the values before and after. | 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](https://docs.sreagent.app/guides/security-cost/compliance.md) 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 | Where | Field | Meaning | | - | - | - | | `get_organization_settings`, `organization_settings` in the configuration API | `mfa_required` | Whether this organization asks for two-step sign-in. | | same | `mfa_grace_days` | The grace period, 0 to 30 days. | | same, read only | `mfa_effective` | The requirement that holds: `required`, `source` (`own` or `parent`), `grace_days`, `grace_ends_at`, and `own` and `parent` with the same keys. | | `list_members` | `mfa_enrolled` | Whether a member has an authenticator. Org admins only. It never says which kind and never carries a secret. | `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. ## Related * [Single sign-on](https://docs.sreagent.app/guides/administer/single-sign-on.md): connect your identity provider. * [Parent and child organizations](https://docs.sreagent.app/guides/administer/parent-and-child-organizations.md): how a requirement reaches children. * [Compliance](https://docs.sreagent.app/guides/security-cost/compliance.md): export the evidence for an audit period. * [Sign in and join your team](https://docs.sreagent.app/guides/administer/sign-in-and-joining-your-team.md): how people get an account. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.