> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Your login security: read your history, retire sessions, enroll your own 2FA

> The member-side walkthrough of Settings → Security: what your three personal cards show, how to read a login history row, what to do about an unrecognized session, and how to enroll and manage your own two-factor authentication.

# Your login security: read your history, retire sessions, enroll your own 2FA

Settings → Security shows two kinds of cards. Three of them are personal: they act on your own login and nobody else's. The rest are org-level and are owned by your owner and admins. This guide is the personal loop: read your sign-in history, retire sessions you don't recognize, and put two-factor authentication (2FA) on your account.

If you administer the org itself (session sweeps, per-role 2FA enforcement, support access), the companion guide is [Org security posture operations](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md).

## Your three cards vs the org cards

| Card | Acts on | Who manages |
| - | - | - |
| Two-Factor Authentication | Your login | You |
| Active Sessions | Your open sign-in sessions | You |
| Login History | Your recent sign-in attempts, including failed ones | You |
| Require 2FA per role | Every member holding the selected roles | Owner (admins read-only) |
| Support access | Time-boxed Devotel support window for the org | Owner and admins |
| IP allowlist, SSO (SAML / SCIM), PII redaction | Org-wide dashboard access | Owner |

The Security page is shown to owner, admin, and developer roles. As a developer, your three personal cards work fully while the org cards stay hidden or read-only for you.

Two org settings change which steps below are managed for you:

* If your org enforces single sign-on (SSO), your identity provider is the front door: its MFA policy applies to your sign-in, and your personal 2FA covers any password-based sign-in that remains.
* If an owner requires 2FA for your role, enrollment stops being optional: the org floor overrides your personal toggle, and the dashboard won't let you drop below it.

