Security

Our security model

We will describe our security approach precisely, including its current limitations. An accurate description of a security model is more useful to you than an overclaimed one.

End-to-end encryption

SemaFore implements end-to-end encryption for all messages using the Signal Protocol: X3DH (Extended Triple Diffie-Hellman) key agreement with Double Ratchet forward secrecy. This is the same standard used by Signal, WhatsApp, and organisations with an active interest in not being intercepted.

What this means in practice:

Messages are encrypted on your device before transmission. The SemaFore server stores and relays ciphertext. We have no ability to decrypt your messages. A court order served on SemaFore for message content would yield nothing — we do not hold it.

Forward secrecy and break-in recovery:

The Double Ratchet algorithm provides forward secrecy: past sessions are not compromised if a key is later exposed. It also provides break-in recovery: future sessions are not compromised by a present compromise. Key rotation happens automatically.

Symmetric encryption: AES-256-GCM for message encryption. Key exchange: X25519. Key storage: device Keychain (iOS) or Android Keystore — hardware-backed on supported devices.

What we log

We log:

• Authentication events (successful and failed), including timestamp and IP address
• Administrative actions in the organisation audit log
• Message delivery metadata: message reference ID, timestamp, delivery status
• Device registration events
• File transfer events: reference ID and timestamp only

We do not log:

• Message content, in any form
• File content — files are encrypted client-side before upload
• Who sent a message to whom (we log that a delivery event occurred; not its parties)
• Encryption keys
• Push notification content — push payloads contain a reference only

This logging policy is enforced in code, not only in policy. The server implementation prevents message content from entering any log at the application level.

Infrastructure security

Data centres: SemaFore is hosted on Attomus-operated infrastructure in the United Kingdom. No hyperscale cloud provider — no AWS, Azure, or GCP — processes or stores your organisation’s data.

Network: All client-server communication uses TLS 1.3. Certificates are issued by a public certificate authority and renewed automatically. Certificate transparency logs are public and auditable.

Server hardening: The server runs as a non-privileged system user. Dependency vulnerability scanning runs on every deployment. No known critical vulnerabilities are present in the current release at time of publication.

Secrets management: No credentials, encryption keys, or API secrets exist in source code. All secrets are managed through environment variables loaded at startup. Startup fails if a required secret is missing or malformed.

Authentication

Phone number OTP: SemaFore authenticates users by phone number with one-time passwords delivered via SMS. Organisations with specific requirements can configure an alternative provider.

Rate limiting: Authentication endpoints are rate-limited. API endpoints are rate-limited per authenticated user.

Session tokens: Authentication produces a JWT with a defined expiry. Tokens are validated on every request, not only at login.

Third-party security assessment

SemaFore commissions independent penetration testing. Results are available to enterprise customers under NDA. Write to [email protected] to request the executive summary.

We also run continuous automated dependency vulnerability scanning and static analysis on every release.

Responsible disclosure

If you discover a security vulnerability in SemaFore, write to [email protected]. We will acknowledge your report within 48 hours and provide an assessment within 7 days.

We do not operate a bug bounty programme at this time. We credit researchers who report issues responsibly, with their permission.

Current limits

In the interest of accuracy, the following remain unavailable in the current release:

• Screenshot detection and capture prevention — not yet available
• Desktop clients — mobile (iOS and Android) only at present
• Multi-device accounts — a single registered device per account currently

We will update this page as each of these ships.