Security at lionbackup

How we protect your data – explained clearly for decision-makers and documented in detail for engineering and audit.

Management overview

lionbackup is built from the ground up so that nobody but you can read your content – not even us as the operator. This is ensured by an end-to-end security concept of client-side encryption, immutable storage, strictly separated zones and complete auditability.

In addition, the technical and organisational measures (TOMs), the service description and the data processing agreement (DPA) document the safeguards contractually (German).

Technical details

1. Client-side end-to-end encryption

Encryption happens entirely in the open-source lionbackup client before any data is transferred. Every file gets a fresh, random data key (DEK); the payload is encrypted in authenticated blocks with XChaCha20-Poly1305. The DEK is encapsulated hybrid – classically via X25519 and post-quantum-safe via ML-KEM-768 (age hybrid scheme). Private keys never leave your system and are stored locally with restrictive file permissions. Consequence: the server only ever sees ciphertext. If you lose your key, recovery is technically impossible – by design.

2. Immutable storage (WORN) with retention

Backups land in a hardened, redundant storage system. For immutable projects the platform itself guarantees that every object can neither be overwritten nor deleted for the customer-configured retention period (Write Once, Read Never) – independent of individual storage components. Your backups stay intact even if a compromised system tries to destroy them.

3. Separated zones & fully encrypted traffic

The platform is split into a central backup zone (management, portal, control) and several geographically separated storage zones. Customer uploads go directly to the storage endpoint (“Citadel”) of the chosen storage zone – not through the management zone. Cross-zone control and metadata traffic (e.g. synchronisation, audit forwarding) runs exclusively over a strongly encrypted, mutually authenticated interconnect with a separate connection per zone. Each zone is network-isolated.

4. Central single sign-on & mandatory multi-factor authentication

The only way to log in is single sign-on via a central, dedicated identity platform. There are no local passwords in the portal. Two-factor authentication via TOTP is mandatory and cannot be bypassed. Users and groups are managed centrally; the portal evaluates exclusively cryptographically signed authorisation claims.

5. Least-privilege database access

The application connects with a dedicated, unprivileged database user (no superuser) whose rights are restricted to the application schema. Read queries are routed to a replica where possible; writes go to the primary database. Credentials are not embedded in code but fetched at runtime from a protected secret store and can be rotated.

6. Central audit logging & anomaly detection

Security and application events (logins, audit entries, completed uploads) are shipped as structured records to a central, access-protected analysis system where they can be evaluated. In addition, the storage endpoint checks every upload heuristically: an entropy measurement (Shannon, bits/byte) detects whether uploaded data is actually encrypted. If the measured entropy falls below a threshold (suspected unencrypted or weakly encrypted data), an anomaly event is raised. Other irregularities such as unusual sizes or token misuse feed into the same analysis.

7. Network segmentation & controlled egress

The zones are divided into separate, private network segments. Outbound traffic is tightly controlled: required external sources are only provided through a controlled intermediary bound to the zone-private network, and internet egress runs through a dedicated exit node. The externally visible attack surface stays minimal.

8. Encrypted transport & replication

All transport is encrypted: transfers between client and storage endpoint use HTTPS/TLS, cross-zone control traffic uses strongly encrypted, mutually authenticated connections. Inside the storage system, the per-file encapsulated data key is additionally wrapped server-side – your content itself remains unreadable in any case thanks to client-side encryption.

This page describes the current state of the architecture. Binding, contractually guaranteed statements follow from the TOMs, the service description and the respective contract (German).