Privacy

Status: 17 August 2026

This privacy policy informs you, in accordance with Articles 13 and 14 of the General Data Protection Regulation (GDPR), about the processing of personal data when using the SchlüsselBot service, accessible at https://schluesselbot.de (hereinafter referred to as "Service" or "SchlüsselBot").

1. Controller

The controller within the meaning of Art. 4 para. 7 DSGVO is:

MessingerDesign, Philipp Messinger & Werner Messinger GbR Dahmestraße 10 12526 Berlin Germany

represented by the individually authorised partners Philipp Messinger and Werner Messinger.

• Email: pmessinger@messingerdesign.de
• Phone: +49 174 967 61 56
• VAT identification number: DE332090964

1.1 Data Protection Officer

We are not legally required to appoint a data protection officer (Art. 37 GDPR, § 38 BDSG). For any questions regarding data protection or to exercise your rights, please contact the responsible party listed above directly.

2. Fundamentals of the service architecture (server blindness / zero-knowledge)

SchlüsselBot is designed as a deliberately data-minimal, server-blind service. Understanding this concept is essential for the legal classification of the following data processing activities:

• Client-side encryption: The content you submit (message and optional attachment) is encrypted directly in your browser – that is, on your end device – before being transmitted to our servers, when using the website. An exception exists for the API: there, you may choose to submit the content either encrypted (field ciphertext) or in plaintext (field message). In the latter case, the content reaches us in readable form, is encrypted by us, and the plaintext is immediately overwritten in memory; for this process, server blindness as described below does not apply. The key required for decryption is never stored together with the ciphertext on the Vault server. During direct delivery, it is carried exclusively in the so-called URL fragment (the part of the link after the # character). A URL fragment is technically not sent to the server when the page is later accessed and therefore does not appear in our server logs. For the direct open button in recipient secure inboxes, the limited exception under section 6.3 c applies.
• Delivery method — your choice: Whether the key reaches us is determined by you when sending directly via our sending form prior to sending. In Security Mode ("Secure"), you transmit the access link together with the key yourself via another channel; the key never reaches our servers. In Convenience mode ("Simple"), you explicitly authorise us to assemble and send the completed link on your behalf; for the duration of sending, the key is temporarily transferred to us. For a Receiving secure inbox, access is determined by the protection level selected during setup; the E2E passphrase uses a separate key pair and does not transmit any key fragment to us. Details and legal bases are available in section 6.3.
• Key and ciphertext remain separated: The content is stored exclusively as encrypted ciphertext on the Vault server. During direct dispatch and with E2E passphrase, we do not store the decryption key. Only in receiving secure inboxes without E2E passphrase does the Edge server temporarily hold an additional encrypted copy of the URL fragment; its server key is stored outside the database and not included in our application security measures. The copy is removed after retrieval, expiry or hiding. Neither keys nor URL fragments appear in logs. Technical inability to access the key exists for the "Secure" dispatch method and E2E passphrase secure inbox.
• Exception: API (Business only): If a customer sends content in Plain text (field message) via the interface, we encrypt it on their behalf. The content reaches us in readable form and is immediately overwritten in memory after encryption; it is not stored or logged. For this route, the above statement "not possible" does not apply, so it is not applicable. Anyone wishing to exclude knowledge of the content even in this case must encrypt it themselves and submit a pre-encrypted ciphertext. Purpose: fulfilment of the usage contract. Legal basis: Article 6(1)(b) GDPR.
• Two-server separation: The publicly accessible server ("Edge") does not store any content permanently; encrypted content resides exclusively — additionally encrypted at rest — on a separate, non-publicly accessible server ("Vault").

Legal consequence (Art. 11 GDPR): As we are unable to read or identify the stored encrypted content, this constitutes processing that does not require identification of the data subject. We address the resulting limitations on your data subject rights separately and transparently under section 20.1.

Our role: For the unencrypted data processed (e.g. recipient email address, sending emails, IP addresses, logs, account and payment data), we are the data controller as defined in Article 4(7) of the GDPR. Regarding encrypted content and attachments, we act as a mere hosting or forwarding service without knowledge of the content – even in the Comfort Mode (Clause 6.3), where although we hold the key, the decrypted content is never transmitted to us; in this respect, the liability protections under Sections 7(2), 8 to 10 of the Digital Services Act (DDG, formerly TMG) apply, and the user remains responsible for the lawfulness of the content.

3. Definitions

This privacy policy uses terms defined in the GDPR (e.g. "personal data", "processing", "controller", "processor", "consent"). Additionally, the following service-specific terms apply:

• Secret: A single encrypted transmission (message and/or attachment).
• One-time code: A proof sent by email to the recipient, demonstrating they control the specified inbox; used as an additional access control before the ciphertext is released.
• Edge server / Vault server: The two-server separation described in Clause 2.
• Delivery method: The route by which the access link reaches the recipient – Security Mode ("Secure") (you transmit the link yourself) or Convenience mode ("Simple") (we send the completed link on your behalf). You select the delivery method when using our sending form. For submissions via a receiving secure inbox, access is governed by the protection level chosen by the owner. Details in section 6.3.
• Receiving secure inbox: A permanent submission address ( /i/<nutzer-nummer>/<name> ), available to users on paid plans. During setup, options include one-time code via email, account Passkey, Code plus Passkey, Code plus second factor, and a personal passphrase with true end-to-end encryption. For Passkey levels, we use the account’s public WebAuthn credentials; biometric data never leaves the end device. For E2E passphrase, we store the private secure inbox key exclusively encrypted with the passphrase.
• Janitor: An automated, time-triggered deletion process that reliably and permanently deletes expired or accessed secrets, regardless of access.

4. Hosting and infrastructure

We operate the service on a two-server architecture:

• Edge server (publicly accessible): Hosted by netcup GmbH, Daimlerstraße 25, 76185 Karlsruhe, Germany. Server location: Germany.
• Vault server (not publicly accessible): operated within the control area of the controller; location: Germany/EU.

Purpose: Provision, operation, and security of the service. Legal basis: Article 6(1)(f) GDPR (legitimate interest in reliable and secure service provision); where processing supports contract performance, additionally Article 6(1)(b) GDPR. Data Processing Agreement: A data processing agreement under Article 28 GDPR is in place with the hosting service provider. Both servers are located in Germany/EU; no transfer to a third country occurs in the context of hosting not. Storage period: See the respective processing and section 19.

5. Server logs

When accessing our website, the edge server automatically collects information transmitted by your browser. These include in particular:

• IP address (fully recorded — used for attack prevention and automatically blocked; a shortened address would be useless for this purpose). Stored for 7 to 14 days, then automatically deleted via daily rotation.
• Date and time of access,
• Retrieved resource / status code,
• amount of data transferred,
• Referrer (if transmitted) and User-Agent (browser type/version, operating system).

Logging minimisation (technical protection measure): Our logs inherently contain none decryption keys, none URL fragments, none one-time codes, and none plaintext content. This explicitly applies to the Convenience Mode (Clause 6.3): the key transmitted there is processed exclusively temporarily in memory and is neither written to access logs nor application logs.

Purpose: Ensuring uninterrupted operation, fault diagnosis, IT security, and attack detection. Legal basis: Article 6(1)(f) GDPR (legitimate interest in operational security and attack prevention). Storage period: Server and application logs are typically automatically deleted or rotated within 7 to 14 days, unless required for investigating a specific security incident.

6. Core function: Secure data exchange (content and attachment)

6.1 Message content

Processed data: the encrypted ciphertext of the message, as encrypted in your browser. We do not receive the plaintext when using the user interface. Purpose: encrypted temporary storage for transmission of the message to the recipient you specified. Legal basis: Article 6(1)(b) GDPR (performance of the transmission process you have instructed). Storage location: exclusively on the Vault Server, additionally encrypted at rest. Storage period:

• Plain message (no attachment): deletion immediately after successful retrieval (view).
• If the message is not retrieved: after the time period chosen by the sender, defaulting to 48 hours from creation. In the Pro and Business plans, the sender may instead choose 24 or 72 hours, or up to no later than 7 days at most.

6.2 Attachments

Processed data: the encrypted ciphertext of an optional attachment (Free up to 2 MB, Pro up to 50 MB, Business up to 100 MB). Attachments may contain personal data of third parties – however, these are also only stored as unreadable ciphertext for us. Purpose: encrypted transmission of the file attachment. Legal basis: Article 6(1)(b) GDPR. Storage location: as an encrypted file object on the Vault Server (not in the database). Storage period (special rule):

• When a message with attachment is retrieved, the attachment is delivered together with the message; after that, it exists solely in the recipient's browser. It remains on our server for up to up to 10 minutes after the first retrieval, after which it is permanently deleted. This is a deletion deadline, not a guarantee of availability: The recipient's copy already resides in their browser — if they close or reload the page, it will no longer be there. There is no second retrieval.
• If the attachment is not retrieved: deletion after the same deadline as the message (default 48 hours, maximum 7 days).

Note on server blindness: Content and attachments exist on the Vault server exclusively as ciphertext. Technically enforced is our lack of knowledge in security mode and in the E2E passphrase secure inbox. For other secure inbox levels, separate, time-limited processing applies per Section 6.3(c). Final, time-controlled deletion is enforced by our Janitor process, independent of access.

6.3 Sending method and handling of the decryption key

When sending via our send form, you select before sending how the retrieval link reaches the recipient. This choice determines whether we ever see the decryption key. We clearly separate the options here because they imply different levels of confidentiality towards us as provider. Letter c describes the special case of submission via a receiving secure inbox; there, the protection level chosen by the owner during setup determines the key and retrieval path

a) Security mode ("Secure"): SchlüsselBot sends only a notification and, when requested, the one-time code. You send the retrieval link, including its key, through a separate channel such as a messenger, SMS or in person. Processed data: no key. With this delivery method, the key reaches our servers at at no point in time, so the zero-knowledge property applies without restriction.

