Encrypted cloud storage and what breaks

“Encrypted cloud storage” gets used as a single label for two very different products. That’s the first thing worth untangling, because the difference decides who can actually see your files, and it’s rarely spelled out clearly on a pricing page.

Two products wearing the same label

Most mainstream cloud storage encrypts your files “at rest” and “in transit.” At rest means the data sitting on the provider’s disks is scrambled, not sitting there as plain files. In transit means the connection between your device and their servers is encrypted, usually with TLS, the same protocol that secures normal web traffic. This is genuinely useful. It stops someone who steals a hard drive from a data center, or someone snooping on the network between you and the server, from reading your files. But the provider holds the encryption keys. They generate them, they store them, and they use them to decrypt your files whenever you log in and pull one down. That means the provider itself, or anyone who compels the provider to hand over data, can read the contents.

The other category is often called client-side encryption or end-to-end encryption. Here, the encryption and decryption happen on your device, using a key derived from something only you know, typically your password. The provider only ever receives and stores already-encrypted data. They cannot decrypt it even if they wanted to, because they never had the key. This is a real architectural difference, not a marketing distinction, and it changes what a data breach or a legal order can actually expose.

Neither model makes you anonymous or untraceable. Both still know your account exists, your IP address at login, roughly how much data you’re storing, and often when you access it. Encryption protects content. It doesn’t erase your relationship with the service.

Where the key lives is the whole story

With client-side encryption, the key usually comes from your password run through a key derivation function, something designed to be slow to compute so brute-forcing it is expensive. If your password is weak or reused, that slowness doesn’t help much, because an attacker who already has your password from some other breach doesn’t need to guess it here.

The harder question is what happens when you forget your password. If the provider can help you recover access to your files, that means they have some way to get back to your key, whether through a recovery key they hold, a backup mechanism, or some other escrow. If they genuinely can’t help you recover anything, forgetting your password means losing your data permanently. There’s no way around this tradeoff. A “we can always help you get back in” support policy and “we never have access to your keys” are mutually exclusive claims. If a service offers both, one of them isn’t accurate, and it’s worth reading their documentation on key recovery specifically rather than trusting the word “encrypted” on its own.

The metadata that slips through anyway

Even a well-built end-to-end encrypted system usually leaves some information unencrypted, because the service needs it to function. File sizes are a common one. Folder structure and the number of items in a folder are often visible. Timestamps of when files were created, modified, or accessed are frequently stored in the clear. Some services encrypt file names and some don’t, since search and preview features are easier to build when the server can see them.

None of this reveals content. But metadata alone has told researchers and investigators a lot in other contexts, things like activity patterns, relationship structures between accounts that share folders, or rough estimates of what kind of data is involved based on file size and type. If your threat model includes someone who cares about your patterns and not just your file contents, it’s worth checking what a specific provider actually encrypts versus what they leave as plaintext metadata, because this varies a lot between services and isn’t always documented up front.

The device is the real perimeter

This is the part people skip past. Encryption in the cloud protects data while it’s sitting on someone else’s server. It does nothing once the file is open on your laptop or phone, because at that point it has to be decrypted to be usable. If your device has malware that can read your screen or your files, or if someone has physical access to an unlocked device, the cloud encryption is irrelevant. The file is sitting there in plain form because you’re looking at it.

Sync clients make this more concrete. A desktop sync app for an encrypted cloud service typically keeps a decrypted working copy of your files on your local disk, so you can open them normally. That local copy usually isn’t extra-protected beyond whatever disk encryption your operating system provides. It may also get picked up by things you didn’t think about: OS-level search indexing, thumbnail caches, automatic local backup tools, or a spare copy that syncs to a second device you forgot about. Web-based access to an encrypted vault has its own wrinkle too, since decrypting a file in a browser means the key has to be handled by JavaScript running on a page you’re trusting the provider to serve honestly.

None of this is an argument against encrypted cloud storage. It’s the argument for treating the cloud layer and the device layer as two separate problems that both need attention.

Sharing is where end-to-end encryption tends to bend the most. To share a file with someone, the system usually needs to give them a way to decrypt it, which means generating a shareable link with the decryption key embedded, or re-encrypting the file with a key the recipient can access. A link with the key baked into it is only as protected as that link. If it ends up in a chat log, an email that gets forwarded, or a browser history on a shared computer, the protection the encryption gave you upstream doesn’t apply downstream. And once you share with another person, you’re also trusting their password hygiene and their device security, not just your own.

Some services address this with expiring links or download limits, which help but don’t change the underlying fact: the moment something is shared, control of it partially leaves your hands.

Recovery and backups can quietly undo the point

A recovery key or a printed backup code is often the single point of failure in an otherwise solid setup. If you store that recovery code in another cloud service, a photo library, or a note-taking app that isn’t itself end-to-end encrypted, you’ve effectively copied your master key somewhere with a weaker security model than the one you were trying to build.

The same applies to backups of the encrypted storage itself. If a local backup tool copies your synced folder to an external drive or a NAS in unencrypted form, because it’s backing up the decrypted working copy rather than the encrypted blobs, you’ve created a second unprotected copy of everything. Backup software usually isn’t thinking about your cloud provider’s encryption model, it’s just copying files, so this is easy to miss.

What this actually buys you

Used with a realistic threat model, encrypted cloud storage is a solid tool against a specific set of risks: a data breach at the provider exposing readable files, an insider at the company browsing your data, and casual access by anyone who gets hold of the storage without your key. It’s not a tool against a compromised device, a weak or reused password, careless sharing, or an unencrypted backup sitting somewhere else. No single service or setting closes all of those gaps at once, and being clear about which risk you’re actually addressing is more useful than trusting a label on a homepage.

If you want more explainers like this that stick to how things actually work instead of how they’re marketed, you can find the rest of our writing on the homepage.