Encrypted in the browser before the content leaves your device.
Only the ciphertext resides on our servers. In the Secure sending mode, the key is located behind the hash symbol in the address — and this part is technically never sent to a server. In “Simple”, the key passes through the edge server once, but is neither stored nor logged there.
This page also shows what SchlüsselBot not do. There is no security promise without clearly defined boundaries.
2. The two delivery methods — the difference is important
| Simply (default) | Secure | |
|---|---|---|
| Who sends the link? | We, by email | You, via messenger, phone, or in person |
| Where is encryption performed? | in your browser | in your browser |
| Do we see the key? | It runs once through our server. We do not store or log it — but technically excluded is not reading it on this path. | No, never technically. The key only leaves your browser into your clipboard. |
| Who is it for? | Everyday life, when convenience matters | Client, patient, and personnel data; wherever confidentiality must be technically guaranteed |
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 you set up once and then share — on your website, in your email signature, or in a meeting confirmation. Anyone who opens the link can send you encrypted messages and files, without needing an account or software themselves. For law firms, tax advisors, and medical practices, this is a continuous, secure way to receive documents: clients, patients, or job applicants can submit paperwork without any of it being sent 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.
The following Security assessment compares these five levels against each other on a scale from 0 to 100. It shows how many independently required elements someone would need to gain access. This is SchlüsselBot’s own assessment, not externally audited — not an absolute security certification.
| Level | Required to open | What an attacker would need | Settlement |
|---|---|---|---|
| Code via email | One-time code to your address | Access to your email inbox | 60/100 |
| Only Passkey | Your passkey (Face ID, fingerprint, or device PIN) | Your unlocked device — a passkey cannot be copied or phished | 85/100 |
| Code + Passkey | both | Secure inbox access and your unlocked device | 88/100 |
| Code + second factor | One-time code and TOTP/passkey | Secure inbox access and your second device | 90/100 |
| End-to-end with passphrase | Your passphrase | Your passphrase — nothing else helps, not even SchlüsselBot | 98/100 |
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 immediately overwrite it in memory and never write it to disk. However, for this single process, the server blindness described above not. This belongs on this side, even if it is inconvenient. Those who need it must encrypt themselves — the interface supports both options.
And even when self-encrypting, there is a condition that we explicitly state here: anyone who sends the ciphertext along with the fragment field — so we can build the complete retrieval link and send it by email — thereby hands us their Key. We do not store or log it, but for this delivery, it reaches our server, just as in the ‘Simple’ sending method on the website. Full server blindness over the interface therefore means: send ciphertext without fragment and deliver 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
For professionals bound by professional secrecy — including lawyers, Notaries, tax advisors, doctors and psychotherapists — two separate questions must be assessed: if SchlüsselBot processes personal data on their behalf, a data processing agreement under Article 28 GDPR is required on a regular basis. If confidential information belonging to another party becomes accessible, Section 203 Paragraph 4 of the German Criminal Code (StGB) additionally obliges them to ensure that party's duty of confidentiality. Business provides the appropriate documents for both cases; the data processing agreement is generated in the account and the declaration of obligation is subsequently completed in connection with 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.
- Inform the recipient in advance that the link only once and that they Files must be saved immediately — they are loaded directly into the page upon opening and gone as soon as they close or reload the page. We delete them on our server no later than 10 minutes after opening. Also: they should open the link on the device where the file should 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 you for your password, bank details, or one-time code — neither over the phone nor by email. Anyone doing so is attempting to deceive you. Also, simply opening the link does not consume anything: the message is only displayed and then deleted once you enter the one-time code. You may therefore review 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 path is located at /.well-known/security.txt (RFC 9116). We prefer the route via the service itself: submit your report on the Homepage, select the delivery method Secure, and send us the link — your report will then be received 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.