Skip to main content

​
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.

​
Your three cards vs the org cards

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 and the security console guide. The model behind personal vs org controls is in Account security model.

​
Read your login history

The Login History card lists your recent sign-in attempts, successful and failed. Its columns: 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.

​
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.
  5. Close the door behind it. Set a new password from Settings → Profile (see Set and rotate your dashboard password), 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.

​
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. 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. 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.

​
See also