b) Comfort Mode ("Simple", default): You expressly instruct us to send the completed retrieval link, including the key, by email to the recipient you specified. Processed data: the key fragment used to assemble the retrieval link. Purpose: to carry out the transmission you have instructed. Legal basis: Article 6(1)(b) GDPR (performance of the contracted transmission process). Processing location: exclusively temporarily in the working memory of the edge server. The key leaves the edge server only via a single route – as part of the retrieval link, sent with the notification email via the delivery channel described in section 9 to the recipient's inbox; this is exactly the purpose you have instructed. No transfer to the vault server, where the ciphertext resides, takes place; thus, ciphertext and key are never combined at any point. not at all. Storage period: no storage – the key is neither stored in the database nor logged, and is discarded immediately after the email has been sent.

c) Submission via a receiving secure inbox: Send via another user's secure inbox address (/i/<nutzer-nummer>/<name>), your content is always encrypted with AES-256-GCM in your browser. Additional information you entered regarding sender name and subject is intentionally not part of the encrypted content: The recipient is listed in the notification email and in their inbox overview (section 14.2), so it is clear who sent it and what it is about. Both fields are optional and may remain empty. In the stages Code, Passkey, Code plus Passkey, and Code plus second factor, the random key is sent as part of the notification link to the recipient. To allow the recipient to open the same submission directly from their registered inbox, we store the URL fragment additionally, encrypted with AES-256-GCM, on the edge server. The server key used for this is protected at root level, stored outside the database, separate from the ciphertext on the Vault server, not recorded in logs or application security, and the copy is deleted after retrieval, expiry, or hiding. The required proof of opening still depends on the selected stage; the dashboard button does not bypass either the code or the Passkey. In the E2E passphrase stage, the recipient’s browser generates a key pair; the sender encrypts using the public key, and the private key exists only in passphrase-encrypted form. The key fragment does not reach us in this stage. Processed data: the ciphertext, depending on the level, either the encrypted temporarily stored key fragment or public ECDH key data, the recipient's email address, and optionally their public passkey login details. Purpose: Delivery and secure retrieval of the submission. Legal basis: Art. 6 para. 1 lit. b DSGVO.

