Security

Our security model

Security claims should be precise. SemaFore is built around a simple constraint: messages and files from the mobile clients are encrypted before they reach the messaging server, and that server has no keys to read them. Portal-admin broadcasts are encrypted into per-recipient envelopes by the portal service before they reach the messaging server.

Key recovery, onboarding, retention, and audit are covered in Security Approach.

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 sent from a SemaFore mobile client are encrypted on the device before transmission. Portal-admin broadcasts are encrypted by the portal service into per-recipient envelopes. The SemaFore messaging server stores and relays ciphertext and has no keys with which to decrypt 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

SemaFore keeps different records for different operational purposes:

• Organisation audit log: defined security and administrative events, including the actor where applicable, timestamp, event type, outcome, and relevant target identifiers.
• Private-message delivery state: message identifiers, sender and recipient-device identifiers, and sent, delivered, and read timestamps and status.
• Group delivery state: message, group, and sender identifiers and relevant timestamps.
• Aggregate delivery telemetry: successful private and group delivery counts by organisation and time bucket, without sender, recipient, or message identifiers.
• Broadcast audit metadata: sender identity and role, timestamp, message identifier, envelope count, and recipient count. The audit entry does not contain the recipient list.

These records do not contain:

• Message content, in any form
• File content — files are encrypted client-side before upload
• 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: The SemaFore messaging servers and customer message and file ciphertext storage run on Attomus-operated infrastructure in the United Kingdom. AWS, Azure, and GCP are not used for that core service or its storage. The public website and portal interface run on Cloudflare; support requests are handled under the separate service boundary described in the Privacy notice.

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.

What SMS verification does and does not protect

SMS OTP gates enrolment and session establishment only. It is not part of the message encryption model. An OTP does not generate, disclose, or recover message content or encryption keys; each device generates and retains its own private keys.

Authentication requests are rate-limited. If a number is not already attached to an approved member, enrolment creates a pending membership which is visible to the organisation administrator and requires approval.

SMS remains susceptible to SIM-swap attacks. An attacker who takes control of an existing member’s number may be able to establish a session as that member. They do not obtain historic messages or the private keys held by the existing device. The organisation should revoke the member’s access while control of the number is recovered.

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.

Engineering reference

For readers who want the implementation-level view, see the Architecture and Threat Model on docs.semafore.io. It covers the threat model, wire format, infrastructure posture, and the ADR-grounded cryptographic design in detail.

Third-party security assessment

SemaFore commissions independent penetration testing. Results are available to enterprise customers under NDA. Write to security@attomus.com to request the executive summary.

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

Responsible disclosure

Vulnerability reports for SemaFore are handled under Attomus’s Vulnerability Disclosure Policy — the canonical policy covering SemaFore and all other Attomus products. Contact: security@attomus.com. We acknowledge reports within 48 hours and provide an initial assessment within 7 days. We do not operate a bug bounty programme at this time; researchers are credited with their permission.

Current limits

At present, the following are not available 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

This list changes as new platform capabilities ship.