How It Works

The architecture in plain terms

SemaFore is not a modified consumer messaging app. It was designed from the beginning as an enterprise platform with the following properties:

• Every employee account belongs to an organisation, not to an individual
• Encryption keys are generated on each device and never transmitted to our servers
• Administrators have full control over user access without the ability to read messages
• The core messaging servers are stateless with respect to message content — they cannot be compelled to produce something they have never seen

The signal chain

A message sent from a SemaFore mobile client moves through the system like this:

Your device
→ Message composed in app
→ Recipient's public key fetched from server (if not cached)
→ Session established via X3DH key agreement
→ Message encrypted with AES-256-GCM, Double Ratchet forward secrecy applied
→ Encrypted message transmitted to SemaFore server over TLS 1.3
→ Server stores ciphertext, queued for recipient
→ Recipient device connects
→ Ciphertext delivered to recipient device
→ Recipient device decrypts with private key (never left their device)
→ Message displayed

At no point in this chain does plaintext exist on the server or in transit outside of a TLS-encrypted connection between a device and the server.

Portal-admin broadcasts follow a separate path. Their plaintext passes over TLS to the Cloudflare-hosted portal service, which creates a separate encrypted envelope for each recipient before sending those envelopes to the SemaFore messaging server. Cloudflare is not used to store the broadcast.

For employees

Getting started. Your organisation administrator adds you to the platform by phone number. You receive a verification SMS, download the SemaFore app, verify your identity, and your account is ready. There is no separate username or password to manage. Your identity is your verified phone number and your registered device.

Sending messages. Private conversations and group conversations work as you would expect from any messaging application. Your device handles encryption automatically. You do not need to understand or manage it.

Files. Files are encrypted on your device before upload. The server stores and relays ciphertext. Attomus cannot see the content of any file transferred through the platform.

When you leave. Your administrator revokes your access. Your account ceases to exist. The messages encrypted to your keys are no longer accessible. There is no residual access.

For administrators

Starting an evaluation. Apply through the SemaFore evaluation programme. Once approved, the nominated administrator receives the organisation access details. Approved organisations can use the free tier with up to 5 members and no time limit.

Adding members. Enter employee phone numbers in the Members section of the portal. They receive an SMS with a link to download the SemaFore app. Once they register their device, it appears in the portal for your approval.

What you can see. You have full visibility of who is in your organisation, when they joined, when they were last active, and the organisation audit log. The audit log records defined security and administrative events, including the actor, timestamp, event type, outcome, and relevant target identifiers. It does not contain message or file content.

What you cannot see. Message content. This is an architectural constraint, not a policy promise. The encryption keys that would be required to read messages are generated on devices you do not operate and are never transmitted to any server.

Access management. Approving a new device is one tap. Revoking a member’s access is immediate and complete — the revoked user loses access to the platform and all future messages. Historical messages remain encrypted to keys they no longer have access to.

For IT and security teams

Encryption: Signal Protocol — X3DH (Extended Triple Diffie-Hellman) key agreement with Double Ratchet forward secrecy. AES-256-GCM for symmetric message encryption. X25519 for key exchange.

Forward secrecy: Key rotation and one-time pre-key replenishment run automatically. Past sessions are not compromised if a key is later exposed.

Key storage: Device Keychain (iOS) or Android Keystore — hardware-backed on supported devices. Keys are never transmitted to servers.

Transport: TLS 1.3 minimum for all client-server communication.

Push notifications: Metadata only. Push payloads contain a message reference — never content. Devices fetch and decrypt locally on wake.

Authentication: Phone number OTP via configurable provider. Session JWTs with defined expiry, validated on every request.

Infrastructure: The messaging servers and customer message and file ciphertext storage run on Attomus-operated UK infrastructure. The public website and portal interface run on Cloudflare; the Privacy notice describes the separate support-service boundary.

Operational records and telemetry: Private-message delivery receipts retain message, sender, recipient-device, and delivery-status references. Group delivery records retain the message, group, sender, and timestamps. Separate delivery telemetry contains only aggregate successful-delivery counts by organisation and time bucket. Broadcast audit entries record the sender, timestamp, message identifier, and envelope and recipient counts. None of these records contains message or file content.

Deployment options:

Managed service — Attomus operates the infrastructure. You control user access. Appropriate for most organisations.

Private deployment — SemaFore deployed within your own infrastructure. Your data never leaves your environment. Appropriate for organisations with specific data residency or air-gap requirements. Get a briefing to discuss requirements.

Third-party assessment: SemaFore commissions independent penetration testing. Results available to enterprise customers under NDA: security@attomus.com

For the deeper security model, see Security Approach and the Architecture and Threat Model whitepaper.