Databeamer for security officers and CISOs

Overview for security officers, CISOs, auditors and others who assess Databeamer from the perspective of security, technology and compliance before their organisation starts using it. It explains the architecture model, what it means for the assessment and what the organisation itself has to check, set up and agree.

For the privacy side (personal data, retention periods, data subject rights, DPIA) see Databeamer for DPOs and privacy officers and the DPIA support. The privacy statement, the data processing agreement (DPA), the security policy and the terms of service are on the legal page. The cryptographic details per feature are in the collapsed Security details blocks throughout the documentation; see how to read them.

1. The architecture model in short #

Databeamer is a Dutch SaaS service by Full Join B.V. for secure communication, file exchange and collaboration, with zero-knowledge encryption and hosting within the EU. The service was built to exchange and jointly use confidential information, including when people from different organisations work together.

The main principles:

• Encryption on the user's side. Files, messages, answers and journal content are encrypted on the user's device and decrypted at the recipient's. The server stores and relays encrypted data only.
• Key custody with the user. The master key is generated on the device, never stored and split 2-of-3. Databeamer holds one share and cannot decrypt content on its own or recover keys for users.
• Hybrid post-quantum cryptography. Classical cryptography is combined with post-quantum cryptography (PQC) for key exchange and digital signatures. An attacker has to break both algorithms.
• Access confined per group. Every user is a group of one; shared groups use the same key model. Administrative rights at organisation level do not automatically give access to the content of every group.
• Verifiable events. Changes are recorded in an audit trail of events signed by the user's device, sealed into chained epochs.

What does this mean for the assessment? A compromise of the server side yields, in principle, encrypted data, not readable content. The centre of gravity of the risk therefore lies partly with the endpoints and with the management of keys, devices and groups. Those are topics your own organisation influences and therefore has to set up. That does not mean the server side can be left out of scope: see section 4 for the exception and section 6 for the metadata.

See Technology for the full cryptographic stack with the associated RFCs and NIST standards.

2. Cryptography and key management #

The technology page describes the cryptographic stack with the associated RFCs and NIST standards and tracks what is still open. This overview follows that page and adds what the choices mean for the assessment; it does not go beyond it.

Topic	What is it?	Notes
Symmetric encryption	ChaCha20-Poly1305 (RFC 8439, AEAD) for the content. Domain-separated AAD per context, so ciphertext from one context cannot be used in another.	Constant-time, so resistant to timing attacks. Block nonces are derived from the file key; the same content in two files therefore encrypts differently and cannot be matched across files.
Key exchange	Hybrid X25519 (RFC 7748) + ML-KEM-768 (NIST FIPS 203), combined through HKDF-SHA512, to encrypt keys for recipients.	Both algorithms are standardised; an attacker has to break both.
Digital signatures	Hybrid Ed25519 (RFC 8032) + ML-DSA-65 (NIST FIPS 204) on every group key set at creation and rotation and on every audit entry.	Verifying the signatures on group keys in the client on every load is still open work; until then they are stored, not enforced. The technology page tracks this under "Open work".
Hashing and content addressing	BLAKE3 over every encrypted block as its address (deduplication of identical ciphertext); SHA-256 of the plain content, reported by the client for the malware check.
Key derivation	HKDF-SHA512 (RFC 5869) with domain-separated info strings for working keys; Argon2id (RFC 9106, 64 MiB memory, 3 iterations) for the PIN and for guests' passphrases.
Key generation	On the user's device when the account is created; randomness from the OS CSPRNG (in the browser the Web Crypto API).	See Create your account.
Key custody and recovery	Pedersen verifiable secret sharing (Ristretto255), threshold 2 of 3. The device share is unlocked with the PIN or a passkey that never leaves the device; the server share is released after sign-in; the recovery share can only be opened with the 24-word recovery phrase. One share says nothing about the key and every share is verifiable.	The master key is never stored: it is rebuilt temporarily to derive the working keys and then wiped from memory. See Recovery phrase and shares and Devices and unlocking.
Group keys	Per group a versioned key set, signed by the administrator's device at creation and at every rotation. Removing a member produces a new version.	See Groups.
Linking a new device	SPAKE2 (RFC 9382) over a short one-time code, with hybrid ECIES for the transcript: the new device receives its share from a device you already have; the server only relays ciphertext.	See Set up a second device.
Implementation	Server, cryptography libraries and browser build (WebAssembly) are written in Rust; the same code runs on both sides. unsafe is disabled at compiler level in our own code. No home-grown algorithms; only standardised, widely reviewed primitives. The architecture is crypto-agile: primitives sit behind strict interfaces, so algorithms can be replaced.	Changes to cryptographic code require double approval by the lead engineer and the CISO (see section 8).
External review of the cryptography	There is no separate, published independent review of the cryptographic design. The primitives used are standardised; the source code is not public.	Penetration tests see section 8; options for inspection can be discussed via compliance@databeamer.io.

