Case study · Defence · Ethora Professional Services
On-premise, end-to-end encrypted messaging for a European defence prime, with no traffic leaving its network
An EU-based defence prime wanted Signal-grade encrypted messaging and calls for its staff, running on its own hardware with no dependence on public cloud services. Ethora Professional Services designed, built and installed a fully on-premise messaging system with branded mobile and desktop clients.
By the numbers
The project at a glance
Zero
public cloud services in the message path: storage, CDN, push and contact discovery all run inside the network
3
environments (production, UAT, development) on client-owned servers
1,000
concurrent users as the design target for the production environment
2021
architecture, proof of concept and on-premise install; in use by the client from 2022
Overview
Secure messaging for a defence group that trusts no external cloud
The client is a large EU-based defence and aerospace prime. The project is under NDA, so the client, its partners and its people are not named here. We worked with the client’s cybersecurity partner, which managed the programme on their side.
The challenge. Staff needed end-to-end encrypted messaging, file sharing and voice and video calls on corporate-managed phones, as easy to use as a consumer messenger. But no message, file or piece of metadata could pass through a third party: not a public cloud, not a push service, not a content delivery network. The whole system had to run on the client’s own servers inside its own network, and the client wanted the option to plug in its own cryptographic routines later.
The approach. This was an Ethora Professional Services engagement, led by Ethora founder Taras Filatov and drawing on our team’s decades of experience in messaging and secure communications. In 2021 Ethora did not yet offer end-to-end encryption, so we built the system on the open-source Signal codebase, which provides the well-reviewed Signal Protocol for messages and calls, and then removed every dependency on external services. The lessons from that choice are below: today we would build the same project on Ethora’s own codebase.
Requirements
What the project needed, and how we delivered it
Each requirement is tagged by how it was delivered on this project, and where the same capability is now part of the Ethora platform.
No dependency on any external cloud service
The public messaging stack assumes cloud services at several points. Each was replaced or brought inside the network: self-hosted, S3-compatible object storage (MinIO) for encrypted attachments instead of a public cloud bucket, no CDN, an internal push mechanism instead of Google and Apple push services, and a self-hosted TURN server for one-to-one voice and video calls. Contact discovery, which in the public service relies on secure-enclave servers on the internet, was replaced by an internal directory approach.
Registration that resists abuse without CAPTCHA services
Identity stays the staff member’s mobile number, but the external CAPTCHA service was removed. To compensate, the SMS verification code was lengthened from 6 digits to 32 hexadecimal characters and read automatically by the app, and only numbers on an administrator-managed allowlist can activate the app, so a copied installer is useless outside the organisation.
Branded clients that only talk to the client’s servers
The Android app was compiled from source, rebranded with the client’s name and colours, pinned to the private server’s certificate and delivered with its source code and a build guide, for rollout through the client’s own device management. An iOS client followed from the partner’s team, and we delivered a feasibility study and a working build of a desktop client reconfigured to the private server and trust root.
A build chain that works with no internet connection
Local source repositories and a local artefact repository let the server and the clients be compiled entirely inside the network. The development environment exports installable artefacts to network storage, where UAT and production pick them up, so nothing is downloaded from the internet at deploy time.
Hosting on the client’s own hardware
A dedicated rack of client-owned servers runs virtualised production and UAT environments, plus a development environment. Only the messaging endpoint and file storage are exposed, and only inside the client’s own firewall. The server keeps no state of its own (state lives in PostgreSQL, Redis and object storage on network storage), so it can scale out later; the design target is 1,000 concurrent users on production.
A security review of the code before it went live
Because the public server and client releases had drifted apart, a working pair had to be pinned by experiment. A review of that client version found known zero-click vulnerabilities in its real-time media library, published by Google Project Zero, so the media library was upgraded before rollout. Transport uses TLS with certificate pinning, and the open-source licence obligations were documented for the client.
Visibility for administrators
An internal console lists each registered number, its registration status and presence, with an editable display name. A fuller management console to add and remove users was scoped for a later phase.
Deployment
Everything inside the client’s network
Production, UAT and development run on client-owned servers in the client’s own facility. During the pilot, SMS delivery of verification codes was the only outbound connection, and the client explored an on-premise SMS gateway to remove it. Ethora’s own server can be deployed the same way: see Get Ethora and the self-hosted chat server guide.
Where this stack runs
Security
Controls built into the design
The aim, in the words of the architecture brief: no unencrypted communication to the outside of the client’s network.
End-to-end encryption
Messages, files and calls are encrypted on the device with the Signal Protocol, and transport uses TLS with certificate pinning.
No external services
Storage, push, calls and contact lookup run inside the network, with no public cloud in the message path.
Closed registration
An allowlist of staff numbers and long verification codes stop outsiders and brute-force sign-ups.
Supply-chain control
All builds happen offline from reviewed source, so the client knows exactly what runs on its devices and servers.
Lessons learned
Why we would build this on Ethora today
The Signal Protocol is excellent cryptography. The public Signal codebase, though, is built first for one consumer service, and running it privately exposed real limits:
- Server code lagging the apps. The public server code went unpublished for many months while the consumer apps kept moving, so a compatible server and client pair had to be found by trial and error, and the matching client carried known vulnerabilities that we had to patch.
- Gaps between platforms. The Android, iOS and desktop clients and the server move on separate schedules, and features available in one are often missing or different in another.
- Missing pieces for private use. Contact discovery depends on secure-enclave servers on the internet, group calls depended on a media server that was not public at the time, and the apps assume Google and Apple push services. Each needed its own workaround.
Ethora now offers optional end-to-end encrypted rooms (OMEMO 2), switched on per app by the app owner, alongside encryption in transit and at rest. They are off by default because an encrypted room gives up server-side moderation, search, export and recovery, which many regulated deployments need. With that in place, a project like this one can run on Ethora’s own codebase: one server, web, iOS, Android and React Native stack that we maintain and release together, a self-hosted installer that runs with central monitoring switched off, and full freedom to customise the clients, the server and the deployment for each client.
Signal is a trademark of the Signal Technology Foundation. This project used the open-source Signal code under its licences and is not affiliated with or endorsed by Signal.
The outcome
A private messenger in daily use, on the client’s own hardware
After the architecture was reviewed with the client in May 2021, the proof of concept was demonstrated, installed on-premise in the autumn and in use by the client’s staff by 2022. The programme then grew into follow-on phases: iOS push, group calls, a desktop client, device-level integration with secure mobile platforms, and studies on extracting the cryptography into a replaceable library.
For organisations that need the same level of control, Ethora Professional Services can deliver the full project, from architecture and security review to installation and long-term support, now on Ethora’s own platform.
FAQ
Does Ethora support end-to-end encryption?
Yes, as an option. Ethora encrypts in transit and at rest by default, and app owners can switch on end-to-end encrypted rooms (OMEMO 2) per app. Encrypted rooms give up server-side moderation, search, export and recovery, so regulated deployments that archive messages often keep them off.
Why was the Signal codebase used for this project instead of Ethora?
In 2021 Ethora did not yet offer end-to-end encryption, and the client required it. Ethora now has optional end-to-end encrypted rooms, so a similar project today would run on Ethora’s own codebase, which we maintain and release together across server, web and mobile.
Can the apps carry our brand and connect only to our servers?
Yes. On this project the clients were rebuilt with the client’s name and colours and pinned to its private server. Ethora’s white-label chat app and SDKs work the same way for your own servers.
Do you work under NDA with defence and government clients?
Yes. This client is under NDA, which is why it is not named here. We can share more detail on a call, within what our agreements allow.
More case studies
Healthcare: self-hosted patient messaging for a multi-clinic digital health platform in Canada
VITALL is a Canadian digital health platform used by hospitals, clinics and private practices.
Ethora runs as a self-hosted chat server in VITALL’s own AWS account in Canada, with one isolated tenant per clinic, chat in the practitioner portal and in native iOS, Android and React Native patient apps.
Users, rooms and clinics are provisioned by VITALL’s backend through the Ethora API.
- Self-hosted in the customer’s AWS account in Canada
- One isolated tenant per clinic, created by API
- Web portal, iOS, Android and React Native SDKs
Insurance: in-app chat for a workers’ comp health insurance provider (HIPAA compliant)
Atom Advantage provides workers’ compensation and health insurance solutions in the United States.
On Ethora they built Atom Connect: secure, case-based chat between injured workers, nurses and case managers, embedded in their claims portal and a white-label mobile app. HIPAA and SOC 2 compatible.
Less manual work for case managers and a better experience for injured workers.
- Chat embedded in the case managers’ web portal
- White-label iOS and Android app for injured workers
- One secure room per claim, created automatically by API
Energy: dedicated chat server, AI-agent rooms and a React Native app for a procurement platform
Preshent is a US platform for energy-project procurement with AI-driven decision support.
Ethora provides the conversation layer: a chat room per project workspace shared by people and the AI agent, a dedicated chat server in Preshent’s own cloud, push notifications and a React Native app.
- 1,130 chat rooms, one per workspace
- AI agent as a participant in every room
- Dedicated chat server, 99.99%+ uptime
Need secure messaging that never leaves your network?
Self-hosted Ethora with optional end-to-end encryption, or a fully managed project from Ethora Professional Services.