Transparency notice regarding letters b and c: In comfort mode and for secure inbox levels without a personal E2E key pair, keys and ciphertext — though for different purposes and without being combined — pass through our systems. Confidentiality towards us is not technically enforced in these cases, but relies on the described measures: in comfort mode, no storage or logging occurs; for secure inboxes, encrypted, separate, and time-limited storage is used without including the server key in application security. With the E2E passphrase, server blindness is technically enforced; however, a forgotten passphrase cannot be reset.

6.4 Special categories of personal data (Art. 9 GDPR)

The service is explicitly offered to professional groups where the exchange may involve special categories of personal data under Art. 9 para. 1 GDPR — particularly Health data (doctors’ and dentists’ practices, therapy, care) as well as indirect data revealing religious, philosophical, trade union, or sexual life information (counselling services, law firms). We therefore clarify:

• Role distribution. If you use SchlüsselBot for professional or business purposes to transmit data about your patients, clients, applicants or employees, You are the responsible controller under Article 4(7) GDPR; we act as processor under Article 28 GDPR. Whether processing of special categories is permitted depends on a lawful basis in your sphere (e.g. Article 9(2)(a), (h) or (f) GDPR, § 22 BDSG). We do not assess this and cannot assess it.
• A Data Processing Agreement is a prerequisite. For this use, you need a contract under Article 28(3) GDPR. It is included in the Business plan and can be generated directly in your account; it is not available in the Free and Pro plans. Without it, you may not use the service professionally for personal data of third parties.
• Holder of professional secrecy, § 203 StGB. Anyone subject to professional secrecy under § 203(1) StGB may only involve supporting persons under the conditions set out in § 203(3) StGB. We provide a separate declaration of obligation under § 203(4) StGB in the Business plan, which you can download together with the data processing agreement from your account.
• The content is unreadable to us – the accompanying data is not. The message and any attachment are only available to us as ciphertext (Clause 6.1, 6.2). Readable by us are, however, (partly stored unencrypted, partly encrypted with a key we hold ourselves): the sender and recipient email addresses, a Subject you assigned, a Sender name (Clause 6.3, letter c), and the Name of a receiving secure inbox, which is part of a publicly distributable address. These details alone may already constitute data under Art. 9 GDPR. Therefore, we strongly recommend not including any information about diagnosis, treatment, procedure subject or consultation reason in the subject line, sender name or secure inbox name – a neutral subject (e.g. "Documents", "Receipts") is sufficient, as the content is already encrypted during transfer. All three fields may remain empty.
• No profiling, no analysis. No evaluation, categorisation, or automated decision-making based on content takes place, and this is technically not possible for us (Clause 2, Clause 20.1).
• Deletion. For special categories, no longer retention periods apply, but the same short periods as for all content (Clause 6.1, 6.2, Clause 19); deletion occurs immediately after retrieval.

7. Recipient email address (mandatory)

Processed data: the recipient's email address you provided. Purpose: Delivery of the retrieval link and, upon request by the recipient, the one-time code. The recipient's address is essential to the service: Without it, the transmission process you have commissioned cannot be carried out. Legal basis: to the sender, Article 6(1)(b) GDPR (processing necessary for the performance of the contracted transmission); to the recipient, who is not a party to the contract, Article 6(1)(f) GDPR (legitimate interest in delivering the message intended for them) — You have the right to object under Art. 21 DSGVO against this processing (clause 21); a message to our abuse address is sufficient, after which we will no longer send you anything. Storage period: until delivery or retrieval, but in any case not later than the deadline chosen by the sender (default 48 hours, in Pro and Business up to 7 days) for uncollected secrets; after successful retrieval, it is deleted together with the secret (with attachments, after the 10-minute window expires). Purpose limitation: It takes place none Creation of distributors, none Use for advertising purposes only; no reuse for other purposes than those specified here. Exception: Delivery blocklist: If the recipient's mail server explicitly rejects an address (SMTP code 5.1.x) or a misuse complaint is received, we record the address along with the reason and timestamp in a blocklist and send nothing more to it. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in ensuring our mail server's deliverability and protecting third parties from unwanted deliveries). Storage period: 180 days (only entries from delivery failures; a objection under Art. 21 DSGVO remains stored indefinitely — otherwise we could not permanently observe it, Art. 17 para. 3 lit. e DSGVO). Deletion from the blocklist is possible at any time via the address listed in the imprint.

8. Sender email address (optional, voluntary)

Providing a sender email address is voluntary and not a mandatory requirement. It is only processed if you wish to receive delivery or read notifications.

Purpose: Notification to the sender regarding delivery or retrieval. Legal basis: Article 6(1)(b) GDPR (execution of the transmission process) or Article 6(1)(a) GDPR (consent), where applicable to purely notification-based processing. You may withdraw your consent at any time with effect for the future. Storage period: Stored together with the associated secret (immediately upon retrieval or at the end of the chosen period, default 48 hours, maximum 7 days); if no sender address is provided, we do not store any data.

9. Sending of notification and code emails

