For security and privacy officers Reference
Databeamer for security and privacy officers
The protection model in one page, what the server can and cannot see, the deliberate exceptions, and where every cryptographic detail in these docs lives.
This page is for the people who have to judge Databeamer before their organisation adopts it: security officers, data protection officers, auditors and IT. It summarises the model, states its limits plainly, and maps where the detail sits. The detail itself is in the collapsed Security details blocks throughout the documentation; see how to read them.
The model in short #
- End-to-end encryption. Files, messages, answers and journal entries are encrypted on the user's device and decrypted on the recipient's. Databeamer's servers store and relay ciphertext.
- Keys exist only on devices. A user's master key is generated in the browser, never stored and never sent. It is split 2-of-3 into a device share (PIN-protected), a server share and a recovery phrase; any two rebuild it. Databeamer holds one share and cannot recover or reset a user's keys for them.
- Post-quantum hybrids. Key exchange is X25519 + ML-KEM-768, signatures are Ed25519 + ML-DSA-65, content encryption is ChaCha20-Poly1305. An attacker has to break the classical and the post-quantum algorithm.
- Every user is a group of one. Personal storage and shared groups use the same key model: a versioned group key set, wrapped per member with ECIES. Sharing is adding a member; revocation is removing one and rotating the key.
- Signed audit trail. Every mutating action carries an audit entry signed by the user's device, stored in the same transaction and sealed hourly into hash-chained epochs.
Security detailsWhat is this?
The key hierarchy, algorithms and derivation steps are described under Create your account, Recovery phrase and shares and Groups. The public technology page gives the architecture overview outside the documentation.
What the server can see #
Zero-knowledge covers content. Metadata is plaintext on the server, and your assessment should treat it as such:
| Visible to the server | Not visible |
|---|---|
| Account identities, email addresses, organisation and group names, member lists, roles | File contents, file names, folder names |
| Who did what to which object and when (audit log, activity) | Message text, tags, replies, journal entries |
| Encrypted sizes, block counts, timestamps | Request answers, uploaded documents, private notes |
| Document types, statuses and labels, group types | Passphrases, PINs, private keys, group keys |
| Chat channel, sender, key version, read and typing state | Attachment names and types |
| Guest email addresses and access events |
Two consequences for policy: labels and group names must never carry personal data or case details, and traffic analysis (who exchanges with whom, how often, how much) is possible for whoever controls the server.
Deliberate exceptions #
These are the points where Databeamer trades some zero-knowledge for usability. Each is documented at the feature, and each is a choice your organisation can govern.
- Guest unlock by emailed code. When a sender chooses "code by email" instead of a passphrase, the envelope key is held in escrow by a managed key-management service and released after the guest proves control of the mailbox. For that transfer, Databeamer can open the files during a verified access, and the release is logged. The passphrase mode has no such escrow. See Send a transfer. Decide which mode your organisation allows for which data.
- Threat scan by hash. The client reports a SHA-256 hash of each uploaded file's plaintext so it can be checked against known-malware lists. The server learns when two users hold the same file, not what it is. The result is advisory. See Upload and organise files.
- Key rotation protects what comes next. Removing a group member leaves what they already decrypted in their hands; the rotation that starts automatically on removal protects everything added afterwards. See Groups.
- An account reset by Databeamer destroys a user's keys and personal data when both the devices and the recovery phrase are lost. See Roll Databeamer out to your users.
Identity and access #
Authentication runs through Databeamer's identity service (Zitadel), with optional single sign-on over OpenID Connect or SAML 2.0. Identity and keys are separate: signing in grants no keys, and a compromised identity provider alone yields no plaintext. A new SSO user receives the organisation's keys only when an administrator's device wraps them. Authorisation is policy-based per resource; roles are owner, admin, member and reader at group level, and owner, admin and member at organisation level. See Organisations.
Device and recovery policy #
Each device holds its own PIN-protected share and can be revoked from another device. Passkeys (WebAuthn PRF) can replace the PIN per device. Losing every device makes the recovery phrase the only way back; losing that too means the account cannot be recovered. Your organisation should therefore have a written rule on where staff keep their phrase, and a decision on when to request a reset. See Devices and unlocking and Recovery phrase and shares.
Incident playbook pointers #
| If | Then |
|---|---|
| A device is lost or stolen | Revoke it from another device; regenerate the recovery phrase if it was stored there. Guide |
| Someone leaves the organisation | Remove them from every group; the key rotates on removal. Transfer ownership first. Guide |
| A transfer or mail went to the wrong person | Delete the transfer or recall the guest's delivery; content already fetched cannot be recalled. Reference |
| A passphrase was exposed | Delete the transfer and send again with a new one. |
| Something looks off in an account | Read the audit log and security alerts; signed entries cannot be forged by the server. Reference |
Where the detail lives #
| Topic | Pages with Security details |
|---|---|
| Key generation, secret sharing, recovery | Create your account, Recovery phrase and shares |
| PIN, passkeys, device approval, revocation | Devices and unlocking |
| File encryption, integrity, threat scan | Upload and organise files, Trash and deleting |
| Journals | Journals |
| Group keys, membership, rotation | Groups |
| Transfers to accounts and guests, expiry | Send a transfer, Track and receive transfers, Open a transfer |
| Secure Mail | Secure Mail |
| Requests and submissions | Create a request, Manage submissions, Answer a request |
| Chat | Chat and direct messages |
| Contacts and identity | Contacts |
| Audit log | Audit log |
| SSO, organisation metadata | Organisations |
For hosting, processors, certifications and the standards Databeamer is assessed against, see the compliance page. Next: Assess Databeamer before adoption.