The key model #

For the assessment the model suffices. A user's working keys are derived from their master key. Every group, including the personal group of one, has its own key set; content is encrypted under keys that only members of that group can open, and the server stores encrypted copies only. Guests never receive a group key, only access to what has been shared with them (section 4). How this works out per feature we discuss on request via compliance@databeamer.io.

3. Identity, access and roles #

Databeamer separates authentication from access to encrypted content. Signing in proves who the user is, but by itself yields no keys. A compromised identity provider therefore yields no readable data on its own.

Component	Description
Authentication	Sign-in goes through Databeamer's identity service (hosted by Full Join itself on its own infrastructure; no external identity provider). Multi-factor authentication is mandatory for every account: after the password an authenticator app (TOTP) or a device-bound confirmation. The secret of the second factor sits with the identity service, not in the app. With SSO the authentication policy of your own identity provider applies.
Unlocking keys	After signing in, a PIN or passkey is needed on every device separately to open the device share; only then is the master key rebuilt in memory. A locked PIN produces a security notification.
Single sign-on	OpenID Connect or SAML 2.0, set up by the organisation owner (depending on the subscription), with the option to disable password sign-in. The identity service keeps the secrets of the connection. A new SSO user stays pending until an administrator's device makes the organisation keys available to their account. SSO changes how people sign in, not how data is protected; recovery still works through the recovery phrase.
Authorisation	Policy-driven per object, enforced by a central policy decision point on every request. Group membership and cryptographic keys determine access to content; someone without a key cannot read anything even with a favourable policy decision.
Roles	Organisation level: owner, admin and member. Group level: owner, admin, member and reader. Administration of the organisation (accounts, groups, roles, seats) is separate from access to the content of groups; an organisation administrator sees which groups exist, their name, members and readable attributes, and without membership holds no key.
Guests	External people without an account gain access through a passphrase or an email code (section 4). Submitters on a request can only write and cannot open their own submission after sending.
Devices and sessions	Every device has its own share and is approved from an existing device (six-digit code, expires after a few minutes). A device can be revoked from another device; the remaining devices then get new shares and the revoked share is unusable. Device approvals and revocations are signed audit entries and produce security notifications. Sign-in sessions are managed by the identity service.
Identity verification	Full Join can give organisations and, at their administrator's request, users a verification mark after checking the profile data, through a restricted administrative channel with mandatory justification and audit recording. The mark grants no rights and lapses automatically when a verified attribute changes.

See Organisations, Devices and unlocking and Contacts.

What does this ask of the organisation?

• Joiners and leavers: determine how accounts and group memberships are managed when someone starts, changes role or leaves. With SSO the organisation manages the lifecycle in its own identity provider.
• Group membership: check periodically that people only have access to the groups they need.
• Administrative rights: distinguish between administration of the organisation and access to the content of individual groups. Decide who approves new SSO users.
• Connection to the identity provider: determine how SSO is set up and which additional measures (MFA, conditional access) are enforced at your own IdP.

4. Exceptions and points to consider #

These are the points where Databeamer trades some zero-knowledge for usability. Each is documented with the feature, and each is a choice your organisation can set policy on.

Guest access by email code #

For transfers and Secure Mail to recipients without an account, the sender chooses the unlock mode per delivery. The default is a passphrase: generated by Databeamer, one per transfer, shared outside Databeamer; the guest's key is derived from it with Argon2id and the server never learns the phrase (only the salt). The alternative is an email code: the guest's key is kept encrypted under a non-exportable key in a key management service (Scaleway Key Manager, EU, Amsterdam region), so an operator cannot copy it and use it offline. After the guest proves control of the mailbox with a six-digit code (single-use, valid ten minutes, limited in issuance and attempts), the key is released for that session. Every release is written to the audit trail. Recall or expiry destroys the escrow copy.

