Regulated teams keep drifting to consumer chat apps because the approved tool is slower or less private, and that gap has produced some of the largest record-keeping penalties in financial services. In September 2022 the US SEC announced more than $1.1 billion in combined penalties against 16 firms whose staff routinely discussed business over text messaging apps on personal devices from January 2018 to September 2021, with most of those messages never kept. Buying a secure enterprise messaging platform is how organisations try to close that gap: end-to-end encryption that people trust, combined with the retention, administration and device controls that compliance needs. This vendor-neutral buyer's guide is for security, compliance and IT teams choosing such a platform. It does not explain the protocols themselves; for double ratchets, MLS and key transparency read the End-to-End Encryption and Messaging Protocols Guide, and for capture and supervision policy read the Enterprise Messaging Retention and Off-Channel Communications Guide.
Key takeaways
- Encryption and retention must coexist by design. Ask exactly where messages are decrypted for archiving, who holds those keys and what the archive copy is protected with; "E2EE plus compliance" can mean very different architectures.
- Key management decides who can read your data. Customer-held keys, per-device keys and documented recovery paths matter more than the cipher names on the datasheet.
- Adoption is a security control. If the approved tool is worse on mobile or cannot reach external contacts, staff will return to consumer apps, so test usability with the people most likely to go off channel.
- Federation widens the trust boundary. Every external domain, bridge or guest account is a path for data to leave and for impersonation to enter.
- Sovereignty is a set of testable facts. Data location, operator location, metadata handling and lawful access exposure should be written answers, not a region picker.
Define requirements
- Record-keeping duties: which regulations apply (for example SEC and FINRA books and records rules, CFTC rules, FCA recording rules in SYSC 10A), which roles are in scope, and how long messages, edits, deletions and attachments must be kept.
- Threat model: are you protecting against the platform operator, foreign lawful access, a compromised admin, device theft, or mainly against staff using unmanaged apps? The answer decides how much end-to-end encryption and customer key control you need.
- User groups: executives, traders, clinicians, incident responders and field staff have different needs; incident responders also need an out-of-band channel that survives a compromise of your main identity provider.
- External communication: clients, regulators, partners and suppliers, and whether they will install your app, join as guests or need federation.
- Device estate: corporate-owned, BYOD with work profiles, or unmanaged; which MDM and mobile application management stack must integrate.
- Data residency and operator requirements: jurisdictions where data, keys, backups and metadata may sit, and whether a self-hosted or customer-operated deployment is required.
- Integrations: identity provider (SAML or OIDC sign-in, SCIM provisioning), archive or eDiscovery system, DLP, SIEM and any bots or AI assistants that will read messages.
Capability areas
| Area | What to look for |
|---|---|
| End-to-end encryption | E2EE on by default for one-to-one, group, voice, video and file transfer; a published protocol description (a double ratchet or MLS, RFC 9420); forward secrecy and post-compromise security; independent cryptographic review |
| Key management | Per-device keys generated on the device; clear model for adding and revoking devices; key verification or key transparency; customer-managed keys for any server-side encrypted data, ideally in your own KMS or HSM |
| Archiving and eDiscovery | Capture of messages, edits, deletions, reactions, attachments and call metadata; export in standard formats to your archive; legal hold; documented point where content is decrypted for capture and how that point is secured |
| Retention and deletion | Retention policies by user group, disappearing messages that can be disabled or overridden for regulated roles, defensible deletion when retention ends |
| Identity and administration | SSO, SCIM, phishing-resistant MFA, role-based admin with separation of duties, admin action logs, rapid account and device revocation for leavers |
| Mobile controls | MDM and app protection policies (copy and paste, screenshot and backup restrictions, remote wipe of the app container), jailbreak and root detection, secure local storage |
| Federation and external access | Allow lists of external domains, guest accounts with expiry, clear marking of external participants, no silent bridging to consumer networks |
| Sovereignty and hosting | Data and metadata location, operator and support staff location, self-hosting or dedicated-tenant options, subprocessor list, transparency reporting on government requests |
| Assurance | Recent independent audits (for example ISO/IEC 27001 certification or SOC 2), public security documentation, a vulnerability disclosure programme |
The MLS architecture document (RFC 9750) is a useful lens for any MLS-based product: it states that the delivery service cannot read group content but can see membership, delay or drop messages and serve stale keys, while a compromised authentication service could allow impersonation. Ask vendors how they limit both.
Evaluation criteria
| Criterion | What good looks like | How to test it | Suggested weight |
|---|---|---|---|
| Compliant capture | Complete capture including edits and deletions, delivered to your archive within a defined time, with integrity evidence | Send, edit and delete messages in a regulated group; find them in the archive | [25%] |
| Encryption and key control | E2EE by default, documented protocol, customer-controlled keys for server-side data, no vendor ability to read content | Review the cryptographic white paper and an independent assessment | [20%] |
| Usability and adoption | Mobile experience comparable to consumer apps; external contacts reachable | Pilot with a front-office or executive group for two weeks; survey them | [15%] |
| Identity and device lifecycle | SCIM deprovisioning revokes all devices within minutes; lost device wipe works | Disable a pilot user in the IdP and time device revocation | [15%] |
| External and federation controls | Domain allow lists, guest expiry, visible external labels | Invite an unapproved external domain; confirm it is blocked | [10%] |
| Sovereignty and assurance | Written data, metadata and operator locations; current audit reports | Compare contract schedules with the architecture description | [10%] |
| Integration and logging | Admin and security events streamed to SIEM; DLP hooks | Trigger an admin change and find it in the SIEM | [5%] |
Weights in brackets are illustrative: a trading floor will weight capture higher, a security team choosing an out-of-band channel will weight key control and independence from the corporate IdP higher.
Questions to ask vendors
- Where exactly are messages decrypted for archiving, which component holds the archiving keys, and can your staff access that component?
- Are edits, deletions, disappearing messages, reactions and voice calls captured, and how do you prove the archive is complete?
- Which protocol do you use for groups, has it had an independent cryptographic review in the last two years, and can we read the report?
- How are new devices added to an account, how is a user warned when a contact's keys change, and do you support key transparency?
- What happens to all of a user's sessions and devices when we disable them in our identity provider, and how long does it take?
- Can disappearing messages be disabled or forced to archive for specific groups of users?
- Which metadata (contact lists, group membership, IP addresses, timestamps) do you keep, for how long and where?
- Can external parties join without installing a full client, and how are external participants labelled in a conversation?
- In which jurisdictions are data, backups, keys and support staff located, and how many government data requests did you receive last year?
- How are bots, integrations and AI features authorised, and do they break end-to-end encryption for the conversations they join?
Red flags
- "End-to-end encrypted" where the vendor also holds keys that can decrypt every message, with no disclosure of that fact.
- Compliance capture that depends on users running a second app or forwarding messages themselves.
- No independent cryptographic review, or a proprietary protocol with no public description.
- Disappearing messages that administrators cannot disable for regulated users.
- Device revocation that waits for the device to check in, or account recovery by SMS or email reset alone.
- Integrations and AI assistants that receive message content without per-workspace approval or logging.
- A "sovereign" offer where support staff or metadata processing sit outside the stated jurisdiction.
Proof of concept
- Scope: pick two pilot groups, one heavy mobile user group with external contacts and one regulated group with retention duties, plus your compliance and eDiscovery staff.
- Integrate identity: connect SSO and SCIM in a test tenant, enforce phishing-resistant MFA and confirm admin roles are separated.
- Prove capture: run a scripted set of messages, edits, deletions, files and calls, then retrieve them from your archive and place one on legal hold.
- Test mobile controls: enrol corporate and BYOD devices, apply app protection policies, then wipe a lost device and confirm the container is removed.
- Test external access: invite an approved and an unapproved external domain and check labelling, blocking and guest expiry.
- Test leaver handling: disable a pilot user in the IdP and time how long until every device stops receiving messages.
- Review evidence: read the cryptographic white paper, audit reports and data processing terms against your sovereignty requirements.
- Score and clean up: score against the criteria, survey pilot users on whether they would still use consumer apps, then delete test tenants, tokens and integrations.
After rollout, track the share of regulated users active on the platform, archive capture completeness, time to revoke devices for leavers, and the number of off-channel incidents found in surveillance or reported by staff. For the personal side of messaging hygiene, see the Securing Messaging Apps Guide.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: End-to-End Encryption and Messaging Protocols Guide · Enterprise Messaging Retention and Off-Channel Communications Guide · Securing Messaging Apps Guide · Email Encryption