Both settings are described in [Org security posture operations](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md) and the [security console guide](https://docs.orbit.devotel.io/guides/settings-security-console.md). The model behind personal vs org controls is in [Account security model](https://docs.orbit.devotel.io/concepts/account-security-model.md).

## Read your login history

The Login History card lists your recent sign-in attempts, successful and failed. Its columns:

| Column | What it shows |
| - | - |
| Time | When the attempt happened, pinned to your timezone with the zone abbreviated |
| Device | A parsed device label such as "Chrome on macOS"; where your sign-in provider reports none, the raw browser string, with a note when a session can't be identified |
| IP Address | The source address of the attempt |
| Location | The resolved location of that address, when available |
| Status | Success or Failed |

The row you are signed in on carries a **This device** badge. The list shows the ten most recent rows; use **Show all** for the full set.

Two actions sit in the card header:

* **CSV** downloads every row as a spreadsheet-ready file (timestamp, IP, device, location, status), not just the ten rows on screen. Hand it to your admin or security contact during an incident.
* **Refresh** re-fetches immediately. The card otherwise caches for five minutes, which is fine for routine checks but too slow when you are investigating.

A healthy history is boring: devices and browsers you recognize, addresses and locations that match where you actually work, Success at the times you signed in, and the occasional Failed row that lines up with your own mistyped password. Because every timestamp is pinned to your timezone, a 3 a.m. row from a city you have never visited is evidence, not a rendering artifact.

Your history is one lens; the org's alerts are the other. Admins receive session-anomaly alerts for patterns no single member can see, such as impossible travel across the org or bursts of failures. If an alert names you, or a row looks wrong, work the incident below. For the alert side, see [Reading session anomaly alerts](https://docs.orbit.devotel.io/guides/session-anomaly-alerts-reading.md).

## Worked incident: an unrecognized session row

Suppose a refresh surfaces a row you don't recognize: a browser you don't use, or an address and city that aren't yours.

1. **Export first.** Press **CSV** so the evidence is preserved outside the page, whatever you click next.
2. **Revoke the row.** Press **Revoke** on that row and confirm. The device holding that session is signed out immediately, and the revocation cannot be undone.
3. **If more than one row is foreign**, use **Revoke all other sessions** in the Active Sessions card instead. It signs out everything except the device you are on, in one confirmed step.
4. **Tell your admin.** Your revocation writes a `session.revoked` entry to the org audit log with the actor and source IP, so your admin sees what you did and can run the org-side sweep. The admin workflows live in [Org security posture operations](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md).
5. **Close the door behind it.** Set a new password from Settings → Profile (see [Set and rotate your dashboard password](https://docs.orbit.devotel.io/guides/set-and-rotate-your-dashboard-password.md)), then enroll in 2FA below if you haven't.

What the **This device** flag guarantees while you clean up: it is resolved from your live session, and the card never offers a Revoke button on that row. Revoking one foreign row, or all other sessions, cannot sign out the device you are working from. The flag also states the one thing this page deliberately cannot do: your current session is the one session you cannot revoke here. You end it by signing out.

If the unknown row turns out to be yours after all (a new phone, a hotel network), no harm done: a revoked session only needs a fresh sign-in.

## Enroll your own 2FA

The Two-Factor Authentication card puts TOTP on your login with any standard authenticator app (Google Authenticator, Authy, 1Password, or similar).

1. Press **Enable 2FA**. The dashboard first asks you to re-prove it's you with a step-up prompt for your password, then opens the setup dialog.
2. Scan the QR code with your authenticator app, or copy the manual secret if you prefer typing it.
3. Enter the 6-digit code the app shows and press **Verify & Enable**. This proves the app and the dashboard share the same secret before 2FA turns on, so a lost QR can never lock you out.
4. Save your backup codes. They are shown exactly once, with **Copy** and **Download .txt** actions, and the dialog makes you confirm you stored them before it closes. Put them in a password manager or another durable place: each code signs you in once if your device is lost.

With 2FA on, the card also tracks your recovery posture:

* A remaining-codes indicator tells you when your spare keys run low.
* **Regenerate backup codes** mints a fresh single-use set and invalidates every older code. It requires a current code from your authenticator app.
* **Disable 2FA** likewise requires a current code, not just your session.

### Why disabling 2FA needs a step-up

Behind the dialog, disabling 2FA and regenerating backup codes both start at `POST /api/v1/settings/security/2fa/challenge`: you prove a fresh credential (your password or a current TOTP code), the backend returns a single-use challenge token, and the sensitive operation replays it. A stolen session cookie alone therefore cannot silently strip your second factor or burn your backup codes; the attacker would also need one of your live factors at that moment.

The trail is written down. Failed step-up attempts write `security.2fa.stepup_failed` to the audit log, a completed disable writes `security.2fa.disabled` and triggers a notification, and regenerating codes writes `security.2fa.backup_codes_regenerated`. If you ever receive a 2FA-changed notification you didn't cause, treat it as the incident above.

If your account uses the newer sign-in flow, the card walks you through the same loop: enroll shows the QR code and secret, a 6-digit code activates it, and disabling asks for a current code. Recovery for those accounts uses an emailed code instead of backup codes.

## Lost-device routine

If a signed-in device goes missing:

1. From a device you trust, sign in and open Settings → Security.
2. In Active Sessions, press **Revoke** on the lost device's row. If you can't tell which row it is, press **Revoke all other sessions**: everything except the device you are on is signed out immediately. Revoking needs nothing from the lost device, so a lost phone cannot block you from retiring its session.
3. End your current session by signing out. The card retires every session except the one you are on, and sign-out ends that one; together they are your "sign out everywhere."
4. If the lost device also held your authenticator app, sign in with a backup code, then **Regenerate backup codes** so the lost set stops working.

If you are locked out entirely (lost device and no backup codes), involve your owner: an owner can reset your 2FA so you can re-enroll, and the reset is written to the audit log. Owners can also open a time-boxed support window through the Support access card when hands-on help is needed. Both levers are org-owned and audited; see [Org security posture operations](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md).

## FAQ

**Is this the same 2FA my app's end users get?**
No. This card protects your Devotel Orbit operator login. The Verify product's factors (TOTP, passkeys, and push for your application's end users) are a separate, API-only system. See the [Verify overview](https://docs.orbit.devotel.io/verify/overview.md).

**We use SSO. Does my personal 2FA matter?**
Your identity provider is then the primary gate, and its MFA policy applies at the IdP. Your personal 2FA still covers any password-based sign-in your org allows. Which sign-in methods exist at all is an org setting; see the [security console guide](https://docs.orbit.devotel.io/guides/settings-security-console.md).

**What can my org override?**
Owners set the floor: per-role required 2FA, enforced SSO, and the org IP allowlist all take precedence over personal choices, and an allowlist lockout blocks sign-in regardless of your factors. Personal cards never weaken an org control. The full matrix is in [Org security posture operations](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md).

## See also

* [Security console: IP allowlist, SAML, SCIM, and 2FA](https://docs.orbit.devotel.io/guides/settings-security-console.md)
* [Org security posture operations](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md)
* [Account security model](https://docs.orbit.devotel.io/concepts/account-security-model.md)
* [Reading session anomaly alerts](https://docs.orbit.devotel.io/guides/session-anomaly-alerts-reading.md)
* [Set and rotate your dashboard password](https://docs.orbit.devotel.io/guides/set-and-rotate-your-dashboard-password.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.