To provide the service, we send a neutral notification email to the specified recipient address, containing the access link, and — on request — an email with the one-time code.

• Content of emails: The actual message content is never in the email itself, but exclusively encrypted behind the retrieval link. The notification itself, however, includes two freely selectable by the sender fields that the sender may voluntarily fill in: a Sender names (up to 60 characters, appears in the subject) and a brief personal message (up to 500 characters, appears in the email body). Both fields may be left empty. Purpose: The recipient should be able to identify the sender and the subject — without this information, a notification may appear like a phishing attempt. Legal basis: Article 6(1)(b) GDPR for the sender, Article 6(1)(f) GDPR for the recipient. Storage period: as the associated message (Section 6.1). An automated filter removes internet and email addresses from both fields to prevent the notification from being misused as a carrier of external links; no content review takes place. The same applies to submissions via receiving secure inboxes (Section 6.3(c)) and the API in the Business plan.
• Processed data: Recipient email address, access link or one-time code. In Comfort Mode ("Simple") and when secure inbox levels do not have their own E2E key pair, the access link sent by email additionally contains the key fragment; in Security Mode ("Secure") and for E2E passphrase secure inboxes, it does not.

Purpose: Delivery of access link and one-time code; ensuring only the recipient’s secure inbox holder can access the ciphertext. Legal basis: Article 6(1)(b) GDPR (performance of the transmission process); additionally, Article 6(1)(f) GDPR (legitimate interest in secure delivery and abuse prevention) regarding the one-time code. Storage period: Recipient address and code reference are deleted together with the secret (see paragraphs 6, 7, and 10).

Delivery route: Email delivery is carried out via a own mail server ( server.messingerdesign.de ), operated by the provider in Germany. No external transactional email service provider is used; therefore, no data is transferred to third parties and no international data transfer occurs.

10. One-time code (proof that the inbox is reachable)

The one-time code serves as proof that the recipient controls the specified inbox and protects against unauthorised access through simple forwarding or interception of the link.

Processed data: the one-time code; server-side, this is stored exclusively as a cryptographic hash, never in plaintext. Purpose: secure, recipient- and secret-bound delivery of the ciphertext; protection against link leaks, forwarding, and automated attacks. Legal basis: Article 6(1)(b) GDPR (part of secure delivery) in conjunction with Article 6(1)(f) GDPR (legitimate interest in security and abuse prevention). Technical protection measures (Art. 32 GDPR): hash-only storage, comparison in constant time (protection against timing attacks), sufficient key length, brute-force protection via rate limiting and attempt counter, one-time use, binding to the respective secret. Storage period: stored together with the associated secret (immediately upon retrieval or upon expiry of the selected period, default 48 hours, maximum 7 days).

11. Security, abuse prevention and Captcha

11.1 IP addresses for rate limiting and abuse prevention

Processed data: IP address (fully, exclusively used as a counter key; automatically deleted after at most 24 hours) of the accessing device, and optionally a counter for sending activities. Purpose: Protection against brute-force attacks, spam, mass sending, and overload (DoS); ensuring service availability and integrity. Legal basis: Article 6(1)(f) GDPR (legitimate interest in security, availability, and misuse prevention; see recital 49 GDPR). IP addresses are considered personal data under the case law of the ECJ (Case C-582/14, "Breyer"). Balancing of interests: The risk of misuse of an anonymous-accessible transmission service is significant; processing is necessary for prevention, and is data-minimal: the address is used only as a counter key, is not linked to any account, and is deleted after at most 24 hours, remaining short-lived and without profiling or correlation with content. Your protected interests therefore do not outweigh this. Storage period: Within short-lived rate-limiting windows (minutes); for misuse correlation, up to 24 hours, after which deletion occurs.

11.2 Captcha (bot protection)

To protect against automated abuse during sending, we use a privacy-friendly, preferably EU/self-hosted protection mechanism: a self-run computational task (Proof-of-Work) solved in the browser.

Purpose: Protection against automated spam and mass distribution. Legal basis: Article 6(1)(f) GDPR (legitimate interest in preventing abuse). Storage period: Only for the duration of validating the respective challenge.

Note: Should a third-party captcha provider (e.g. Cloudflare Turnstile, hCaptcha) be used in the future that processes data outside the EU, it will be disclosed as a processor in Section 17, including location and third-country safeguards. Where required, consent will be obtained. No external captcha service will be integrated; no data will be transmitted to third parties.

12. Range measurement / Analytics

No external analytics script: SchlüsselBot does not load JavaScript from any analytics provider on public or sensitive pages. This prevents an analytics service from reading input before browser encryption, credentials, retrieval identifiers or secure-inbox paths. Google Analytics and comparable third-party services are not used.

Audience measurement is generated exclusively on the server from the short-lived access logs that already arise and is immediately aggregated into coarse daily figures. No cookies, analytics identifiers, browser fingerprinting, dwell time, scroll depth or click profiles are used. Retrieval pages (/r/…), receiving secure inboxes (/i/…), APIs and the logged-in area are excluded from these statistics.

12.1 Internal daily statistics and service usage

For internal operational overview, SchlüsselBot additionally generates a deliberately coarse daily summary. This is based on the server logs described in point 5; no further request triggered from your browser, no cookie or browser storage is used, and no additional identifier is set. Known bots and technical testing programs are filtered out. IP address and browser identifier are used solely during processing to prevent repeated requests on the same calendar day from being counted multiple times as visitors. These details, and any checksum derived from them, remain only in memory and are not included in the statistics. Only the calendar day, number of visitors, and number of page views are stored. Thus, recognition across different days is not possible.

Daily statistics only include public information, registration, and sign-up pages. Access pages ( /r/… ), inbox folders ( /i/… ), APIs, and logged-in areas are excluded. Therefore, the sum over multiple days is the sum of daily visitors, not a count of uniquely identifiable individuals.

