What we can and cannot see

This is a translation for your convenience. The Dutch version is binding.

Sendis encrypts the text of every message on your device before anything is sent. Attachments are encrypted on our server. What we can and cannot technically decrypt afterwards depends on the delivery method. This page sets that out per delivery method, including the data our server does process in each case.

Registered recipient

If you send to a registered recipient, Sendis can decrypt the text only through your organisation's recovery key or that of the recipient's organisation.

The text of your message is encrypted on your device with a one-time message key. That message key is then encrypted with the recipient's public keys, in a hybrid wrapping of X25519 and ML-KEM-768. The matching private keys are on the recipient's devices; on our server they exist only in encrypted form, locked with keys derived from the recipient's password or recovery code. If the recipient works within an organisation, a recovery copy is added; see "Recovery within your organisation" below.

Our server therefore stores the encrypted text and encrypted message keys. Apart from your organisation's recovery key, or that of the recipient's organisation, we hold no key that can open them. Please also read "Recovery within your organisation" below: it explains what this means for this delivery method.

Access code

If you send with an access code, Sendis can decrypt the text only through your organisation's recovery key.

The recipient opens the message in the portal with a code that you yourself share outside Sendis, for example in person or through another channel. The key that encrypts the message key is derived from that code in the browser (Argon2id). The code itself is not sent to our server.

To check the code, our server stores a verification value: a hash of a value derived from the code in the browser, not of the code itself. Only after a successful check does the server release the encrypted message key. Without the code we cannot open that key, except through your organisation's recovery key. Please also read "Recovery within your organisation" below.

This delivery method does not use a hybrid post-quantum construction to wrap the message key; the strength of this link depends on the access code.

Email or SMS verification

If the recipient verifies by email or SMS, decryption runs through our server. Sendis can technically decrypt the text of these messages.

The text of these messages is also encrypted on your device. But because the recipient has no account and no code shared in advance, our server stores the secret that can open the message key, in encrypted form. After a successful verification the server releases that secret to the recipient's browser, where decryption takes place. This applies to every delivery method in which the recipient verifies with a code that Sendis itself sends.

To be clear: whoever can decrypt that secret on our server can also derive the message key. That is the essential difference from the two delivery methods above. The numeric code the recipient receives by email or SMS is a temporary proof of access; that code alone is not enough to decrypt the content.

If you want the strongest protection for the text, choose a registered recipient or an access code. Read below what your organisation's recovery key means for that choice. The compose window shows the security level of your choice before you send.

Overview

What "recovery within your organisation" means is explained further down this page.

Metadata: what our server processes in every delivery method

Encryption covers the text of your message and your attachments. Attachments are checked for viruses on our server. The server processes them unencrypted only for that check and for encryption, then stores them in encrypted form. We can therefore technically decrypt attachments with every delivery method. To deliver messages, our server processes at least the following data in readable form, under every delivery method:

• the subject of the message;
• name, email address and phone number of sender and recipient;
• file names and file sizes of attachments;
• times: sent, delivered, opened, read, expires;
• the chosen delivery method and the conversation structure (which message replies to which);
• the size of the encrypted content.

Who communicates with whom, when, with what subject and with which attachment names is therefore visible to our systems. So do not put confidential information in the subject or in a file name. Which other data we process and how long we keep it is set out in our privacy statement.

Recovery within your organisation

Every message from an organisation also gets a recovery copy of the message key, encrypted to that organisation's recovery key. This lets the organisation open and read messages, for example when an employee loses their password or leaves. Sendis stores and manages that recovery key in encrypted form in its own key management system. Organisations cannot currently choose a different recovery method. If you send a message to a Sendis user in another organisation, that organisation can also open the message through its own recovery procedure.

• Sendis can therefore technically decrypt all messages and attachments of your organisation, including those sent to a registered recipient or with an access code.
• Within Sendis itself, your organisation can use the recovery key only with a stated reason, after notifying the employee concerned, after a waiting period of 72 hours by default and with approval from an administrator, plus a second administrator where your organisation has more than one. The waiting period can be skipped only where a legal obligation requires it, such as a court order. This is recorded.
• We do not use the recovery key on our own initiative: only on the written instruction of your organisation or when the law compels us to.

A personal account without an organisation has no recovery key.

Post-quantum encryption

The hybrid wrapping Sendis uses for registered recipients, for your own sent copy and for recovery copies combines a classical and a post-quantum algorithm. Both must succeed: the message key is released only when both the classical and the post-quantum parts succeed. The algorithm of this wrapping is fixed and is not negotiated between browser and server.

X25519 + ML-KEM-768 (NIST FIPS 203) and AES-256-GCM.

Which parties process data on our behalf is listed on the sub-processors page.