Security Approach

Security choices with operational consequences

Adopting secure messaging is an operational decision, not just a technical one. The important questions are practical: who can recover content, what happens after a lost device, how external collaborators are approved, what audit evidence remains, and where the service runs.

SemaFore’s answer is consistent across the product: give the organisation control and evidence without creating a central place where private message content can be recovered. For the engineering model, see the Architecture and Threat Model whitepaper.

Cryptographic posture and account recovery

Can an administrator or SemaFore support reset a user’s password or recover their historical message archive?

No. SemaFore operates on a strict zero-trust, non-custodial privacy model. Cryptographic session keys are locked directly within the user’s device hardware (iOS Secure Enclave / Android Keystore) and are never exposed to our servers or any Attomus system. While this means historical message content cannot be recovered if a device is permanently lost or destroyed, it guarantees that content remains entirely inaccessible to unauthorised third parties, insider threats, or server-side adversaries.

Centralised key recovery is a back door. SemaFore does not build back doors.

If a user loses their device, what happens to their historical messages?

If the user has other registered devices, those devices retain their own copies of historical content; the new device replacing the lost one can be onboarded as a fresh device and will receive new messages from the point of onboarding forward.

If the user has no other registered devices, the historical content on the lost device is unrecoverable. That trade-off is intentional: any mechanism capable of recovering that content would also be capable of being abused by an attacker, an insider, or a subpoena. If your organisation has a formal requirement for centralised content recovery, check that requirement during procurement. SemaFore is designed for teams that prefer device-held content and server-side audit evidence over centralised plaintext recovery.

What does our organisation lose access to if a user departs unexpectedly?

User content on devices that the departing user controls. Organisational metadata, audit logs, group membership records, broadcast histories, screenshot reports, billing records, and admin actions remain available to the organisation through the normal admin and audit interfaces. SemaFore’s audit and retention surfaces are deliberately designed to satisfy lawful retention obligations on metadata and event records; content retention sits with the user as the legitimate custodian of their own communications, in line with the typical position of regulated communications platforms.

Can Attomus engineering recover content under court order or warrant?

No. Attomus cannot produce content it never had access to. End-to-end encryption is not a marketing position for SemaFore; it is an architectural property that limits what Attomus can be lawfully compelled to disclose. Subpoenas served on Attomus for customer message content can be honestly responded to with proof that the content is mathematically inaccessible from the server tier.

This makes SemaFore suitable for customers whose threat model includes compelled-disclosure risk. If your operating model requires recoverable content under court order, a recoverable-archive platform may be a better fit.

What does the organisation do if a user is suspected of misconduct?

Investigations of suspected user misconduct rely on the organisation’s metadata audit surface (communication-graph audit, timing audit, group membership audit) plus the organisation’s existing supervisory and disciplinary processes. SemaFore’s audit surface provides the metadata visibility regulated organisations expect; content review, where lawfully required, proceeds through the user’s own device, typically under supervised custody as part of an established investigation procedure.

What about MDM (mobile device management) integration?

SemaFore is compatible with standard mobile device management deployment. MDM-controlled devices may have restricted backup, restricted screenshot capability, restricted copy-to-clipboard, and other organisational controls applied to the SemaFore application alongside other managed apps. The MDM integration surface is a feature of the platform’s enterprise deployment posture, not a separate architectural concern.

External collaboration and onboarding

Why can’t users automatically invite external contacts using their phone’s address book?

Data isolation is a core security boundary of the platform. SemaFore does not scrape, upload, or otherwise consume individual users’ device address books. Consumer-style address-book discovery is the opposite of the controlled onboarding model SemaFore is built for.

Cross-organisational coordination and external supplier communication are managed exclusively through administrator-mediated paths, such as delegated invites and approval-gated external rooms. This ensures that every external connection remains visible to the organisation’s governance, risk, and compliance frameworks.

How do users onboard?

Users onboard through administrator-issued invitations. The administrator generates an invitation, the prospective user receives the invite, and the user completes verification (phone OTP, optional TOTP, organisational membership approval). This deliberate provisioning model gives the organisation visibility and control over its own user population at all times.

How do users coordinate with external parties (suppliers, partners, contractors)?

Cross-organisational collaboration is supported through admin-mediated channels: delegated external-user invitations issued by the customer organisation’s administrator, time-bounded external collaboration rooms, and audit-trailed external participation. The external party’s participation is fully visible to the customer organisation’s audit, compliance, and supervision functions.

This is materially different from consumer address-book auto-discovery. The customer organisation knows exactly which external parties are participating in which conversations and can revoke access on the organisation’s terms. For regulated teams, this visibility is the point.

What about temporary cross-organisation collaboration during incidents?

The same delegated-invite path supports time-bounded collaboration. An organisation administrator can issue an invitation for a specific external party with a defined expiry, restricted to a specific room or thread, with full audit-trail of every message and action.

Why is this preferable to letting users invite anyone they want?

Most security incidents at large organisations involve the exfiltration of sensitive information through informal channels — personal email, consumer messaging, ad-hoc external invitations. SemaFore’s invitation model is designed to make the right thing easy (admin-mediated external collaboration with full audit trail) and the wrong thing impossible (silent ad-hoc external invitations without organisational visibility).

If your organisation does not need this level of control, SemaFore may be more structured than you need. If your procurement process requires visible, revocable, audit-trailed external collaboration, the invitation model is part of the value.

Adjacent concerns

What happens during planned platform maintenance?

Planned maintenance windows are notified to customer organisation administrators in advance, sized per the customer’s contracted SLA. The deployment topology supports rolling upgrades for most maintenance scenarios; planned full-platform downtime is rare and pre-notified.

How is content retention handled?

Per-organisation retention policy is configured by the customer organisation’s administrator and enforced on the server side. The retention policy applies to metadata, audit logs, and content-existence proofs; content retention sits with the user device per the cryptographic architecture described above. Detailed retention behaviour is recorded in ADRs 0093, 0094, 0095, and 0097, summarised in the Architecture and Threat Model whitepaper.

How does SemaFore handle compliance audit?

Per-organisation SIEM export, audit log queries through the admin interface, and content-existence proofs sufficient to demonstrate that a specific encrypted message existed and transited the platform. The audit surface is documented and is a deliberate first-class part of the product. For customers with specific regulatory regimes (FINRA, FCA, HIPAA, et al), the audit posture should be validated against the regime’s specific requirements during procurement.

Where does SemaFore deploy?

UK-resident, Attomus-controlled infrastructure. The deployment shape and scale-out path are described in the Architecture and Threat Model whitepaper.

Where can I read the engineering detail?

The Architecture and Threat Model whitepaper covers the threat model, cryptographic architecture, infrastructure posture, and multi-device wire format in engineering detail. Substantive technical concerns are best directed at that document or to the security disclosure path for issues that require coordinated disclosure handling.

For procurement review, security questionnaires, or deployment constraints, request a briefing.