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

# Pre-production security hardening checklist

> Walk the tenant-owned security posture decisions before go-live: per-role 2FA enforcement, the dashboard and per-key IP perimeters, SCIM role defaults, support access, PII redaction, and the recurring reviews that keep the posture honest.

# Pre-Production Security Hardening Checklist

The [production go-live checklist](https://docs.orbit.devotel.io/guides/go-live-checklist.md) verifies that your integration is ready for live traffic. This companion checklist walks the security posture decisions behind it. Every item below is a control **your organization owns**: each one ships default-off or with a permissive default, and enabling it is your decision, not a Devotel mandate. The checklist exists so that each decision is made deliberately, with a named owner, before customers and agents touch the workspace.

Assign an **owner** to every checkbox before you start, and verify each item in your own organization's settings rather than on paper.

## 1. Session-auth posture

* [ ] **Per-role two-factor enforcement is decided for every role.** Orbit can require 2FA per role across the whole organization. Require it at minimum for the roles that change settings, mint keys, or see billing (owner, admin, developer), then make an explicit call for viewer and billing-only roles instead of leaving the question unanswered. The role model is described in [Account security model](https://docs.orbit.devotel.io/concepts/account-security-model.md); the enrollment and enforcement controls sit on [Settings → Security](https://docs.orbit.devotel.io/guides/settings-security-console.md#operator-2fa). *Owner: Administrator.*

* [ ] **Enforcement is staged so it strands nobody.** Open an enrollment window first, confirm every member has an active second factor and backup codes stored somewhere durable, and only then switch enforcement on per role. Enforcing before enrollment converts a posture decision into a lockout incident. See [Settings → Security](https://docs.orbit.devotel.io/guides/settings-security-console.md#operator-2fa) for the enrollment and step-up flows. *Owner: Administrator.*

## 2. Dashboard perimeter

* [ ] **The org-wide IP allowlist covers the real access footprint.** Under **Settings → Security → IP Allowlist**, restrict which source IPs may open the dashboard and start a SAML login: office egress, VPN ranges, and bastion hosts as IPv4/IPv6 addresses or CIDR ranges. An empty list means unrestricted, which is the out-of-the-box state. The allowlist governs session (dashboard) traffic only; programmatic keys carry their own list (section 3). See [Settings → Security](https://docs.orbit.devotel.io/guides/settings-security-console.md#org-ip-allowlist). *Owner: Administrator.*

> [!WARNING]
>
> Use the page's "Use my current IP" action before saving your first entry. The page shows the source IP Orbit actually enforces against, which can differ from what an external "what's my IP" site reports; allowlisting the wrong address is the classic self-lockout.

* [ ] **The lockout recovery path is understood before it is needed.** A blocked dashboard request returns `403` and lands in your audit log as `auth.ip_blocked`, so attempted access outside the perimeter is visible. Support can reach a locked-out org only through a logged override that also appears in your [audit log](https://docs.orbit.devotel.io/guides/audit-log.md). *Owner: Administrator.*

## 3. Programmatic perimeter

* [ ] **Every live key carries its own `allowed_ips` list.** The per-key allowlist gates programmatic API authentication separately from the dashboard allowlist, so CI runners and SDK egress IPs belong on the keys that use them, not on the org list. Decide which source IPs may use each live credential and set them under **Settings → API Keys**; see [API key IP allowlist](https://docs.orbit.devotel.io/guides/api-key-ip-allowlist.md). *Owner: Engineering.*

* [ ] **Usage budget alerts would reach someone if a key misbehaves.** A leaked key usually shows up as a traffic or spend spike before anything else. Configure per-key usage budget alerts so the spike lands in a monitored inbox while the key is rotated; see [API key usage budget alerts](https://docs.orbit.devotel.io/guides/api-key-usage-budget-alerts.md). *Owner: Engineering.*

## 4. Provisioning posture

* [ ] **SCIM defaults encode least privilege before sync is enabled.** Set `defaultRole` to `viewer` so any user without a group mapping lands on the least-privilege floor, map IdP groups to elevated roles with `groupMapping`, and keep the role ceiling at `admin` so `owner` assignment stays a deliberate dashboard action that a directory sync can never perform. See [SCIM provisioning](https://docs.orbit.devotel.io/guides/scim-provisioning.md) and the defaults table in [Settings → Security](https://docs.orbit.devotel.io/guides/settings-security-console.md#scim-provisioning). *Owner: Administrator.*

## 5. Assistance posture

* [ ] **Support access follows a written policy.** Decide whether support sessions start denied until explicitly granted, or open only inside bounded windows you define, and name the roles (keep it to owner) that may grant them. Every grant, and every support override past a locked-out org, is recorded in your audit log with actor and timestamp; see [Audit log](https://docs.orbit.devotel.io/guides/audit-log.md). *Owner: Administrator.*

## 6. Data display posture

* [ ] **Each surface has a deliberate redaction choice: display-time or write-time.** Display-time redaction masks sensitive fields per role while the underlying data is retained; write-time redaction removes it irreversibly as it lands. Make the call per surface rather than globally: conversation and inbox views, exports, and call recordings each have different retention consequences. See [On-demand message redaction](https://docs.orbit.devotel.io/guides/on-demand-message-redaction.md) and [Recording redaction](https://docs.orbit.devotel.io/guides/recording-visual-redaction.md). *Owner: Compliance.*

## 7. Recurring reviews

* [ ] **A monthly session sweep is on the calendar.** Review active sessions and login history for departed members, unrecognized devices, and unexpected source IPs, and revoke what you cannot explain; [session anomaly alerts](https://docs.orbit.devotel.io/guides/session-anomaly-alerts-reading.md) surface the outliers between sweeps. *Owner: Administrator.*

* [ ] **The audit log is filtered monthly for posture changes.** Run these filters in **Settings → Audit log** and review every hit; the action names are the same ones each control writes when it changes (see [Settings → Security](https://docs.orbit.devotel.io/guides/settings-security-console.md#audit-log-tie) and [Audit log](https://docs.orbit.devotel.io/guides/audit-log.md)): *Owner: Administrator.*

| Audit action | Why it matters |
| - | - |
| `ip_allowlist.added` / `ip_allowlist.removed` | The dashboard perimeter changed. |
| `auth.ip_blocked` | Someone outside the perimeter tried to get in. |
| `auth.ip_allowlist.super_admin_override` | Support bypassed the allowlist for a locked-out org. |
| `api_key.allowed_ips_updated` | A key's programmatic perimeter changed. |
| `security.2fa.disabled` | A second factor was stripped from an account. |

***

Every control on this page is tenant-decided and default-off: until you configure it, enforcement is off, allowlists are empty and unrestricted, provisioning defaults are permissive, and redaction follows each surface's default. Re-run this checklist on every material change to your team or architecture, and hand the outcome to the [production go-live checklist](https://docs.orbit.devotel.io/guides/go-live-checklist.md) as its security sign-off.

## See also

* [Production go-live checklist](https://docs.orbit.devotel.io/guides/go-live-checklist.md) — the launch gate this checklist feeds
* [Settings → Security](https://docs.orbit.devotel.io/guides/settings-security-console.md) — the console every control above lives in
* [Account security model](https://docs.orbit.devotel.io/concepts/account-security-model.md) — roles, sessions, and per-role 2FA enforcement
* [Security](https://docs.orbit.devotel.io/guides/security.md) — roles and auditability overview


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