Two-factor and how you sign in
Your own sign-in credentials, and the workspace-wide two-factor requirement.
Settings then Security is one page covering your own credentials and, for an owner, the requirement that everybody carries a second factor. Most of what is here is yours alone, so it gates on being signed in rather than on a permission.
Confirming it is you
Several actions across the console ask you to confirm it is you before they run. The precise term is step-up, and what it means is a fresh challenge against a factor you already carry.
A challenge stays fresh for 15 minutes. Inside that window the same action runs without asking again. Somebody carrying no factor at all is not asked, because there is nothing to challenge.
The permission is always checked first. Somebody who was never allowed to do a thing is told that rather than sent to fetch a code that would not have helped.
Your own credentials
| Card | What it does |
|---|---|
| Authenticator | Enroll a code-generating app, or replace the one you have |
| Passkeys | Add, rename and remove passkeys, each usable to sign in and to confirm it is you |
| Recovery codes | Regenerate the one-time codes that get you back in |
| Recovery email | Add a second address, verify it, remove it, or promote it to your sign-in address |
| Terminals | Every terminal your account is signed in on, with a button to sign one out |
| Linked accounts | Link or unlink Google, GitHub and Microsoft sign-in |
Recovery codes appear once a factor exists to recover from.
A terminal signed in with penv login lasts 30 days from its last use, extending itself on every request. Signing one out from here is the same thing penv logout does from the terminal.
A recovery email removal link sent by email is good for 30 days and needs no session. That is deliberate, so somebody who has lost access to an address can still cut it off.
The workspace-wide requirement
An owner can require every member to carry a second factor. Turning it on starts a grace window, and the console shows a banner with the deadline until everybody has enrolled. Past the deadline, somebody with no factor is walled at /mfa until they add one.
Anybody with member:read also sees the roster of who has enrolled and who has not.
What each action needs
| Action | Needs | Confirm it is you | Recorded as |
|---|---|---|---|
| Open the page | org:read | No | not recorded |
| Enroll an authenticator | a signed-in session | No | member.mfa_enrolled |
| Replace an authenticator | a signed-in session | Yes | member.mfa_enrolled |
| Add or remove a passkey | a signed-in session | Yes | not in the action picker |
| Rename a passkey | a signed-in session | No | not in the action picker |
| Regenerate recovery codes | a signed-in session | Yes | not in the action picker |
| Add, remove or promote a recovery email | a signed-in session | Yes | not in the action picker |
| Sign a terminal out | a signed-in session | Yes | device.revoked |
| Unlink a social account | a signed-in session | Yes | not in the action picker |
| See the enrollment roster | member:read | No | not recorded |
| Turn the requirement on | Owner | Yes | org.mfa_required |
| Turn the requirement off | Owner | Yes | org.mfa_requirement_lifted |
The requirement carries no permission slug. Being the workspace owner is the gate.
member.step_up_verified lands each time somebody answers a challenge, so you can see when a sensitive action was confirmed and by whom.
Next: who holds the key.