Quick answer: Security posture splits into three questions, and this blog has owned one post for each of the first two: the API-abuse explainer covers what attackers do with a leaked credential or a forged webhook, and the SCIM due-diligence checklist covers identity lifecycle. The third question — how stored data is protected — had no owned post until now. This one maps it: the envelope-encryption design that protects every tenant field by default, the BYOK control plane that puts your organization's key policy on top of it, the exact webhook signature contract your receiver implements, and why key scoping is the piece that holds the rest together. Judges split cleanly: the platform owns encryption of data at rest, your organization owns its BYOK policy, and your receiver owns signature verification.
Always-on envelope encryption, and why the design matters
Every tenant field Devotel Orbit stores — provider secrets, tokens, message payload content, binary compliance documents — is encrypted at rest under a platform key. That is the default, not a setting; an organization that never touches key management is fully covered by it.
The design is envelope encryption with AES-256-GCM: a fresh random data-encryption key (DEK) encrypts each payload, and the DEK is itself wrapped under a key-encryption key (KEK). The wrapped DEK sits beside the ciphertext; the KEK never touches Orbit storage. A database dump therefore carries no usable key. Ciphertext carries a versioned enc:v1: prefix, so read paths distinguish encrypted blobs from legacy plaintext, and a future algorithm change can bump the version while old rows stay readable.
The design choice is what makes the BYOK layer in the next section possible: because the bulk ciphertext is sealed under small DEKs — not one monolithic master key — the expensive operation of moving key governance to a customer KMS is a re-wrap of a few hundred bytes per data key, never a re-encryption of the dataset. The full design, including the KEK-provider seam, is in the encryption-at-rest concept page.
BYOK: a control plane over the same envelope
The second layer is bring-your-own-key: you register a reference to a key in your own KMS — AWS KMS, Google Cloud KMS, Azure Key Vault, or HashiCorp Vault — as your organization's governing policy, move it through a lifecycle (register, activate, rotate, revoke), and set an enforce flag on it. Orbit stores the reference and a truncated fingerprint, not key material.
Two consequences follow for an evaluator. First, the fail-closed posture is owned by your organization: when your key references are unreachable, field-encryption calls that consult your BYOK policy fail closed instead of silently falling back to the platform envelope — a governance guarantee, not a software promise. Second, revocation under a customer KMS is real: disable the KEK in your own KMS and everything sealed under it is undecryptable without any stored data being touched. These are the guarantees enterprise and healthcare RFPs name on paper; the register/activate/rotate/revoke workflow is in the BYOK guide.
Transmission layer: signatures belong to the receiver
Message content leaves the platform as outbound webhook deliveries, and the trust direction inverts — the platform calls your endpoint, where anyone on the internet can POST. Orbit signs every delivery with HMAC-SHA256, and verification happens in code your organization owns. The durable rule to write down is the one the API-abuse explainer puts plainly: a delivery never counts until verification passes, and failed checks drop before your handler runs.
The exact contract your receiver implements is documented in the webhook security guide: a canonical X-Orbit-Signature header on every current delivery carrying a single v1=<hex> over the string <t>.<raw_body>; a X-Orbit-Signature-Next header that appears only during a rotation grace window, signed with your previous secret; and a legacy combined X-Devotel-Signature kept for back-compat. Replay protection comes from checking the t=<unix> timestamp against a five-minute tolerance window and rejecting older deliveries. The failure shapes — clock skew, wrong secret, stale configuration — are catalogued in troubleshooting signature failures.
Scoping: the piece that holds the rest together
None of the above stands alone. Encryption at rest protects stored ciphertext; it says nothing about who can read the plaintext through the API. API keys are the access layer to decrypted data, and scoping them is what keeps the layers coherent. In Orbit that scoping is structural, not conventional: keys carry only the scopes granted at creation, and browser-embeddable public keys (dv_live_pk_ / dv_test_pk_) are restricted to read-only scopes at creation — a request for a write or administrative scope is rejected with a 422. The key classes and the rejection behavior are in the authentication reference, and the abuse cases when scoping is skipped are the entire subject of the API-abuse explainer.
The data-protection checklist
Run these against a candidate's documentation, not its marketing page.
- Is at-rest encryption always on, or a marketed option? An option that must be enabled is a tenant field that was plaintext until someone remembered the checkbox.
- Is envelope encryption the design? DEK-wrapped-by-KEK is what makes BYOK feasible without touching the bulk data and what makes revocation real. A flat master key can do neither.
- Does BYOK fail closed on unreachable key references? Silent fallback to the platform envelope means your organization's key policy was decorative.
- Is the webhook signature contract documented precisely? One header shape per role — current, outgoing during rotation, legacy — with an explicit timestamp tolerance. "We sign webhooks" with no contract is a receiver you cannot write.
- Are key scopes restricted structurally? A public-key class whose read-only restriction is enforced at creation survives a leaked bundle. Policy alone does not.
Frequently asked questions
Does BYOK replace the platform encryption layer?
No. Platform-managed envelope encryption is always on and covers every tenant field. BYOK is a governance layer on top: a registry of your organization's key references, an enforce flag, and fail-closed behavior on unreachable references. An organization that never configures BYOK is fully covered by the platform layer.
Who verifies webhook signatures — the platform or the receiver?
Your receiver. Orbit signs each delivery; verification runs in your endpoint's code, and the verify-before-consume rule is yours to enforce. A provider phrasing this as platform-side protection is claiming something no provider ships — covered in depth in the API-abuse explainer.
Why is scoping an encryption question at all?
Because ciphertext protection ends where API access begins. An unscoped or ambient-admin key is full read access to decrypted data, whatever the storage layer does. Scoping keys to their actual verbs — and keeping public keys to read-only by construction — is what makes the storage-layer guarantee reachable only through the access layer you actually configured.