Security

2. The two delivery methods: the difference is important

We recommend "Simple" as it is sufficient for most use cases and is actually used by many. Anyone subject to a duty of confidentiality should instead select Secure. In this mode, reading the message is technically impossible.

3. Recipient secure inboxes

A secure inbox is a permanent link that you set up once and then share, for example on your website, in your email signature or in an appointment confirmation. Anyone who opens the link can send you encrypted messages and files without needing an account or software. For law firms, tax advisers and medical practices, this provides a continuous, secure channel for incoming documents: clients, patients or applicants can submit documents without sending them unencrypted by email. Secure inboxes are part of Pro plans (and included in Business); they are not available in the free plan.

When setting up, you choose from five levels: One-time code by email, only the Account passkey, code plus Passkey, code plus second factor, or a your own passphrase with true end-to-end encryption. The Passkey variants use the same Passkey as for login. Those who have not set up a Passkey or whose device does not support WebAuthn may use the code, an authenticator, or a custom passphrase.

With Business you can also activate searchable templates for submission - for example for Instagram, WordPress, FTP/SFTP, SSH, email, hosting, database or API access. The template only shows the person submitting the information that is normally necessary for the chosen access. These values ​​are not transmitted as individual metadata, but are combined into a message block in the browser and encrypted together. Revocable personal forms can also be created for individual customers with a pre-filled name, email address, introduction and a fixed template. The default is encrypted in the account database; the URL itself just contains a random identifier.

The following Security assessment compares these five levels on a scale from 0 to 100. It shows how many independent elements someone would need to gain access. This is SchlüsselBot’s own assessment; it has not been independently audited and is not a security certification.

The passkey confirms your identity using WebAuthn/FIDO2; biometric data never leaves the device. It is not an encryption key. Only for E2E passphrase does the browser generate its own key pair: the private key is stored exclusively encrypted with the passphrase, and without the passphrase, no one can recover open submissions.

New submissions open directly from your logged-in Inbox; you don't need to search for the previous notification email. For the four stages without E2E passphrase, the URL fragment is stored AES-256-GCM encrypted on the edge server, separate from the ciphertext and only available until retrieval, expiry, or hiding. The associated root-protected server key is stored outside the database and is not included in application security. Code, passkey, or second factor cannot be bypassed via the direct button. Only the E2E passphrase fully prevents us from accessing the content.

3a. The exception: plaintext via the programming interface

All the above applies to the website. Through our API, a developer has an additional choice: they can encrypt the data themselves and send us only the ciphertext (field ciphertext). Or they hand us the Plain text (field message); in that case, we encrypt it for them, and the content reaches us in readable form.

We overwrite it in memory immediately afterwards and never write it to disk. However, the server blindness described above does not apply to this operation. We state this here even though it is inconvenient. Anyone who requires server blindness must encrypt the content themselves. The API supports both options.

And even when self-encrypting, there is a condition that we state explicitly here: anyone who sends the ciphertext together with the fragment field hands us their Key. We need the fragment to build the complete retrieval link and send it by email. We do not store or log the key, but it reaches our server for this delivery, just as it does with the “Simple” method on the website. Full server blindness via the API therefore means sending ciphertext without fragment and delivering the link yourself.

This never happens via the website: there is no way to hand us plaintext.

4. Structure

• Two separate servers. An edge server receives and delivers. A vault server holds the ciphertext and is not accessible from the internet.
• Connection only via WireGuard , additionally with mutual certificate authentication (mTLS). The vault will not accept any data without a valid client certificate.
• Location: Germany Edge servers operated by netcup GmbH, Karlsruhe (with data processing agreement under Art. 28 GDPR). The vault server is also located in Germany.
• Procedure: AES-256-GCM for content and WebAuthn/FIDO2 for passkey verification by the secure inbox owner.
• Sign in via passkey (WebAuthn) or password plus second factor. Security-critical changes require fresh confirmation.

5. What SchlüsselBot can see

Not the content. But yes: Recipient email address, timestamps, file size, and retrieval status. These metadata are encrypted with us, but we could decrypt them. We need the address to send the notification. For a law firm, the recipient list alone might reveal a client relationship. This should be stated.

6. What SchlüsselBot cannot do

• Nothing to restore. If the link, key, or one-time code is lost, the content is permanently gone — even for us. Simply resend in that case.
• No delivery guarantee. Whether a notification email arrives depends on the recipient’s inbox and their spam filter.
• No availability guarantee. We strive for continuous operation, but do not guarantee it (§ 13 of the Terms). An archive is not SchlüsselBot.
• No certification to show. There is currently no external security audit, no ISO-27001 certification, and no published penetration test. If you need such proof for approval, you won’t find it here. We’d rather state this clearly than obscure it.

7. For holders of professional secrecy

Professionals bound by professional secrecy include lawyers, Notaries, tax advisers, doctors and psychotherapists. Two questions must be considered separately: if SchlüsselBot processes personal data on their behalf, a data processing agreement under Article 28 GDPR is generally required. If another person's confidential information becomes accessible to another participating person, Section 203(4) of the German Criminal Code also requires them to ensure that person's duty of confidentiality. Business provides the appropriate documents for both cases; the DPA is generated in the account and the confidentiality undertaking is then concluded alongside it.

What's the difference, in simple terms? The AVV governs the relationship between you and SchlüsselBot as a company and covers the processing of personal data on our behalf. The declaration of obligation under § 203 para. 4 StGB protects a professional secret and obliges those actually involved to maintain confidentiality. Whether both regulations apply in a given case depends on your role and specific use. An AVV does not replace a required confidentiality obligation; therefore, Business includes both documents. The legal classification of your own use remains with the using company.

For technically enforced server blindness during direct delivery, choose the Secure sending method and transmit the retrieval link via a separate channel.

8. What you can do

• For sensitive content, select Secure instead of "Simple".
• Send the link and one-time code via two different methods: share the link yourself (in the meeting, by phone, or via messenger), and we will email the one-time code. This is exactly the Secure sending method.
• Tell the recipient in advance that the link can be opened only once and that they must save files immediately. Files are loaded directly into the page when opened and disappear as soon as the recipient closes or reloads it. We delete them from our server no later than 10 minutes after opening. The recipient should open the link on the device where the files are to be saved.
• Enable a second factor or a passkey in your account.

9. Protection against fraud

A genuine SchlüsselBot link always begins with https://schluesselbot.de/. If the address is different, the link is not from SchlüsselBot.

We will never ask for your password, bank details or one-time code by phone or email. Anyone who does is trying to deceive you. Simply opening the link does not use it up: the message is displayed and then deleted only after you enter the one-time code. You can therefore inspect the link at your leisure.

Found a gap?

We appreciate your report and will respond. You may use our own systems for review, as long as you no reading, modifying or deleting of third-party data and do not disrupt operations. We will not take legal action against individuals who comply with these rules and give us time to fix the issue before any public disclosure.

The machine-readable reporting channel is available at /.well-known/security.txt (RFC 9116). We prefer that you use the service itself: submit your report via the Homepage, choose the Secure delivery method and send us the link. Your report will then reach us encrypted.

We are particularly interested in anything that could allow ourselves to read content that should remain inaccessible, retrieve a message without its one-time code or link, or use our delivery system to contact third-party addresses.

Contact us by email at abuse (at) schluesselbot dot de. We will reply, and we thank you.