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

# Evaluating secure-messaging alternatives

> A tenant-owned scoring rubric for secure/enterprise messaging platforms: key custody, encryption-at-rest envelopes, audit-ledger export, DLP scanning, and consent posture — with a worked scoring table, evaluation surfaces, and the FAQ on when a pure-E2E messenger genuinely wins.

# Evaluating secure-messaging alternatives

Secure-messaging evaluations come down to one question: whether the encryption keys, the decryption audit trail, and the credential envelopes live under your custody. This page gives you the checklist, a worked scoring table for generic "secure messaging" vendors and Devotel Orbit, the surfaces to run the evaluation on, and an FAQ for deciding when a pure end-to-end messenger is genuinely the right tool instead of a CPaaS.

## 1. Gaps buyers hit first

* **E2E encryption claims you cannot verify.** The vendor's marketing page says "end-to-end encrypted" but there is no surface to inspect which key, held by whom, actually encrypts what. Score the verifiability of the claim, not the claim.
* **Vendor-held keys.** The encryption key for your tenant's data lives in the vendor's KMS, so revoking access means asking the vendor. If key custody matters to your threat model, a vendor-held key is a permanent residual risk.
* **No audit of who decrypted what.** Your security team asks "which user or service decrypted this content, and when?" and the incumbent answers with a support ticket. Chain-of-custody questions need an exportable ledger, not a queue.
* **Credentials stored in plaintext-adjacent envelopes.** Channel credentials (WeChat, Kakao), provider tokens, and API secrets come back from the API readable by any viewer. An envelope scheme you can recognize — and verify — beats a promise.

Orbit closes these with tenant-owned controls: [customer-managed keys (BYOK)](/compliance/byok-customer-managed-keys) you register from your own KMS, a recognizable [`enc:v1:` encryption-at-rest envelope](/concepts/encryption-at-rest-model) on stored secrets, an exportable [audit ledger](/compliance/audit-export) with a [posture rollup](/compliance/audit-ledger-posture-rollup), and a [DLP scanner](/compliance/dlp-scanner) that flags sensitive content before sending.

## 2. Tenant-owned checklist rows

Score every candidate on five rows you can verify about any vendor:

* **Key custody (BYOK).** The encryption-key reference lives in your own KMS (AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault), and you activate, rotate, and revoke it yourself — [customer-managed keys](/compliance/byok-customer-managed-keys). No key material ever leaves your KMS; the platform stores only the reference and echoes a truncated fingerprint.
* **Encryption-at-rest envelope.** Stored secrets come back from the API in a recognizable envelope (`enc:v1:…`) instead of plaintext — see the [encryption-at-rest model](/concepts/encryption-at-rest-model) and the envelope notes on channel config pages like [Kakao](/channels/kakao) and [WeChat](/channels/wechat).
* **Audit-ledger export.** Decryption and access events are retrievable through the API on your own key, not through a support ticket — [audit export](/compliance/audit-export), with a per-tenant [posture rollup](/compliance/audit-ledger-posture-rollup) so you can verify ledger completeness before you trust it.
* **DLP scanner.** Outbound messages are scanned for sensitive-content patterns (credentials, financial identifiers, health data) before sending, with per-tenant rules you own — [DLP scanner](/compliance/dlp-scanner). Per the tenant-ownership principle this control is tenant-configured, default-open — you decide it, the platform does not impose it.
* **Consent posture.** Per-recipient consent and suppression records are tenant-owned objects you govern — [consent management](/compliance/consent-management).

## 3. Scored candidates

Score each candidate "yes / partial / no" per row, at the level of the published product surface; a blank cell reads as missing research, so mark "partial" or "no" instead of leaving one.

| Checklist row               | Pure-E2E messenger (Signal-class)                                         | Generic enterprise "secure messaging" vendor                                  | Devotel Orbit                                                                            |
| --------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Key custody (BYOK)          | partial — keys are protocol-owned, not tenant-KMS-registered              | partial — some vendors offer BYOK on enterprise tiers, often as an add-on     | yes — register, activate, rotate, revoke a key reference in your own KMS                 |
| Encryption-at-rest envelope | no — envelope is client-side protocol, not an API-verifiable artifact     | partial — "encrypted at rest" stated, envelope rarely verifiable from the API | yes — `enc:v1:` envelope returned by the API, documented in the encryption-at-rest model |
| Audit-ledger export         | no — the protocol deliberately minimizes server-side metadata             | partial — export often limited to admin-console CSV, or behind a support path | yes — self-serve API export plus a posture rollup to verify ledger completeness          |
| DLP scanner                 | no — content is encrypted client-side, so no server-side scan is possible | partial — scanning exists on some tiers; tenant-owned rules vary              | yes — tenant-owned sensitive-content rules scanning outbound messages                    |
| Consent posture             | no — consent is a social signal, not a tenant-owned record                | partial — consent handled per vendor policy                                   | yes — tenant-owned consent and suppression objects                                       |