For the assessment: this is the only route on which the service can technically gain access to content, and the security of the guest's mailbox then becomes part of the chain. The path requires access to the production environment and to the key management service; that access falls under the access management in section 7 (least privilege, mandatory MFA, quarterly review, logging). The DPA (§4.3) and the Security Policy (§4.5) describe this trade-off explicitly.

What does this ask of the organisation? Determine which access route fits which type of information and record when guest access by email is allowed and when a passphrase or another way of working is required. See Send a transfer and Open a transfer you received.

Check for known malware #

On upload, the browser computes a SHA-256 hash of the content before encrypting and reports it with the upload. A background process looks the hash up at a hash reputation service (OPSWAT MetaDefender); the call contains only the hash. On a hit the file gets the status Threat found and cannot be stored in a Drive; downloads are never blocked and the outcome is advisory. A failed lookup is retried with increasing intervals.

For the assessment: a hash can reveal that two users have the same file, or that a file is a known public file; about a unique file the hash says nothing. Because the server does not see the content, it cannot perform a content-level scan. An organisation that requires one arranges endpoint scanning on its own side. See Upload and organise files.

Revoking access and key rotation #

When someone is removed from a group, the administrator's device generates and signs a new version of the key set; the server never generates keys. New information is then no longer accessible to the removed person. Information already downloaded or decrypted cannot be removed from their possession remotely, and earlier chat messages and journal entries are not re-encrypted. This is a property of every encrypted exchange model, not a shortcoming of the implementation, but it does call for organisational agreements. See Groups.

Loss of devices and recovery data #

A user can have a device revoked from another available device. The recovery phrase is important to keep access. If all devices and the recovery phrase are lost, the account cannot be recovered in the usual way. If Databeamer then resets the account, the user's shares and public keys are removed; the old master key can no longer be rebuilt by anyone and personal content is permanently gone. Group content becomes reachable again once an administrator adds the user back. The reset is recorded as a security event in the audit log.

What does this ask of the organisation? Determine how employees keep the recovery phrase safely, how loss is reported, who is involved in a reset and how you prevent business-critical information from existing in one account only. See I have no device and no recovery phrase.

5. Audit trail, logging and incidents #

The audit trail records events and changes. Every mutating action by a user carries an audit entry that the user's device signs with the hybrid signature (Ed25519 + ML-DSA-65) and that is stored together with the action. Guests' actions and actions the server performs itself (such as a download by a guest or an expired transfer) carry no signature from a user's device. Every hour entries are sealed into chained epochs. See Audit log.