In addition, SchlüsselBot only records, for a successfully saved secure message, the type of operation (direct send or recipient secure inbox), size of the already encrypted data packet, whether an attachment was included (yes/no), and timestamp. With registered usage, account or company assignment is also recorded; this is removed after account deletion. Message content, recipient address, subject, or filename are not recorded. For confirmed self-registration, only a distinction is made between self-registration and registration via social login; invitations and accounts created by the operator do not count as conversion.

Purpose: Daily analysis of reach and conversion, capacity planning, and service improvement. Conversion is a purely statistical comparison of daily totals; SchlüsselBot does not track which individual later sends a message or creates an account. Legal basis: Article 6(1)(f) GDPR (legitimate interest in efficient, data-minimising performance measurement and secure, economic operation); additionally, Article 6(1)(b) GDPR for provision and billing of the purchased plan in relation to account-specific usage events. Storage period: Aggregated daily values and content-free usage events are automatically deleted after 25 months. This allows comparisons over two full years without maintaining an unlimited usage history. The underlying server logs are deleted independently after 7 to 14 days.

13. Cookies and local storage

SchlüsselBot uses no non-essential cookies and no analytics or advertising storage. A consent banner is therefore not required. Technically necessary storage is limited to the secure account session, your selected language and short-lived security state for one-time retrieval. It serves only the function explicitly requested and does not require consent under Section 25(2)(2) TDDDG.

14. Account and login (paid plans, optional)

Core usage of SchlüsselBot is without account. An account is only required for paid plans (e.g. higher limits, personal receiving secure inboxes, contact management) and is fully optional.

Important: An account grants no access to encrypted content. The account is used solely for managing and controlling usage limits; the service architecture remains unaffected (the decryption key is not derived from account data nor stored in the account; the distinction by delivery method in clause 6.3 remains unchanged).

Processed data: email address, password (stored exclusively as Argon2id hash, never in plaintext), and upon activation of two-factor authentication, a 2FA secret or passkey data; optionally, a profile/subject ID when using social login (see Clause 15). Purpose: provision and management of the paid account (registration, management, higher limits, security). Legal basis: Article 6(1)(b) GDPR (performance of the user agreement). Technical protection measures (Art. 32 GDPR): password hashing with Argon2id, optional or mandatory two-factor authentication (TOTP/passkey), revocable sessions. Storage period: for the duration of the account’s existence. After cancellation or deletion of the account, the data will be deleted or anonymised, unless legal retention obligations apply (see Clause 16 for billing-relevant data).

14.1 Two-factor authentication (2FA)

Passkeys (WebAuthn): When logging in with a passkey, biometric data (e.g. fingerprint, facial features) remain exclusively on your endpoint device and are never transmitted to us. Our server stores only a public key and a random identifier; identification or tracking across other services is therefore not possible.

Processed data: TOTP secret and/or Passkey/WebAuthn login data, and optionally Argon2id-hashed recovery codes. Purpose: Securing account access against unauthorised login and phishing. Legal basis: Article 6(1)(b) GDPR (necessary for contract performance) or Article 6(1)(f) GDPR (legitimate interest in account security). Storage period: For the duration of the account or until the function is deactivated.

14.2 Address book and inbox overview in customer area

Address book: You may store email addresses along with optional names in the logged-in area to select them during sending. In the Business plan, an API key explicitly granted contacts:read or contacts:write permissions may read or manage the same contacts. Processed data: only the names and email addresses you enter. Both fields are encrypted in the database using AES-256-GCM and only decrypted during an active session or a properly authorised API call; the key used for this is stored separately from the database and web root. The checksum for duplicate detection is secret-key bound and unique per account, so a database dump cannot link identical contacts across different accounts. Purpose: improved usability during sending and customer-selected software integration. Legal basis: Article 6(1)(b) GDPR. Storage period: until deletion by you, at most until account deletion. No matching with other data sets, enrichment or transfer to third parties occurs.

Overview of incoming secure inboxes: When a submission arrives via one of your receiving inboxes, we record an entry in your customer area. Processed data: the already public retrieval-link reference number, the affected inbox, the time of receipt, whether an attachment is included, and — if voluntarily provided by the sender — the sender name and subject (same details as in the notification email). For inboxes without E2E passphrase, the encrypted copy of the URL fragment described in Clause 6.3 c is added until retrieval, expiry, or hiding. Content is not stored upon receipt. The submission remains encrypted on the separate Vault server; for inboxes with their own key pair, it is technically impossible for us to access the content. Purpose: Overview and direct, ongoing retrieval secured by the chosen protection level, independent of the notification email. Legal basis: Art. 6(1)(b) GDPR. Storage period: Metadata retained for 30 days from receipt; the encrypted fragment copy only until retrieval, expiry, or hiding — at most 7 days for uncollected submissions. The submission itself is deleted independently per Clause 6.

15. Social login (optional)

If offered and selected by you, you may optionally register and log in via an external identity provider (Identity Provider, IdP). This use is strictly voluntary (Opt-in) and does not affect core service usage without an account. Only the profile data required for login (typically your email address and a subject ID) will be processed.

Common legal framework for all social logins: Purpose: fast account creation and login. Legal basis: Article 6(1)(b) GDPR (performance of the account contract) and Article 6(1)(a) GDPR (consent to integration of the respective provider). Consent may be withdrawn at any time with effect for the future. Third country transfer: The providers listed below are based in the USA or process data in the USA. As such, a third-country transfer takes place. The basis for the transfer is — where the respective provider is certified — the EU-US Data Privacy Framework (DPF) pursuant to the EU Commission's adequacy decision, otherwise Standard Contractual Clauses (SCCs) under Article 46(2)(c) GDPR, together with additional safeguards. Technical note: The key required for decryption never depends on the identity provider; the service's security promise remains unaffected.

