The honest, layered picture

Security you can actually verify

We won’t tell you “everything is end-to-end encrypted” and leave it there. Here is exactly what each part of Ollasync protects, how, and what we don’t claim yet — written to survive a buyer’s security review.

Encryption model

Protection, data type by data type

End-to-end encrypted

Messaging & shared files

Uses the open IETF MLS standard (RFC 9420) via an independently audited MLS library. Keys are generated and stay on participants’ devices; the server stores only ciphertext and cannot read the content. Server-blind.

Encrypted in transit

Live meeting video & audio

Sent over WebRTC with DTLS-SRTP to a media relay (SFU) you can self-host — so on-premise, the relay is inside your own network. A per-frame end-to-end encryption mode is available when a meeting is provisioned with a shared key; it is not the default for instant meetings.

Encrypted in transit + access-controlled

Deal-room documents

Uploaded over TLS and gated by role and NDA, with short-lived signed access links. At-rest encryption follows your storage configuration. Client-side end-to-end document encryption is on the roadmap — we don’t claim it today.

Access-controlled · your storage

Recordings

When enabled, recordings are written to object storage you control and restricted to authorised viewers. Self-host and recordings never leave your infrastructure.

Trust boundary

What the server can — and can’t — see

For end-to-end encrypted messaging the precise claim is “we can’t read your messages,” not “we know nothing.” Metadata still has to be routed. Here’s the honest split.

Can’t see

  • The content of your messages and shared files (end-to-end encrypted)
  • Your message keys — they never leave participants’ devices
  • On self-host: meeting media, recordings and documents at all

Necessarily sees

  • Routing metadata for messaging: room identifier, membership, message size, timing and ordering
  • Who is connected to a meeting, and when
  • On our hosted service: meeting media passes through the relay in encrypted transit
Identity & access

Who gets in, and to what

Strong identity

Self-hosted sign-in with email + password, magic-link, TOTP two-factor and passkeys (WebAuthn/FIDO2). OIDC single sign-on to your own IdP — Okta, Entra ID, Google Workspace and more.

Rooms default-closed

A guest needs an invite, and the host must approve the join request before anything flows. Room tokens are short-lived and scoped to a single room with a role.

Role & NDA gating

Deal roles govern who sees which folders. A deal can require NDA acceptance before any document can be downloaded — audited, and the admin is notified.

View-only (deterrence)

View-only documents render in-browser with a per-viewer watermark and no download. We call this what it is: deterrence against casual leakage, not DRM.

Radical transparency

What we do not claim yet

Stated plainly, because hiding it is worse. A serious buyer rewards a vendor who draws the line honestly — so here it is.

No SOC 2 / ISO 27001 / ANSSI / HDS certification yet

These are on our roadmap; SOC 2 Type 1 is the first target as we land regulated design partners. We would rather tell you than imply a badge we don’t hold.

Our integration is not independently audited yet

The MLS cryptography library we build on is independently audited. An independent audit of our own integration, deployment and the meeting end-to-end path is not yet done — it is our top security investment with committed design partners.

Meeting E2EE is not on by default

The instant-meeting flow relies on encrypted transit to a relay you can self-host. Making end-to-end encryption the default for meetings (group-key distribution) is on the hardening roadmap.

Documents are not client-side E2EE today

In the current web flow, deal-room documents are encrypted in transit and access-controlled, but not end-to-end encrypted in the browser. Client-side document encryption is a roadmap item.

Don’t take our word

How a reviewer can check the claims

Every guarantee above is backed by an automated proof that runs against the live system.

Server-blind, proven

An automated two-browser test runs real messages through the live delivery service and asserts the plaintext never appears in anything the server stores — while each peer decrypts the exact message.

Tenant isolation

An automated test asserts one organisation cannot read or even list another organisation’s data.

Nightly end-to-end suites

Identity, deal-room, cross-org access and the full in-call feature set run every night against the live stack, with results emailed on failure.

Contract conformance

Every API route is checked against its documented contract on every build.

Building a compliance programme on this? See our compliance posture and request the security whitepaper and DPA.

FAQ

Security questions

What encryption does Ollasync use for messaging?

The IETF MLS standard (RFC 9420) — a published, modern group-messaging protocol — via an independently audited open-source library. It provides forward secrecy and post-compromise security, and all key material stays on devices.

Is the meeting video end-to-end encrypted?

Meeting media is encrypted in transit (TLS 1.3 / DTLS-SRTP) to a media relay you can self-host. A per-frame end-to-end encryption mode exists and is used when a meeting is provisioned with a shared key, but it is not the default for instant meetings — we state this plainly rather than imply blanket E2EE.

Do you hold any of my keys?

For messaging, no — keys are generated on devices and never sent to us. For meeting media on our hosted service, transport keys are negotiated per WebRTC session; self-host and the relay handling them is entirely yours.

Are you certified (SOC 2, ISO 27001, HIPAA)?

Not yet, and we say so. We provide the technical controls a compliance programme needs and a DPA, and self-hosting keeps regulated data inside your own certified environment. SOC 2 Type 1 is our first certification target.

Can a court compel you to hand over message content?

For end-to-end encrypted messaging, we have no keys and store only ciphertext, so there is no readable content for us to produce. We can only ever describe routing metadata, not message contents.

Put it through your security review.

We wrote our security model to be defensible line by line. Request the whitepaper and DPA, or bring your questions to a call.

Request the whitepaper Compliance posture