Skip to main content

​
Org security posture operations

Settings → Security renders seven cards. Four of them are operational workflows you run as part of keeping the org’s posture where you want it: session review and revocation, org-wide 2FA enforcement, support-access granting, and PII redaction. This guide walks each one, with the API calls behind it and the audit row each action writes. The other three cards (org IP allowlist, SAML SSO, SCIM provisioning) plus your own operator 2FA are covered in the security console guide; the per-API-key IP allowlist is a separate, programmatic control covered in its own guide. Every control on this page is tenant-owned and default-off. Orbit does not mandate session policies, 2FA enrollment, support access, or redaction for any organization; you choose what to enforce, for which roles, and when. The concepts behind this layer (step-up challenges, backup codes, the per-role policy model) are on the account security model page.

​
Scope map

Two boundaries worth keeping straight before you operate:
  • The org IP allowlist gates session (dashboard) traffic only. Programmatic requests authenticate per API key, and each key carries its own allowed_ips list; see the per-API-key IP allowlist guide.
  • The require-2FA policy and the operator 2FA card are different levers: the card enrolls your factor, the policy decides which roles must have one.

​
Session review and revocation

Two reads give you the full picture of who is signed in:
  • GET /api/v1/settings/sessions — the devices currently signed in as a member: browser/device label, source IP, approximate location, and last-active time. This is what the Active Sessions card renders.
  • GET /api/v1/settings/login-history — the merged sign-in history: active, ended, expired, and revoked sessions (most recent 30), enriched with IP, user-agent, and location from the audit log. This is what the Login History card renders, and it is the surface for spotting a session that already ended oddly.
Both endpoints return an empty list rather than an error when the identity provider is unreachable, so an empty card is never silently mistaken for “no sessions”; refresh from the card if a load fails.

​
Spot an unrecognized device

  1. Open Settings → Security and read the Active Sessions card top to bottom. The current session is flagged This device and sorted first; every other row is a session someone holds against your org.
  2. Compare each row’s device label, IP, location, and last-active time against what the member says they use. A phone-shaped session for a member who has no phone enrolled, an IP from a country nobody works in, or a last-active time after the device was reported lost is the classic unrecognized row.
  3. If the label is bare (the sign-in provider reported no browser or device details), the card explains why rather than leaving an unlabeled row; fall back to the login-history read, which adds user-agent and location enrichment from the audit log.

​
Revoke it

Use the row’s Revoke action, or call the endpoint directly:
The {sessionId} value comes from each row’s id on GET /api/v1/settings/sessions.
  • The revocation takes effect org-wide: the session ends everywhere it is held, so the member is signed out on every tab and device using it, not just the one you were looking at.
  • The revoked member’s next request fails authentication and lands them on sign-in; in the login-history read the row moves to revoked status. There is no grace window and no undo.
  • The action writes a session.revoked audit row with the acting operator and source IP.
  • The current session cannot be revoked from this surface; sign out through the normal flow instead. This is deliberate, so a reviewer can never accidentally revoke the session they are working from.
When you suspect broad unauthorized access, Revoke all other sessions on the Active Sessions card signs out everything except the session you are holding, in one confirmed action. Follow a panic revocation with the require-2FA rollout below so the next sign-in needs a factor the attacker does not have.

​
Org-wide 2FA enforcement

The Require 2FA card (owner-only write) sets a per-role policy over GET/POST /api/v1/settings/security/require-2fa. The policy is a bitmap over the five roles — owner, admin, developer, viewer, billing — and each role flips independently. A role whose bit is set cannot use the dashboard until every member holding it enrolls a second factor; unset roles stay not-required. The read returns the full map, so you can always round-trip what is currently enforced. Writes merge a partial bitmap, so you toggle one role without re-sending the whole map:

​
Staged rollout order

  1. Announce. Tell the team what is coming and give a date; enrollment takes a minute per person but stragglers are locked out at the deadline, not before.
  2. Admins and developers first. These roles hold the most mutating surface and their members are quickest to enroll without help.
  3. Viewers and billing next. Watch for lockout noise before you widen further; a viewer who only reads reports may need a nudge and a backup-code printout.
  4. Owner last. Enroll your own factor first, then set owner: true.

​
The self-lockout guard

POST rejects a write that sets owner: true while your own account has no enrolled second factor, with a 422 explaining why. The policy can therefore never strand the person enforcing it; enroll on the operator 2FA card first, then flip the bit.

​
What a blocked member sees

A member of a required role who has no factor signs in to an enrollment redirect: the /me response carries the redirect, the dashboard routes them straight to TOTP enrollment, and they cannot reach anything else until enrollment completes. Expect a short tail of these the morning after each rollout step. Every bitmap change writes a security.require_2fa.updated audit row with the per-role before→after diff and the actor, so a SOC 2-style reviewer can reconstruct the rollout from the audit log alone. The policy is default-off and tenant-owned; Orbit never sets it for you.

​
Support access SOP

Devotel support can sign in as your workspace only inside a window you grant, from the Support access card. Grants and denies are owner-only; admins see the card read-only so they can watch status and active sessions without holding the lever.

​
Grant a bounded window

Pick the shortest window that covers the support case and press Grant access, or call it directly:
The dashboard offers 15-minute to 24-hour presets; 30 minutes is the default. The grant expires on its own at the end of the window; nothing to remember, nothing left open. While a window is live, Active support sessions lists each support sign-in with its reason, start, and expiry, and End session on a row (or POST /api/v1/settings/security/support-access/sessions/{jti}/end) signs that session out without closing the window.

​
Deny and revoke semantics

Deny access (POST /api/v1/settings/security/support-access/deny) closes the window and ends every active support session immediately. Use it two ways:
  • Routine close-out. The support case resolved before the window ran out; deny rather than leaving an open door into the weekend.
  • Leak signal. Treat any of these as “deny now, investigate after”: an active support session you did not grant, a grant with no open support case, or a session that outlives the case it was opened for. Denying ends the access in one action, and the deny itself is a durable record that someone closed the door.

​
What the audit log records

The last two rows come from the support side of the same flow; a rejected attempt is not an attack by itself (it means revocation worked), but auth.impersonation_consumed rows you cannot match to a grant you made are exactly the leak signal above. The failure-path codes a support engineer sees (SESSION_REVOKED, TOKEN_ALREADY_USED, …) and their meanings are in the support access troubleshooting page.

​
PII redaction posture

The Privacy card carries two independent redaction controls; they protect different surfaces and you can run either, both, or neither. Choose by what you are worried about:
  • Display-only is a viewing control: a viewer-tier operator sees masked contact details while routing work, but the system still dials and sends the real values. Turning it on changes what people see, never what Orbit sends.
  • Write-time is a data control for orgs whose posture says transcripts must not retain PII at all: new agent conversation turns are scrubbed before they land in storage.
Write-time redaction is irreversible and not retroactive. Turns written while the control is off keep their original content forever; enabling the control only scrubs new turns from that moment on. If retention (not just redaction) is part of your posture, pair it with the transcript retention window on the same card, which purges conversations older than the set number of days nightly (blank means keep forever).
The three fields on the card save together through PUT /api/v1/settings/privacy, always sending the full current state so a single toggle can never silently unset a neighbour, and the write lands as a settings.privacy.updated audit row. As with everything on this page, both controls default off and are yours to set; because write-time redaction cannot be back-applied, trial it in a non-production org before flipping it on for real.

​
Evidence queries

Filter Settings → Audit log (or the audit export) by these action names to reconstruct who changed the org’s posture and when; see the audit log guide for filtering and export. Each row answers the two questions an auditor always asks: who changed it, and from where.

​
See also