Topic	Description
What is recorded	Who did what with which object and when: uploads and deletions, transfers sent, accepted, downloaded and expired, guest access (with a passphrase as a confirmation from the guest's browser, with an email code on every key release), submissions and withdrawals, member and role changes, key rotations, device approvals and revocations, recovery phrases, account resets, changes in organisations. Entries never contain content, file names or messages.
Scope	Per account, per group and for the system as a whole. Filters in the app: transfers, requests and mail; files; chat; account and security; groups and organisations.
Integrity	Signed by the acting device (Ed25519 + ML-DSA-65), sealed into chained epochs that are continuously re-verified. Deleting or changing an entry afterwards would break the chain.
Viewing and export for the customer	Users see the audit trail of their own account. Organisations can view and export the audit data of their own organisation and groups (DPA §13.6). Integration with your own monitoring or a SIEM is set up in consultation, depending on configuration and agreements.
Retention	Audit data remains after the underlying content or account has been deleted, anonymised where possible, as long as needed for security, administration, incident investigation, accountability and legal or contractual obligations (DPA §13.6). Operational infrastructure logs and error monitoring are kept for a limited period (in the order of one month) and contain no customer content, personal data or keys.
Notifications of suspicious activity	Events that deserve attention, such as a new device approval or a locked PIN, appear as Security notifications on the user's dashboard and, depending on the notification settings, by email.

The audit trail does not replace all organisational measures. Agree who reviews events, when further investigation is needed and how findings are recorded.

Examples of situations and first actions #

Situation	First points of attention
A device is lost or stolen	Revoke the device from another available device. Assess whether the recovery phrase may have been exposed and regenerate it if so. Guide
An employee leaves the organisation	Remove the person from the relevant groups (the key rotates on removal) and transfer group or organisation ownership first. Guide
A transfer or Secure Mail went to the wrong person	Delete the transfer or recall the delivery to the guest. Information already collected cannot be taken back remotely. Reference
A passphrase may have become known to unauthorised people	Delete the transfer and resend with a new phrase.
There is suspicious activity on an account	Review the audit data and security notifications; signed entries cannot be forged by the server. Follow the internal incident procedure and report a suspicion to Databeamer at security@databeamer.io.

In case of a possible data breach, also assess whether notification duties apply, and involve the DPO in time.

Incident handling by Databeamer #

Topic	Description
Reporting channel for the customer	Security incidents and vulnerabilities: security@databeamer.io, with PGP for sensitive reports. Other questions: compliance@databeamer.io. A valid report is acknowledged within five working days.
Detection and classification	Automated alerts on infrastructure and deployment pipeline, own observation and external reports. Classification on report: P1 critical (active attack, suspected data breach, outage of all production clusters, suspected compromise of keys) first response within 1 hour; P2 high (unauthorised access without exfiltration, loss or theft of a device) 4 hours; P3 normal (vulnerability in production, not exploited) 8 hours on a working day; P4 low next working day.
Notification to the customer: deadline and content	Without undue delay and within 24 hours of discovery at the latest, to the security contact designated by the customer, by email and by phone if needed, so that the customer can itself notify within 72 hours (GDPR, NIS2, Dutch Cybersecurity Act). Content: nature, systems affected, categories of data and data subjects, consequences, measures, contact point; supplemented as more becomes known (DPA §9.2 and §9.3).
Contact point and availability	The customer designates a security contact and keeps it up to date. In a major disruption a first public notice follows within thirty minutes, then an update at least every hour, and after recovery a confirmation by email.
Evaluation and follow-up	After a P1 or P2 incident an evaluation of cause, detection, recovery and preventive measures, and an assessment of whether the ISMS needs adjusting; the outcomes relevant to the customer are shared on request. The incident process is tested at least once a year.

6. Which data is visible to the service? #

The zero-knowledge architecture protects the content. A limited amount of metadata remains readable, because the service needs it for accounts, groups, access and exchange.

For a CISO the key point is that this is the data an attacker on the server side or a malicious administrator could see: names and email addresses, organisation and group names, member lists and roles, classifications, statuses and labels, titles, senders, recipients and status of transfers and requests, events and timestamps in the audit trail, counts, encrypted sizes and the shape of the folder tree, channel, sender, read status and presence in chat and mail, guests' email addresses, IP addresses and sign-in times, and the SHA-256 hash of every uploaded file. Not visible are file content, file names and types, folder names, messages, attachments, journal entries, answers, tags and descriptions, and passwords, PINs, recovery phrases, passphrases and keys. The technology page keeps this list current.

The privacy consequences are described in the overview for DPOs. For the security assessment the following is relevant:

• Who within Databeamer can access this metadata? Only staff with a role in administering the production environment, under least privilege and need-to-know, with mandatory MFA (authenticator app or hardware key), a quarterly review of all access rights and logging of administrative actions. Access is deactivated on the last working day on departure. There is no separate support access.
• How is the metadata protected in transit and at rest? TLS for all traffic, encryption at rest on the infrastructure, network segmentation and access restriction. This protection is of industry-standard level, not zero-knowledge: it is the exposure in a server break-in.
• Keep group names, titles, labels and statuses neutral, so that the metadata itself reveals no confidential information.

7. Hosting, infrastructure and continuity #

Topic	Description
Hosting location and provider	Scaleway SAS (France), European Union, Amsterdam region, redundant across three zones. The identity service runs on software managed by Full Join itself on the same infrastructure. No data, metadata or backups leave the EU; no US hyperscaler. The sub-processors are listed in chapter 10 of the DPA.
Architecture of the service	Separate environments for development, build, staging and production, technically and organisationally; the production environment is not reachable over the network from development workstations. Production data is never used in development or test environments; test data is synthetic or anonymised. The entire infrastructure is defined as code and deployed from it.
Network and transport security	TLS for all traffic, network segmentation, firewalls, secured administrative connections, protection of public endpoints, rate limiting, measures against automated abuse and DDoS, monitoring of network activity.
Administration and access to production	Limited to the people for whom it is necessary; personal accounts with mandatory MFA; for every critical platform at least two administrators, so continuity does not depend on one person while personal traceability is preserved. Manual changes in production outside the deployment pipeline are not allowed and in emergencies require the four-eyes principle. Access rights are reviewed every quarter; granting and revocation are recorded as tasks.
Backup and recovery	Automated backups of everything needed to restore the service; customer content in them is always encrypted. Database backups daily, kept for seven days; encrypted file blocks redundant across three zones in Amsterdam. Recovery runs exclusively through the infrastructure-as-code pipeline, after the root cause has been established and with a verification test by two people. Recovery procedures are tested at least once a year, including a database and identity restore on a separate environment.
Recovery objectives (RTO and RPO)	Set internally for the production platform and the identity infrastructure and laid down in the continuity plan. They are not part of the public policy; for customers with an SLA they are agreed contractually (Security Policy §11.3).
Cryptographic condition on recovery	Full Join can restore encrypted customer data and metadata from backups, but users only open their data again with their own device or recovery phrase. There is no master key to force this centrally.
Availability and monitoring	Redundant set-up where possible; uptime monitoring, log alerts and error monitoring with defined thresholds; monthly security and monitoring review. Planned maintenance on working days between 22:00 and 06:00 (Dutch time), announced at least five working days in advance in the app and by email to administrators when it causes unavailability. In a major disruption a first public notice within thirty minutes and then an update every hour.
Subcontractors and sub-processors	See chapter 10 of the DPA and section 6 of the DPIA support. Critical suppliers must hold a current ISO 27001 certificate or SOC 2 report and a DPA with EU data residency and are reviewed at least once a year; on selection they are tested on ownership within the EU and the origin of the underlying technology.

8. Development process, supply chain and vulnerability management #

Topic	Description
Secure development	Secure SDLC in six phases, from ticket to maintenance. Every change starts as a ticket; significant changes to the zero-knowledge or post-quantum architecture require management approval and a risk review by the CISO. unsafe is blocked at compiler level in our own Rust code; strict compiler flags and linters reject unfinished code. Secrets are never in the repository. All code going to staging or production passes a formal review; self-merging is blocked by branch protection. Changes to cryptographic and zero-knowledge code require, through CODEOWNERS, double approval by the lead engineer and the CISO.
Testing	Every release passes the automated test suite: unit and integration tests (against local database, cache and authorisation containers), policy tests for the authorisation rules (a change that breaks existing rules is blocked), static analysis (Semgrep, Clippy, cargo-geiger) and dependency scanning. Critical or high findings block the deployment.
Dependencies and supply chain	Continuous management of open-source dependencies with cargo-deny and Renovate; CVE reports automatically produce a change proposal, critical CVEs are registered as risks. New releases of cryptographic libraries are only adopted after a maturation period, as protection against supply-chain attacks through quickly rolled-out malicious updates. An SBOM is not published; the dependency list is part of the source code and can be discussed on request.
Change and release management	The CI/CD pipeline is the only route to production; manual deployment is prohibited. Every deployment is logged. On a problematic deployment the lead engineer decides on the rollback to the previous stable release; the disruption is registered as an incident. Production servers run minimal (no debug or analysis tools without an approved, temporary change). Maintenance causing unavailability is announced five working days in advance.
Patch management	Vulnerabilities are proactively identified and resolved as quickly as possible; priority follows severity. An identified, unexploited vulnerability in production is a P3 incident (first response within 8 hours on a working day); an actively exploited vulnerability is P1 (within 1 hour).
Penetration tests and independent review	Periodic external penetration tests by an independent, certified party, with a pre-agreed scope (rules of engagement); findings are followed up as tasks. Tests customers commission themselves are facilitated after agreeing the scope. In addition, an annual independent internal audit of the ISMS by an external firm. Summaries and assurance information are shared on reasonable request (DPA chapter 14).
Vulnerability policy and responsible disclosure	Reports via security@databeamer.io (PGP available); acknowledgement within five working days; no criminal complaint or civil action against researchers who follow the rules (Security Policy chapter 16).
Reviewability of the code	The source code is not public. The same Rust code runs on the server and in the browser (WebAssembly), so there is one source of truth for the cryptography. Options for inspection can be discussed via compliance@databeamer.io.

9. Certifications, standards and compliance #

Topic	Status
ISO/IEC 27001:2022	The ISMS is set up in line with ISO/IEC 27001:2022 and Annex A, with the Databeamer production environment, the underlying infrastructure and the supporting systems in scope. The external certification process has been completed; formal completion awaits the certification body's report. The Security Policy (§17.1) gives the current status and is updated on award.
NEN 7510, 7512 and 7513	Full Join is preparing for certification against NEN 7510 and sets up the service with regard to NEN 7512 (trust basis for data exchange) and NEN 7513 (logging of access to client data); the audit functionality is partly aligned with the latter standard.
NTA 7516	Substantive conformity on most pillars; the development of NEN 7516, NTA 7531 and NTA 7532 is followed. See the compliance page.
BIO (Dutch government baseline), NIS2, DORA	Databeamer supports customers' obligations on access control, incident logging, notification deadlines and supply-chain security; the mapping per standard is on the compliance page. Full Join itself does not fall under the NIS2 notification duties, but aligns its 24-hour notification deadline with customers who do.
Other standards or reports (such as SOC 2)	Not available.
Statements on the technical and organisational measures	Annex B of the DPA and the compliance page; additional documentation, certifications and assurance information on reasonable request (DPA chapter 14).
Data processing agreement, privacy statement, cookie policy	See the legal page.

10. What to check, set up and agree #

Topic	What do you check or arrange?	Agree with
Risk analysis	Does Databeamer's security level fit the sensitivity of the information to be shared?	Process owner, DPO
Guest access	Which guest access options are allowed for which type of information? Is the email code acceptable for the most sensitive information?	DPO, programme manager
Identity and SSO	How is SSO connected to your own IdP? Which additional requirements (MFA, conditional access) apply? Who approves new SSO users?	IT manager
Groups and rights	How are groups set up and periodically checked? Which roles does who get?	Organisation administrator, IT manager
Joiners, movers and leavers	How do account management and the removal of group members on departure work, taking key rotation into account?	HR, IT manager
Endpoints	Which requirements apply to devices Databeamer is used on (updates, disk encryption, malware protection)? Is a passkey required, allowed or discouraged?	IT manager
Recovery policy	How are recovery phrases kept, loss reported and resets handled? At least two devices per user?	IT manager, DPO
Logging and monitoring	Who reviews audit data, how often and how is this recorded? Is integration with your own monitoring needed?	IT manager
Incident handling	Is it clear who does what in an incident and how the supplier is engaged? Is the security contact at Databeamer up to date? Do the notification deadlines fit your own obligations?	DPO, management
Supplier management	How are certifications, penetration test reports and changes at Databeamer periodically assessed?	Procurement
Continuity and exit	Is the service sufficiently available? Is an SLA needed for RTO and RPO? How does the organisation get to its data if the service fails or the agreement ends (export function, thirty days after termination)?	IT manager, programme manager

11. Where to find the technical details #

Topic	Documentation
Outline of the technology	Technology
Account, key generation and recovery	Create your account and Recovery phrase and shares
Devices, PIN, passkeys and revocation	Devices and unlocking and Passkey unlock
File encryption and malware check	Upload and organise files and Trash and deleting
Group keys and group membership	Groups
Transfers and guest access	Send a transfer, Track and receive transfers and Open a transfer you received
Secure Mail	Secure Mail
Requests and submissions	Create a request, Manage submissions to requests and Answer a request
Chat and contacts	Chat and direct messages and Contacts
Journals	Journals
Audit trail	Audit log
Organisation, roles and SSO	Organisations
Rolling out to users	Roll Databeamer out to your users
Privacy and DPIA	Databeamer for DPOs and privacy officers and DPIA support
IT and application management	Databeamer for IT and application management
Hosting, processors, certifications	Compliance
Privacy statement, DPA, security policy, terms of service	Legal page

About this document #

The owner is the CISO of Full Join B.V. The document is reviewed at least once a year, and additionally on every change of the security policy, the DPA, the certification status or the technical architecture. The date of the last change is at the bottom of the page.

Questions about security or compliance? Contact us through the compliance page or email compliance@databeamer.io. Report vulnerabilities via security@databeamer.io.