Your Cloud Provider Can Read Your Files
By NorwegianSpark Editorial · Published August 8, 2026 — written with AI assistance and reviewed by the NorwegianSpark SA editorial team.
Every major cloud storage service says your files are encrypted. That is true, and it is not the reassurance it sounds like.
There are two very different arrangements hiding behind the same word, and the distinction decides whether the company holding your files can open them.
Two kinds of encryption
Provider-managed encryption. Your files are encrypted on the provider's servers, but the provider holds the keys. This protects against someone stealing the physical drives, and against interception in transit. It does not stop the provider itself reading your files, and it means a lawful demand, a rogue employee or a breach of their key infrastructure can expose them.
Zero-knowledge encryption. Files are encrypted on your device before upload, with a key derived from your password that never leaves your control. The provider stores data it cannot read. A court order produces ciphertext.
Both are honestly described as "encrypted". Only the second means the company cannot look.
The trade-offs of zero-knowledge
It is not strictly better, and pretending otherwise sets people up for a bad surprise.
If you lose the password, the data is gone. There is no reset, because there is no one holding a spare key. That is the entire point, and it is unforgiving.
Some features become impossible. Full-text search across your documents, server-side previews and thumbnails, in-browser editing, and easy link sharing all depend on the server being able to read the file. Zero-knowledge services either do without or do it locally, which is slower and more limited.
Collaboration is clunkier. Real-time co-editing is hard when the server cannot read the document.
It usually costs more per gigabyte and the apps are often less polished.
A practical split
Most people do not need everything encrypted to the same standard, and treating it as all-or-nothing leads to doing nothing.
The workable approach is to split by sensitivity. Keep the bulk — photos, general documents, things you would not mind a stranger seeing — on mainstream storage where the features and price are good. Put the genuinely sensitive material in a zero-knowledge service or an encrypted container.
That second group is smaller than people expect: identity documents, financial and tax records, medical information, legal correspondence, password and recovery keys, anything covering someone else's private life.
The container alternative
You do not necessarily need a different provider. An encrypted container — a file that behaves like a locked folder, using a well-regarded open-source tool — can sit inside your existing cloud storage.
The provider stores an opaque blob and syncs it like any other file. You mount it locally with your passphrase, work normally, and close it.
Trade-offs: the whole container re-syncs when it changes, which is wasteful for large ones, and simultaneous access from two devices risks conflicts. For a modest archive of sensitive documents that you touch occasionally, it works very well.
Before you rely on any of it
Two checks that catch the common disasters:
- Test a restore. Actually retrieve a file from a fresh device, with only the credentials you have stored. A backup you have never restored is an assumption.
- Store the recovery material somewhere else. With zero-knowledge encryption, your password is the data. Keeping it only in a password manager that itself lives in that storage is a loop that fails at the worst moment. A written copy in a physically secure place is unfashionable and effective.
What "the provider can read it" means in practice
The phrase sounds abstract, so it is worth being concrete about the four routes it actually opens.
Automated processing. Files are routinely scanned by the service itself — to generate previews, index text for search, sort photographs by content, and in many jurisdictions to detect illegal material. This is not sinister and much of it is why the product is useful. It does mean the content is processed, not sealed.
Lawful demands. A court order or equivalent instruction served on the provider is answered with your files, because the provider is able to answer it. With zero-knowledge encryption the same order is answered with data nobody can open. Whether you are ever subject to such an order is a separate question; the point is which answer is technically possible.
Employee access. Any organisation that can decrypt your data has staff who can, under some internal control. Those controls are usually decent. They are still controls rather than mathematics, and they have failed at large companies before.
A breach of their systems. If an intruder reaches both the encrypted data and the key infrastructure, your files are readable. Zero-knowledge storage means a breach yields ciphertext, which is the difference between an incident and a disaster.
Notice that none of these requires bad faith on the provider's part. They follow from the architecture, which is exactly why the architecture is the thing to look at rather than the privacy policy.
Questions to ask about your current provider
You can usually settle this without reading a whitepaper. Two questions decide it.
- If I forget my password, can you restore access to my files? If yes, they hold a key. That is not an accusation, it is arithmetic.
- Can I search the text inside my documents from the web interface? If yes, the server read them.
Then, if you want the detail:
- Is encryption applied on my device before upload, or on your servers after?
- Is there an optional zero-knowledge mode, which some mainstream services now offer for a subset of files, and what breaks when it is on?
- What happens to shared links? A file shared by public link is, by necessity, readable by the service delivering it.
- Where is the data stored and under whose law, which decides who can compel what.
The failure mode that quietly undoes it
Sharing is where zero-knowledge setups most often spring a leak, and it happens without any warning.
The moment a file is shared by a plain web link, something has to decrypt it to serve it to a browser. Depending on the implementation this may be handled in the recipient's browser with a key embedded in the link — which is genuinely end-to-end, but also means anyone with the link has the key, and links get forwarded and logged. Other implementations decrypt server-side, which removes the protection entirely for that file.
The second common leak is more mundane. Someone puts a sensitive document into an encrypted folder, then emails a copy to a colleague, then it sits in two mailboxes and a phone. The encrypted store was never the weak point.
The workable habit is to treat the encrypted area as somewhere files live rather than somewhere files pass through, and to accept that anything you need to share widely is, practically speaking, no longer protected by it.
The counter-argument, which is stronger than it sounds
There is a good case that most people should not use zero-knowledge storage for most things, and it is not about convenience.
The realistic way people lose files is not a provider reading them. It is losing a laptop with no backup, deleting something by accident, or forgetting a password. Mainstream providers are extremely good at those problems: version history, deleted-file recovery, account recovery, and support that can help when something goes wrong.
Zero-knowledge storage removes the last of those deliberately. For a household that has never successfully maintained a backup, moving everything into a system with no recovery path is a straightforward increase in the chance of losing the lot — and losing your photographs to a forgotten passphrase is a real harm, whereas a provider being technically able to read them is usually a theoretical one.
Which is why the split described above is the recommendation rather than a wholesale move. Mainstream storage for the bulk, where recoverability is the feature that matters. Zero-knowledge for the small set where confidentiality genuinely outranks recoverability — and only once you have proved to yourself that you can restore from it.
The one-line version
If your provider can reset your password and still give you your files, they can read your files. That may be an entirely acceptable trade for convenience — just make it knowingly, and keep the small set of genuinely sensitive material somewhere it does not apply.
Where this fits
Cloud storage is where most people's backups live, so read this alongside how to back up your data — and note that the offline copy recommended there is also what saves you from ransomware. The same "who holds the key" question applies to your conversations in encrypted messaging compared, and the reason a wiped device is safe comes from the same logic, explained in secure file deletion. Which providers and backup tools actually hold the key is part of our security tool shortlist.
Affiliate disclosure
This article contains affiliate links. If you purchase through them, CyberTechVault earns a commission at no extra cost to you. Our assessments are based on vendors' published documentation, independent lab results and security disclosures — not on hands-on testing by us. Affiliate relationships never decide what we recommend.
Full disclosure: /affiliate-disclosure.
Continue reading
privacy
There Is No Password Reset for a Crypto Wallet
Self-custody means no support line, no chargeback and no recovery. The seed phrase rules that matter, the scams that dominate losses, and the honest case for not self-custodying.
privacy
How to Share a Password Without Texting It
Households share streaming logins, banking access and Wi-Fi passwords constantly. The messy ways create permanent copies in places nobody controls. The tidy ways take no longer.
guides
EaseUS Todo Backup Review 2026: Ransomware Safety Net
An in-depth EaseUS Todo Backup review for 2026: why backup is your last defence against ransomware, who it suits, and how it fits your security plan.
