Skip to main content

​
Pre-Production Security Hardening Checklist

The production go-live checklist 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; the enrollment and enforcement controls sit on Settings → Security. 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 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. Owner: Administrator.
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. 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. 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. 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 and the defaults table in Settings → Security. 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. 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 and Recording redaction. 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 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 and Audit log): Owner: Administrator.
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 as its security sign-off.

​
See also