Why Encryption at Rest Does Not Protect Your Files

Encryption

Security

Educational

Zero-knowledge

7 min read

By Simon Themiot - freelance cybersecurity consultant. Published May 19, 2026.

Summary

Encryption at rest protects storage media, backups, and snapshots against some direct access. It creates no barrier against a provider that also manages the keys, or against a compromise that reaches both the application and key service.
When a service says "your files are encrypted", ask: who holds the key? If it is the provider, they can read your files.
End-to-end encryption (E2E) adds an essential separation: the server stores encrypted content without receiving the key required to read it.

1. The 3 levels of encryption
2. What encryption at rest does not protect
3. Concrete examples of leaks despite encryption at rest
4. The fundamental difference of end-to-end encryption
5. How to verify a service is truly E2E
6. FAQ

1. The 3 levels of encryption in cloud services

When a file sharing service announces your data is "encrypted", it can mean three very different things:

Level 1: Encryption in transit (TLS)

Your files are protected during transit between your browser and the server (HTTPS / TLS 1.2+). This is the absolute minimum in 2026 - every serious website uses it. This does not protect files once they reach the server. Analogy: an armoured van delivering your parcel, but dropping it off in an unsecured warehouse.

Level 2: Encryption at rest (server-side)

The server encrypts files after receiving them, using provider-managed keys. This protects disks, backups, and snapshots against some direct access. By itself, it does not protect against: authorised application access, a sufficiently privileged administrator, a valid legal demand, or a compromise of both the application and keys. Analogy: your parcel is in a vault, but the operator holds the key.

Level 3: End-to-end encryption (E2E / zero-knowledge)

Your browser encrypts the file before upload. The key reaches the recipient without passing through the server, for example in the link fragment. The server receives only ciphertext. This separation protects already-stored content when server storage alone is compromised; it does not protect a compromised endpoint or malicious JavaScript served during a future transfer.

2. What encryption at rest does not protect

Most mainstream services provide encryption at rest, including WeTransfer, Dropbox, Google Drive, OneDrive, and SwissTransfer. When the provider manages the keys, this layer does not cover several important scenarios:

Malicious or negligent employee: A sufficiently privileged administrator may be able to access content through the application or key service.
Legal compulsion: A provider facing a valid demand can disclose content when it is technically able to decrypt it. Jurisdiction and applicable safeguards require case-by-case analysis.
Infrastructure compromise: If a hacker takes control of the server (via an application flaw, compromised SSH access, supply chain attack), they have access to keys and therefore to decrypted files.
Misconfiguration: A misconfigured S3 bucket, an unencrypted backup, a log that exposes keys - all documented vectors that bypass encryption at rest.
Sub-processor access: Cloud providers often use sub-processors (CDN, monitoring, backup) that may have access to plaintext data or keys.

The fundamental question

When a service says "your files are AES-256 encrypted", ask one structural question: "Who can use the decryption key?" If it is the provider, encryption at rest remains useful, but does not technically prevent provider access to the content.

3. Leak scenarios despite encryption at rest

Encryption at rest can be bypassed without breaking AES. Typical scenarios include:

Stolen application credentials: the attacker uses the legitimate API, which decrypts objects with the service's permissions.
Overly broad cloud role: a compromised identity can both read objects and invoke the KMS key.
Misconfigured bucket or link: storage encrypts bytes but transparently returns them to an identity authorised by mistake.
Secondary backup or export: a copy may escape the encryption, key-management, or retention policy of primary storage.

The common thread is that the attacker bypasses encryption through a path the service already trusts. AES strength is not the issue; the trust boundary is.

4. The fundamental difference of end-to-end encryption

End-to-end encryption (E2E) solves the problem at its root: the encryption key only exists on the sender's and recipient's machines. The server never sees it, never stores it, can never reconstruct it.

Concretely, on an E2E service like PrivCloud:

Your browser generates a random 256-bit AES-256-GCM key.
The file is encrypted locally in the browser with this key via the Web Crypto API.
Only the encrypted (unreadable) blob is sent to the server.
The key is placed in the URL fragment (after #), which is never sent to the server by HTTP design.
The recipient opens the link: their browser extracts the key from the fragment and decrypts the file locally.

Result: compromise of storage alone exposes AES-256-GCM blobs without their random 256-bit key, for which exhaustive search is impractical. The model still does not cover a compromised endpoint or malicious JavaScript served at transfer time.

5. How to verify a service is truly E2E

Here are the concrete indicators to verify if a file transfer service offers real end-to-end encryption:

The key is in the URL fragment: Look at the sharing link. If it contains a long string after a #, that is a good sign. The URL fragment is never sent to the server by the browser.
The source code is open: You can verify in the code that encryption happens client-side. With proprietary code, you must take their word for it.
The browser Network tab confirms it: If you open developer tools and observe network traffic during upload, the sent file must be an encrypted blob, not the plaintext file.
Technical documentation explains it: A serious service publishes a threat model and whitepaper explaining the cryptographic implementation.

6. FAQ

Is encryption at rest completely useless?

No. It protects against physical disk theft and is a good baseline practice. It is one defense layer among others. But it alone is not enough to protect sensitive files against the most common 2026 threats (infrastructure compromise, legal compulsion, misconfigurations). It should be combined with E2E for sensitive data.

Are Google Drive, Dropbox, OneDrive all in the same situation?

Their default offerings generally rely on provider-managed keys, but some options alter the scope, such as Apple's Advanced Data Protection. Check the exact product, plan, enabled features, and recovery procedures rather than reasoning by brand alone.

Does E2E encryption have drawbacks?

For link sharing, losing the fragment can make content unrecoverable. Encryption also adds CPU work, memory copies, and recovery constraints. Streaming and Web Workers reduce these costs, but cannot guarantee zero impact on every browser and device.

Browser encryption explained: how E2E really works Zero-knowledge: what it really means for your files How to send sensitive files compliant with GDPR