Enterprise CPaaS evaluations split into two passes. The first pass checks channels: voice, SMS, WhatsApp, email, video. Most credible vendors tie there. The second pass checks identity plumbing: does membership follow the corporate directory, do API credentials survive a leak, can the security team pull an evidence trail during an incident review, and is one customer's data structurally separate from another's. Vendors lose the deal in the second pass, at short-list time, when procurement's vendor security checklist questionnaire lands.
This post is the second pass, written down. It maps the due-diligence questions enterprise security and procurement teams actually ask to the tenant-owned controls in Devotel Orbit that answer them, with the doc that proves each one. Everything here is a control your organization switches on and owns — none of it is a platform mandate, and an organization that never touches these settings keeps working.
Why enterprise buyers short-list on identity plumbing, not features
Feature matrices converge. Channel coverage, per-message pricing, SDK languages, and throughput claims look the same across the three finalists on any CPaaS short list, so the evaluation moves to the axis where vendors genuinely differ: what happens after the contract is signed and two hundred employees need seats.
A buying committee answers to its own audit. The CISO's team asks how access is granted and revoked; if the answer is "an admin keeps a member list by hand," the vendor is volunteering to be the audit finding. Procurement asks what evidence the vendor produces during an incident; if the answer is "open a support ticket," the evaluation ends. These are not edge concerns — they are the short-list filter, applied before anyone compares voice pricing.
The practical consequence for an evaluator: a CPaaS vendor's security documentation is a better predictor of enterprise fit than its channel list. Features can be demoed; identity plumbing either exists as shipped, documented surface or it does not.
What Orbit ships
Each control below is tenant-owned: an owner in your organization turns it on, configures it, and can turn it off. None are platform-mandated posture, and Orbit does not require any of them for a compliance certification.
SCIM provisioning. Orbit speaks SCIM 2.0 per organization, with Okta, Microsoft Entra ID, and OneLogin walked end to end in the SCIM provisioning guide. Provisioning, attribute updates, deactivation that revokes access and active sessions, and group-to-role mapping are all covered. SCIM pairs with SAML SSO — SAML controls how users sign in, SCIM controls which users exist — and both are per-organization settings. The bearer token an organization generates is stored hashed, shown once, and rotation invalidates the previous token immediately.
Per-API-key IP allowlists. Any API key can be bound to a set of source IPs or CIDR ranges, up to 50 entries per key, so a leaked key fails authentication from outside your network with a 401 before it touches billing or tenant data. The per-API-key IP allowlist guide covers the replace-only PATCH semantics and the separate org-wide allowlist that gates dashboard and SAML login surfaces.
Usage budgets and alerts. Each API key can carry org-level hard usage limits plus operator-set monthly request budgets that flag a key at warning and exceeded bands in the dashboard. A runaway integration — or a leaked key being exercised — surfaces as a badge, not a line item on the invoice. The mechanism is in the usage budget alerts guide, and the hard limits it complements are in the usage limits guide.
Audit log. Every action in the organization — membership changes, key creation, role edits, credit transfers, configuration updates — lands in an append-only ledger with actor, action, resource, timestamp, source IP, and a structured before/after detail payload. The audit log guide documents the filters, the CSV/JSON export, and the webhook stream that feeds a SIEM. Rows cannot be edited or deleted through the dashboard or API, by design.
Tenant isolation. Every organization's working data lives in its own PostgreSQL schema, resolved per request from the API key — never from a client-supplied tenant id. The tenant isolation concept page lays out the split between the shared catalog and the per-tenant schema and walks the request-resolution chain.
The due-diligence checklist, answered
Run these questions against any CPaaS vendor on the short list. For Orbit, each has a shipped control and a doc that proves it.
- Can user lifecycle follow our IdP — provision, update, and deprovision without manual member lists? Yes. SCIM 2.0 per organization, with IdP-side setup documented for Okta, Entra ID, and OneLogin. Proof: SCIM provisioning guide.
- Does deprovisioning actually revoke access — not just hide the seat? Unassigning a user in the IdP revokes their Orbit access and every active session on the next sync. Same guide, deprovisioning semantics section.
- Does SSO pair with provisioning, or does the vendor conflate the two? Orbit treats them separately — SAML controls sign-in, SCIM controls membership — which is the model enterprise IdPs expect. See the guide's opening section.
- Can a leaked API key be contained at the network layer? Yes. Per-key IP allowlists reject off-network requests with
401before authentication completes. Proof: IP allowlist guide. - Can usage be bounded per credential, and do we get warned before the invoice? Per-key hard limits bound it; per-key budgets flag the warning and exceeded bands in the dashboard. Proofs: usage limits and budget alerts.
- Is there an audit trail of who did what, and can we prove it was not tampered with? The audit log is append-only — rows cannot be edited or deleted through any customer surface — and records actor, action, resource, timestamp, source IP, and before/after detail. Proof: audit log guide.
- Can the audit trail leave the platform — export and SIEM streaming? CSV/JSON export plus a webhook stream. Same guide, export section.
- How is one customer's data isolated from another's? One PostgreSQL schema per tenant, resolved from the API key on every request, with a shared catalog limited to data no tenant owns. A client-supplied tenant id cannot steer a request into another tenant's data. Proof: tenant isolation.
- Are these controls required of every customer, or tenant-configured? Tenant-configured. An organization that never enables SCIM, sets an allowlist, or opens the audit log keeps working; enterprise posture is your choice, not a mandate.
A vendor that answers all nine with documentation — not marketing copy — survives the questionnaire stage.
How the SCIM lifecycle maps to onboarding
SCIM's value is clearest as a sequence against the first ninety days of an enterprise rollout:
Day 0 — connect. An owner generates the SCIM bearer token under Settings → SCIM, copies the per-organization Base URL, and runs the built-in connection test before the IdP ever calls it. The organization cannot be flipped into the enabled state without a token in place.
Day 1 — seed roles. Assign the first group in the IdP. Synced users land in the default role, or in roles from the group-to-role map — support leads land as admins, agents land as members — without anyone clicking through the member list.
Steady state — drift correction. Name and email changes in the directory flow through on the next sync, so the Orbit member list stops being a second directory someone maintains.
Exit — revoke, not chase. When someone leaves or changes teams, unassigning them in the IdP revokes access and kills active sessions. There is no separate offboarding checklist step against the CPaaS vendor, which is precisely the gap that turns manual member lists into audit findings.
Rotation — planned, not panicked. Bearer token rotation invalidates the previous token immediately, so a scheduled rotation is a two-minute change in the IdP connector, and an unscheduled one is not an incident.
Each stage has a corresponding section in the SCIM provisioning guide, including the sync errors most likely to appear during the first push.
Frequently asked questions
Does Orbit require SCIM or SSO to use the platform?
No. Both are per-organization, tenant-owned controls. An organization without an IdP can manage its member list manually for as long as it wants, and Orbit does not require SCIM for any compliance certification. The controls exist for organizations whose security posture calls for them.
How is the SCIM bearer token stored?
The token is shown exactly once when generated — only its hash is stored — so it must be copied into a password manager or directly into the IdP at creation time. Rotating the token invalidates the previous one immediately.
What happens to active sessions when a user is deprovisioned?
Unassigning a user in the IdP revokes their Orbit access and every active session on the next sync. Deprovisioning is a real revocation, not a hidden seat.
Can the audit log be edited or deleted by anyone in the organization?
No. Entries are append-only: rows cannot be edited or deleted through the dashboard or the API. The log records actor, action, resource, timestamp, source IP, and a structured before/after payload, and it exports to CSV/JSON or streams to a SIEM over webhooks.
Are the IP allowlist and usage budgets org-wide or per key?
Both are per API key. The IP allowlist binds an individual key to up to 50 IPs or CIDR ranges; a separate org-wide allowlist gates the dashboard and SAML login surfaces. Usage budgets are set per key, alongside the org-level hard usage limits.