15.1 Microsoft login

Provider: Microsoft Corporation, One Microsoft Way, Redmond, WA 98052, USA. Third-country transfer to the USA based on DPF/SCC (see above). Privacy notice: https://privacy.microsoft.com/de-de/privacystatement.

15.2 Google login

Provider: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland, or Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA. Third-country transfer to the USA based on DPF/SCC (see above). Privacy notice: https://policies.google.com/privacy.

15.3 Apple login

Provider: Apple Inc., One Apple Park Way, Cupertino, CA 95014, USA. Third-country transfer to the USA based on DPF/SCC (see above). Privacy notice: https://www.apple.com/legal/privacy/de-ww/.

Note: The actual availability of the options listed above may vary. Unavailable options do not trigger any processing. As of today, registration via Microsoft, Google and Apple is disabled — the buttons on the login page are greyed out. No data is transmitted to these providers. This section applies only from the point in time when the feature is enabled.

16. Payment processing (paid plans)

Payment for paid plans is processed by PayPal (Europe) S.à r.l. et Cie, S.C.A., Luxembourg. PayPal is a pure payment service provider. The contractual partner, invoice issuer, and VAT debtor remains MessingerDesign GbR; the invoice and VAT certificate are issued by us. We transmit to PayPal only the data required for payment (amount, subscription ID, email address). Legal basis: Article 6(1)(b) GDPR.

Data processed by SchlüsselBot: billing-relevant master data (e.g. name, billing address, subscribed plan, requested and effective location changes, transaction/invoice reference) – none complete payment details. Purpose: Processing and billing of the paid subscription, as well as compliance with tax and commercial legal obligations. Legal basis: Art. 6 para. 1 lit. b DSGVO (contractual performance) and Art. 6 para. 1 lit. c DSGVO (fulfilment of statutory record retention obligations). Accounting: SchlüsselBot transmits customer name, billing address, email address, document, tax and transaction data to Lexware Office (Haufe-Lexware GmbH & Co. KG, Freiburg) so that invoices and invoice corrections can be recorded and retained in financial accounting. Message content, attachments, contacts and secure inbox data are not transferred to Lexware Office. Third country transfer: Payment processing is carried out via PayPal (Europe) S.à r.l. et Cie, S.C.A., Luxembourg. PayPal may process data in third countries within its corporate structure. Lexware Office is used under a data processing agreement and utilises the sub-processors listed in section 17; the safeguards specified there apply in case of potential international access. Storage period: Invoice and accounting data are stored in accordance with statutory retention periods 8 years (§ 147 para. 3 AO, § 257 para. 4 HGB, § 14b para. 1 UStG; commercial books, inventories and annual financial statements: 10 years). Other account data are deleted in accordance with section 14.

Proof of location for billing addresses outside the EU: To prevent SchlüsselBot from solely deriving the tax location from a freely chosen country field, SchlüsselBot cross-checks the country in the full invoice address with the origin country of the IP address used at checkout. Geolocation is performed exclusively locally on the SchlüsselBot server; the IP address is not transmitted to any external geolocation service. The IP is encrypted using a separately stored key and stored alongside the two country codes, timestamp, database version, and a tamper-proof signature. If the two countries do not match or no proof is available, automatic tax-free billing for third countries will not occur. Purpose and legal basis: Determination and verification of the tax location, Article 6(1)(c) GDPR in conjunction with Articles 24b and 24f of Regulation (EU) No 282/2011. Storage period: 8 years, stored together with the invoice record. Used geodata: IP geolocation by DB-IP (Country Lite, CC BY 4.0; local monthly file).

17. Data processors and recipients (Art. 28 GDPR)

We use carefully selected service providers who process personal data exclusively on our instructions and under a contract for processing data in accordance with Art. 28 GDPR. Data will only be transferred to other recipients if necessary for service delivery or if a legal basis exists.

The free core service runs exclusively within the EU and without transfer to third countries. Paid plans may involve third-country processing, where PayPal transfers data internally within the group or a contractually approved sub-processor of Lexware Office Support gains access. Message contents are not transmitted to any of these providers. The optional social login is currently disabled.

The appointed processors and additional recipients are netcup GmbH (server infrastructure, Germany), CrowdSec SAS (attack detection, France), PayPal (Europe) S.à r.l. et Cie, S.C.A. (payment processing, Luxembourg), and Haufe-Lexware GmbH & Co. KG with Lexware Office (financial accounting, Germany). They are listed in the table above with purpose and location.

18. International data transfers – general notes

Where we transfer data to recipients in a third country (in particular the USA), as specified in detail in this statement, this is only done

• Based on an adequacy decision by the European Commission, particularly the EU-US Data Privacy Framework (DPF), provided the recipient is certified, or
• Based on appropriate safeguards under Art. 46 GDPR, particularly the Standard Contractual Clauses (SCCs) issued by the European Commission, supplemented by an assessment of the effectiveness of additional protective measures (Transfer Impact Assessment).

You can request a copy of the respective guarantees from the controller.

19. Overview of data retention periods

Introduction to backups. The following deadlines apply to ongoing operations. Additionally, systems are backed up daily to enable service recovery after a failure. A deleted data record may still be present in these backups until the backup retention period expires (daily 7, weekly 4, monthly 12 generations). Backups are encrypted and stored on a separate, non-publicly accessible system. Message contents remain unreadable within them — the key for this is not stored anywhere. Accompanying notes (particularly sender and recipient addresses) are also encrypted, but the necessary key material is located within the same backup set. A request to delete under Art. 17 GDPR is processed immediately during normal operation; backups then expire automatically according to schedule.

