What happens if your cloud provider gets hacked?

The honest framing No provider can guarantee that it will never be breached. What it can guarantee — through architecture — is what an attacker would find if a breach happened.

In a traditional cloud Servers hold the keys to data at rest. A successful breach of the right systems can expose plaintext files, search indexes, previews and metadata. The blast radius is large.

In a zero-knowledge cloud Servers hold ciphertext and wrapped keys that can only be opened by the user's password-derived master key. A breach exposes ciphertext, not content. The blast radius is small.

What this means for your decision - For files you would not mind seeing in a leaked dataset, either model is acceptable. - For files you would mind, the architectural posture of the provider is the most important variable — more important than badges, certifications or marketing.

How DRIVUNO is designed for this case DRIVUNO assumes that breaches are possible and designs around that assumption: no server-side decryption path, minimised metadata, audited primitives, and explicit threat-model documentation.

The breach math If a provider holds the keys, a breach of the provider potentially exposes every file they store. Encryption at rest helps against a stolen disk, not against an attacker inside the control plane. History — from large enterprise leaks to single-user account takeovers — keeps proving this.

What a breach of a zero-knowledge provider looks like Stolen ciphertext, stolen wrapped keys, stolen metadata. None of it is decryptable without the user's password (Argon2id-derived) or the user's recovery key. The attacker walks away with opaque bytes — which is the point.

Why DRIVUNO uses defence in depth anyway Strong KDF parameters, audited primitives, recipient-specific key wrapping, revocation, view-once, and explicit metadata minimisation. Architecture first, hardening on top.