Skip to main content

​
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) you register from your own KMS, a recognizable enc:v1: encryption-at-rest envelope on stored secrets, an exportable audit ledger with a posture rollup, and a 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. 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 and the envelope notes on channel config pages like Kakao and WeChat.
  • Audit-ledger export. Decryption and access events are retrievable through the API on your own key, not through a support ticket — audit export, with a per-tenant 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. 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.

​
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. 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 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 and WeChat pages and look for the enc:v1: envelope on stored channel credentials; then read the 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 flow on your sandbox key, then check the 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, 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. This page is one entry of the evaluating alternatives catalog — return there for the other capability-class checklists scored on the same template.