The short deletion periods are technically enforced by a time-triggered, automated deletion process (Janitor) and are not dependent on retrieval.

19a. Additional data processing in your account (as of August 2026)

The following functions were added after the initial version of this statement. They are fully listed here to ensure the statement reflects the current status.

a) failed login protection protocol

After each failed login, confirmation, or retrieval attempt, we store Timepoint, type of event, and IP address in a dedicated log file. This helps prevent repeated automated attacks at the network level. We use fail2ban (entirely local, analysing only this file of failed attempts) and CrowdSec, which additionally evaluates the general access log and shares detected attack patterns with the provider's community network — see point 17.

Purpose: Protection against attacks on accounts and ensuring service availability. Legal basis: Article 6(1)(f) GDPR. Storage period: 7 days, after which automatic deletion occurs through daily rotation. A network block is automatically lifted after one hour.

b) Interface keys (API)

In the Business plan, you can generate keys for the API. These are stored with a freely chosen label, a non-secret username, a key checksum (never the key itself), individually assigned permissions, optional allowed browser origins (HTTPS origins), the creation timestamp, the last usage timestamp, and any revocation status.

For securely repeatable send requests, customer software may transmit an Idempotency-Key. SchlüsselBot stores this identifier, a checksum of the request content, processing status, and response for up to 24 hours. The response may include a one-time retrieval link and is therefore encrypted using a key located outside the database. The request content itself is not stored.

Purpose: Authentication of requests from the customer's own software, restriction to necessary functions, secure browser connection, and prevention of duplicate transmissions in case of network failures. Legal basis: Article 6(1)(b) GDPR. Storage period: Key metadata until revocation of the key or account deletion; retry data retained for a maximum of 24 hours.

c) Webhooks — transmission to a system specified by the customer

Business plan customers can set a custom internet address to which SchlüsselBot sends notifications about key creation, retrieval, withdrawal, expiry, or failed email delivery. The transmitted data includes Event and transaction number, timestamp, delivery status, and indication of whether an attachment was included — no content and no recipient or contact addresses. Delivery is signed with a secret and only sent to publicly accessible https addresses. The signing secret is stored by SchlüsselBot, encrypted with a key kept outside the database.

To ensure no event is lost if the target system is temporarily unavailable, each delivery is stored in a queue and repeatedly checked before the first network request. Event type and ID, empty JSON body, attempt counter, next attempt time, response status, and error text are stored.

Recipient: The target system designated by the customer. The customer defines it themselves and is responsible for its compliance with data protection regulations. Purpose: Reliable integration with the customer’s own software. Legal basis: Art. 6 para. 1 lit. b GDPR. Storage period: Recipient address and encrypted signature secret until webhook or account deletion; completed or permanently failed delivery logs retained for up to 30 days.

d) Team memberships in the Business plan

A Business account can add further accounts as members. The group admin sees for each member E-Mail address, name, date of joining, and time of last login — never messages, secure inboxes, or contacts of the members. Open invitations are stored with the target address and expiry date.

Purpose: Management of booked user slots. Legal basis: Article 6(1)(b) GDPR; if the customer uses the service for employees, they are responsible for their data (§ 26 BDSG). Storage period: Until departure from the team; invitations are retained for 14 days.

e) proof of generated order processing agreements

When a customer in the account enters into a contract under Article 28 of the GDPR, we record Contract number, company, address, named representative, version of the contract text, timestamp, and IP address. These entries are not altered or deleted while the contract remains in force — they serve as proof of when each version was concluded.

Purpose: Demonstrable compliance with supervisory authorities for both parties. Legal basis: Article 6(1)(c) in conjunction with Article 28(9) GDPR. Storage period: For the duration of the contract and subsequently at least six years from the end of the year in which the contract ended (§ 147(1) no. 2 in conjunction with (3) AO). Deletion occurs once the evidentiary purpose no longer applies; upon deletion of your account, we remove company name, address, authorised representative, and IP address, retaining only the contract number, version, and timestamp — evidence under Article 28 GDPR is specifically required for the period after the contract ends.

f) Cancellation logs

Each cancellation declaration submitted via the cancellation button is recorded with Address, name, contract reference, type of cancellation, voluntary reason, preferred date, date of receipt and IP address.

Purpose: Proof of receipt, content, and timing as required by § 312k(4) BGB. Legal basis: Article 6(1)(c) GDPR. Storage period: at least six years from the end of the year of termination (§ 147(1) no. 2 AO; the termination confirmation also serves as evidence under § 312k(4) BGB). Upon deletion of your account, we remove name, reason, desired termination date, and IP address; your email address is replaced with a hash. It is no longer plaintext but still allows us to identify the account in a dispute — therefore, we retain it within the framework of statutory evidentiary obligations; only the fact that termination was requested and confirmed at a specific point in time remains.

g2) Request for the Business plan (request form)

Processed data: Company or practice name, your name (voluntary), email address, phone number (voluntary), desired number of seats, call-back request, and a voluntary message (up to 1,000 characters). Purpose: To provide you with the requested offer and subsequently activate the chosen plan. Legal basis: Article 6(1)(b) GDPR (actions taken in response to your request, prior to contract conclusion). Storage: The information is not permanently stored in our database. For up to 25 hours, your address is stored there as a counter against misuse — to prevent anyone from using the form as a mass-sending tool; after that, it is automatically deleted. The data is transmitted exclusively by email to our inbox office@messingerdesign.de, where it is processed; an acknowledgement of receipt is sent to the email address you provided. Recipient: This inbox is operated by a hosting service provider in Germany; they act as a data processor under Article 28 GDPR. Storage period: Until final processing of your request, up to 12 months; if a contract is concluded, the commercial and tax retention periods apply (Section 16). Voluntary: Mandatory fields are only company and email address — without them, we cannot provide an offer. Phone number and message are voluntary; if no phone number is provided, we will contact you by email. No advertising: We use this information solely to respond to your request and will not send you any marketing material without your explicit consent (§ 7 UWG).

