Skip to content

Security and data protection

What protects your data, and what does not exist yet

Enclessa is in open beta, and it protects data in four layers: MLS end-to-end encryption per RFC 9420 for direct messages, so the server holds no key that opens them; tenant isolation asserted at a single choke point and proven by a generated test suite that drives every API operation across organisation boundaries; European hosting under a German seller; and operational controls including audit logging, per-organisation rate limits, retention rules and full data export. Enclessa holds no compliance certifications and has not undergone an external security audit — what stands in their place is a public standard rather than our word: the encryption is MLS per RFC 9420 through OpenMLS, and the architecture, the data model and the OpenAPI surface are published, so an auditor can review how the platform works without reading our source.

Open betaThe platform is being built in the open, so parts of it are not there yet, behaviour changes between releases, and no availability figure is committed while it is in beta. What is still being built.

At a glance

Encryption protocol
MLS, RFC 9420, via OpenMLS
Key scope
One key per device; the server holds none
Hosting
European Union, single region
Tenant isolation
286 API operations probed across the boundary, all refused
Certifications
None held
External audit
Not yet performed

Encryption

Direct messages and group direct messages are end-to-end encrypted with MLS, the IETF standard published as RFC 9420, implemented with OpenMLS and compiled once in Rust so every client runs identical cryptographic code. Each device is a separate member of the group, so adding one is visible and removing one re-keys the conversation.

  • One key per device, never one per account
  • Forward secrecy and post-compromise security from the protocol, not from policy
  • The server implements the delivery service and performs no MLS cryptography
  • Device cross-signing and safety numbers for out-of-band verification
  • Encrypted key backup so a lost device is not lost history
  • Everything in transit over TLS; managed content encrypted at rest

Tenant isolation

Several organisations share one installation and no row crosses between them. The organisation is asserted at one choke point rather than remembered at each call site, and a request for another organisation’s object is answered with a not-found rather than a forbidden, because a forbidden confirms that the object exists.

  • A probe suite generated from the OpenAPI document drives every operation across the boundary
  • 286 operations driven, 286 refused — and the suite fails the build if that regresses
  • Files and audit records carry the organisation they belong to
  • Every metric and log line is labelled with the organisation id, never its name

Access control

Permissions are a bitmask evaluated in the data layer, so a capability that is not granted is not merely hidden in the interface. An organisation names its own roles over that bitmask, and a role can never carry a permission its author does not hold, which closes the usual privilege-escalation path.

  • Exactly one owner per organisation, transferable, enforced by a database constraint
  • Administrators cannot grant themselves billing authority; only the owner holds it
  • Permission overwrites per category, channel and board
  • Field-level permission resolution in the People module across seven roles
  • Bot accounts and personal access tokens scoped to named operations

Operating the service

The controls that matter after launch rather than at signature. Rate limits are applied per organisation and scaled by seat count, with each member capped at a share of the whole, so one runaway integration cannot exhaust the budget for everybody else.

  • Per-organisation rate limits, with per-member caps
  • Storage accounting and per-organisation usage records
  • Retention configurable per organisation; the default keeps data
  • Full organisation data export
  • Audit log of administrative action, scoped to the organisation
  • Uploads scanned for malware before they can be opened
  • Link previews fetched behind SSRF protection, never from your browser

Who at Enclessa can see your data

The platform control plane — the part our operators use — is a separate identity with its own sessions, its own audit log and a deliberately blind interface: it can list organisations, suspend one, schedule a deletion and run a purge, and it cannot read content. That is enforced by a build check, not by a policy document: the control-plane package is not permitted to import anything that can read your content, and continuous integration fails if that ever changes.

  • Operator accounts are separate identities with mandatory multi-factor authentication
  • The control plane sees metadata: organisations, lifecycle, counts
  • A build check forbids the control plane from importing content-reading code
  • There is no impersonation feature and no silent support access
  • Operator action is written to a separate platform audit log

Supply chain

Enclessa itself is a commercial product and its source is not published. Everything it runs on is open source under an OSI-approved licence, and that is enforced by a licence gate in continuous integration that fails the build when a dependency relicenses. Several otherwise obvious components are absent from the stack for exactly this reason.

  • Zero non-OSI runtime dependencies, checked on every build
  • Dependencies updated weekly rather than quarterly
  • PostgreSQL, NATS and LiveKit underneath — components you can audit yourself
  • The cryptography is OpenMLS, an audited open-source implementation of RFC 9420

What Enclessa does not have

Every item below is something a buyer will eventually find out. Finding it here is cheaper for both of us than finding it in week six of a procurement.

No certifications

Enclessa holds no ISO 27001, SOC 2, HIPAA or comparable certification. Anyone requiring one as a procurement gate should treat that as decisive today.

No external security audit yet

The cryptography uses an audited library, OpenMLS, but Enclessa’s own implementation has not been through a third-party audit. That is planned work and is not finished work.

No regional data residency

The hosted service runs in one European Union region. There is no choice of country within it. Where that is not sufficient, the Enterprise plan buys a dedicated deployment in a region you name, still operated and updated by us — the software itself is never handed over.

No single sign-on yet

Sign-in is by email and password. Integration with an external identity provider, and SCIM provisioning, are planned enterprise work and are not available.

Managed channels are readable by the server

That is deliberate — it is what makes search, retention and compliance export possible — but it means channel content is not protected the way a direct message is. Choose the room to match the sensitivity.

Reporting a vulnerability

  • Report privately to the security contact rather than in a public issue. You will get an acknowledgement and a timeline.
  • Do not test against another organisation’s workspace. Create your own and test that.
  • Enterprise customers receive security advisories ahead of public disclosure.
Questions

Security questions we are asked

Is Enclessa GDPR compliant?

Enclessa is built for GDPR: it is hosted in the European Union, sold by a German company, offers a data processing agreement, supports data-subject export, and provides retention rules and legal holds. Compliance is a property of how your organisation processes data rather than of a product, so Enclessa provides the controls and the processing agreement, and the lawful basis remains yours.

Does Enclessa have ISO 27001 or SOC 2 certification?

No. Enclessa holds no compliance certifications today. What exists instead is published detail a reviewer can check: the architecture, the data model and the OpenAPI surface are documented, and the encryption is MLS per RFC 9420 through OpenMLS, an IETF standard and an audited open-source implementation. That is evidence, not a certificate, and it is not a substitute for one if your procurement requires it.

Can Enclessa employees read my messages?

Not in encrypted conversations — the server holds no key for them. For managed channels, the platform control plane our operators use cannot read content at all: it is a separate identity restricted to metadata, and a continuous-integration check forbids it from importing any code that could read content. There is no impersonation feature.

How does Enclessa keep one customer’s data away from another’s?

The organisation is asserted at a single choke point rather than at each call site, and a request for another organisation’s object returns not-found. A probe suite generated from the API document drives every operation across the boundary — 286 operations, all refused — and it runs in continuous integration so a regression fails the build.

Can I get my data out of Enclessa?

Yes. An organisation can export everything the platform holds for it, at any time and in open formats, the data model is documented, and the whole API is described by an OpenAPI document. The exit is a button rather than a support ticket or a negotiation.

How do I report a security vulnerability in Enclessa?

Report it privately to the security contact rather than in a public issue, and you will get an acknowledgement and a timeline. Enterprise customers receive security advisories ahead of public disclosure.

Encrypted collaboration, hosted in Europe.

Create a workspace in a couple of minutes. It is yours at your-team.enclessa.app, hosted in the European Union, with encrypted direct messages from the first one you send.

Open beta. Free plan, no payment card to start.