Read the two non-Orbit columns honestly: a pure-E2E messenger genuinely wins the "server cannot read content" axis — that is exactly why it scores "no" on audit export and DLP. Those are mutually exclusive properties; the checklist exists so you pick the trade-off that matches your threat model, not the vendor's marketing page.

## 4. Evaluation surfaces

Ground every claim from a vendor on the same surfaces you would run Devotel Orbit against:

* **API key handling** — create a `dv_test_sk_` sandbox key from the [authentication](/authentication) surface with no KYC or approval step; simulated sends cost \$0. Verify what the key can and cannot see — that is the first probe any secure-messaging evaluation should run.
* **Encryption-envelope notes on channel config pages** — open the [Kakao](/channels/kakao) and [WeChat](/channels/wechat) pages and look for the `enc:v1:` envelope on stored channel credentials; then read the [encryption-at-rest model](/concepts/encryption-at-rest-model) for the envelope semantics. If a candidate cannot show you the envelope a stored secret comes back in, the "encrypted at rest" claim is unverifiable.
* **Audit-export endpoints** — run the [audit export](/compliance/audit-export) flow on your sandbox key, then check the [posture rollup](/compliance/audit-ledger-posture-rollup) to confirm the ledger is complete before trusting it as evidence.
* **BYOK registration surface** — register a throwaway key reference from a test KMS on the [BYOK page](/compliance/byok-customer-managed-keys), activate it, rotate it, and revoke it. The whole lifecycle is the evaluation; a vendor that cannot demo it cannot score "yes."

Use the same surfaces for every candidate on your shortlist — the point of the checklist is that you own the verdict, wherever it lands.

## 5. When not to move — FAQ

**When does a pure-E2E messenger (Signal-class) genuinely win over a CPaaS?**
When your threat model requires that the platform operator — any operator, including us — cannot read message content, and you do not need the things a CPaaS gives you: audit-ledger export, DLP scanning, channel orchestration, or consent records. A journalist's source channel, a small team's internal coordination under legal threat, or a recipient set that expects Signal-protocol semantics are all cases where the pure-E2E answer is the right answer. The checklist scores that honestly: it trades auditability for content opacity, and sometimes that is the correct trade.

**Should we move our enterprise messaging off the incumbent?**
Not when the incumbent's "secure messaging" claim is verifiable on the same surfaces above — an exportable audit ledger, a customer-verifiable key-custody story, a recognizable envelope — and the rest of your integration is deep. Run the checklist; if the security rows score "partial" on both sides, the move argument is weak. And per the tenant-ownership principle, every control above except the one federal TCPA dialing-window guard is tenant-configured and default-open — if you did not configure BYOK or DLP on the incumbent or on Orbit, neither platform imposed it on you.

**Do we have to give up the incumbent while we evaluate?**
No. Key-custody registration, audit export, and envelope verification are additive evaluation work: provision a sandbox key, walk the BYOK lifecycle against a test KMS, and run the audit-export flow. Move a single channel only after the scoring table confirms the custody rows have moved.

## 6. Hub link back

This page is one entry of the [evaluating alternatives](/alternatives) catalog — return there for the other capability-class checklists scored on the same template.

## Related references

* [Customer-managed keys (BYOK)](/compliance/byok-customer-managed-keys)
* [Encryption-at-rest model](/concepts/encryption-at-rest-model)
* [Audit export](/compliance/audit-export)
* [Audit-ledger posture rollup](/compliance/audit-ledger-posture-rollup)
* [DLP scanner](/compliance/dlp-scanner)
* [Consent management](/compliance/consent-management)
* [Authentication](/authentication)
* [Kakao channel](/channels/kakao)
* [WeChat channel](/channels/wechat)