g) Processing of incoming spam messages

We operate an email address that is specifically designed for automated address harvesters and is not visible to humans. All messages received there are classified as unwanted and used to train our own spam filter.

Purpose: Protection of our own email infrastructure against unwanted messages. Legal basis: Article 6(1)(f) GDPR. No information to senders under Article 14 GDPR is provided, as this would target senders of unwanted mass mailings and would involve disproportionate effort (Article 14(5)(b) GDPR).

20. Your rights as a data subject (Art. 12–22 GDPR)

You have the following rights regarding your personal data, as the data subject:

• Right of access (Article 15 GDPR),
• Correction (Article 16 GDPR),
• Deletion (Art. 17 DSGVO),
• Restriction of processing (Art. 18 GDPR),
• Data portability (Art. 20 GDPR),
• Objection to processing (Art. 21 GDPR, see clause 21),
• Withdrawal of consent with effect for the future (Art. 7 para. 3 GDPR).

To exercise your rights, a non-formal communication to the contact details listed under point 1 is sufficient.

20.1 Special consideration for server-blind service (Art. 11 GDPR)

For unencrypted data (in particular recipient email address, account and payment details), we provide access, correction, and deletion within the legal scope.

For encrypted content and attachments, there is a conceptually inherent limitation: With the "Secure" sending method and the E2E passphrase secure inbox, we technically lack the decryption key entirely; thus, we cannot provide content-based access or corrections (Art. 11 GDPR). In all other secure inbox levels, ciphertext and encrypted fragment copy are separated both organisationally and technically, but the process is clearly assigned to the registered secure inbox holder. We process data subject requests there based on available metadata; no content decryption occurs as part of standard service.

You still retain full control: You can trigger the Deletion of a specific encrypted process at any time via its identifier or link; regardless, our Janitor process automatically deletes every process no later than 48 hours after transmission (or according to the chosen period in paid plans, up to seven days), or immediately after retrieval.

21. Right to object (Art. 21 GDPR)

You have the right to object, at any time, to the processing of your personal data that is based on Article 6(1)(f) of the GDPR, on grounds relating to your particular situation.

This particularly concerns: the Delivery of notifications to a recipient address that you have provided (Clause 7), maintaining the delivery blocklist (Clause 7), processing IP addresses for abuse prevention (Clause 11.1), server logs, and cookie-free reach measurement. If you object, we will no longer process the relevant data unless we can demonstrate compelling legitimate grounds for the processing that override your interests, rights, and freedoms, or unless the processing is necessary for the establishment, exercise, or defence of legal claims. In addition, for delivery to a recipient address: We do not review or assess anything — your message to our abuse address is sufficient, and we will not send you anything else ever again. We will not automatically remove this entry (Article 17(3)(e) GDPR); only at your request will we delete it.

22. Right to lodge a complaint with a supervisory authority

Without prejudice to any other administrative or judicial remedy, you have the right to lodge a complaint with a data protection supervisory authority (Article 77 GDPR), in particular in the Member State of your habitual residence, place of work, or the place of the alleged infringement.

The supervisory authority responsible for the data controller is:

Berlin Commissioner for Data Protection and Freedom of Information Alt-Moabit 59–61, 10555 Berlin Phone: +49 30 13889 -0 Email: mailbox@datenschutz-berlin.de

23. Obligation to provide data

Providing the Recipient email address is required for using the core functionality: without it, we cannot carry out the transmission process you have instructed. There is no legal or contractual obligation to provide it; however, you will only miss out on using the feature — there are no other disadvantages.

Providing a Sender address, creating a Accounts, and using Social login and paid features are optional.

24. No automated decision-making / no profiling

A decision based solely on automated processing — including profiling — that has legal effect on you or significantly affects you in a similar way does not take place. Automated processing occurs only in the case of adding an email address to our delivery blocklist when the recipient’s mail server permanently rejects it, and in the case of a temporary network block after repeated failed attempts. Both relate solely to technical deliverability, not to any assessment of your person; you may have the entry removed at any time by contacting the address listed in Clause 1. We will review your request manually. The security measures we use (e.g. rate limiting) serve exclusively to prevent abuse and do not result in profiling of your person.

25. Data security (technical and organisational measures, Art. 32 GDPR)

We implement appropriate technical and organisational measures to protect your data, in particular:

• Client-side end-to-end-like encryption (except for plaintext transfer via the programming interface, see clause 6.3) of the content; technically enforced server blindness in security mode and in E2E passphrase secure inbox,
• for other secure inbox levels, AES-256-GCM-encrypted, time-limited fragment copy on the edge server, with a server key protected by root access and separated from database, vault, and application security measures
• when sending via our send form, the option to choose a sending method where we never receive the key (security mode ("Secure"), section 6.3)
• Separation into edge and vault servers, encryption of content even at rest (at-rest),
• Exclusive hash storage of one-time codes and comparison in constant time,
• Password hashing with Argon2id and two-factor authentication,
• Rate limiting and abuse prevention,
• strict logging minimisation (no keys, one-time codes, URL fragments or plaintext content in logs),
• Time-based, final deletion (Janitor process, "Crypto-Shredding"); for continued existence in encrypted backups, see the introductory note to clause 19,
• TLS encryption of data transfer.

26. Changes to this privacy policy

We reserve the right to update this privacy policy to align with changes in legislation or modifications to the service and data processing activities. The version available at the time of your visit will apply. You can find the current version at the beginning of this statement.

As of 17 August 2026