News
Who can read your backups?
Most backup services promise your data is encrypted, but almost none of them say who can decrypt it — and in most cases, the answer is "we can." This plain-English guide explains the real difference between encryption in transit, at rest, and client-side, when each is good enough, and the questions and tests that reveal what a vendor actually does.
A plain-English guide to encryption at rest, in transit, and client-side
Almost every backup service says your data is encrypted. Almost none of them say who can decrypt it. That second question is the one that matters, and it is the one this guide answers.
Here is the uncomfortable truth behind most "encrypted backup" marketing: the provider holds the key. Your files are scrambled on their disks, but their systems can unscramble them at any time. That protects you from a thief walking off with a hard drive. It does not protect you from the provider, its staff, its subcontractors, a breach of its systems, or a legal order served on it.
None of that is dishonest. Encryption really is happening. But "encrypted" has quietly come to describe three very different arrangements, and only one of them means that nobody but you can read your backups. This guide explains all three in plain language, tells you when each is good enough, and shows you how to check what a vendor actually does rather than what its landing page implies.
The only question that matters: who holds the key?
Encryption is a lock. Like any lock, it keeps out exactly the people who do not have the key, and nobody else. So the strength of the cipher, the length of the key, and the certifications on the wall all come second to a simpler question: who can produce the key?
Think of it as a safe-deposit box. In one bank, the staff keep a master key and can open your box whenever policy, a court, or a rogue employee decides they should. In another, the box only opens with a key you brought from home, and the bank has never seen it. Both banks will truthfully say your valuables are locked up. Only one can truthfully say it cannot look inside.
Backup encryption works the same way. The three models below differ mainly in where the key lives:
In transit: the key exists only for the duration of the connection, shared between your device and the provider's server.
At rest: the provider generates and stores the key, usually in a key-management service it operates.
Client-side: you generate the key (or derive it from a passphrase), and the provider never receives it.
Everything else in this guide follows from that distinction.
Encryption in transit
Encryption in transit protects your data while it travels over the network. It is the padlock icon in your browser: TLS (the successor to SSL) wraps the connection so that anyone sitting between you and the server sees only scrambled traffic.
What it protects against: someone on the same coffee-shop Wi-Fi, a compromised router, an internet provider that logs traffic, or anyone else who can watch packets go by.
What it does not protect against: anything that happens once the data arrives. The connection is decrypted at the server. From that moment on, your files are plaintext as far as the provider is concerned, unless another layer of encryption is applied afterwards.
In 2026 encryption in transit is table stakes. Every serious service has it, and a vendor that lists "encrypted in transit" as a feature is describing the road, not the destination. If this is the only encryption a backup product mentions, assume your data sits readable on the provider's storage.
Encryption at rest
Encryption at rest means the data is scrambled while it sits on disk. When a vendor advertises "AES-256 encrypted storage" without further qualification, this is almost always what it means: the provider encrypts your files after receiving them, using keys the provider generates and manages.
What it protects against: physical theft or improper disposal of drives, a data-centre technician with hardware access, and some classes of low-level infrastructure compromise. It also satisfies a lot of compliance checklists, which is a large part of why it is universal.
What it does not protect against: the provider itself. Its software decrypts your data routinely, because it has to in order to serve it back to you. That means the same access is available to its engineers, its support staff, any attacker who compromises its application or key-management systems, and any government or litigant who compels it. The provider may have excellent controls around that access. But "we could read it, and we have rules about when we do" is a fundamentally different promise from "we cannot read it."
A useful mental check: if you forget your password and the provider can reset it and hand your files back, the provider holds the key. Convenient recovery and provider-side key custody are the same feature seen from two angles.
Client-side encryption
Client-side encryption moves the lock to your side of the wire. Your device encrypts each file before it leaves, using a key derived from a passphrase you chose or a key file you keep. What the provider receives, stores, and serves back is ciphertext it has no way to open. You will also see this called end-to-end, zero-knowledge, or customer-managed-key encryption; the terms vary slightly, but the idea is the same.
What it protects against: everything the previous two models cover, plus the provider itself. A breach of the provider's storage or application yields unreadable blobs. A subpoena to the provider yields the same. A curious employee gets nothing. The storage layer becomes untrusted by design, which means you can put your backups on any cloud, any object store, or a friend's server without extending your trust to whoever runs it.
What it does not protect against: losing the key. This is the model's defining trade-off. There is no reset link, because the whole point is that no one else can produce the key. If your passphrase is gone, the backup is gone. It also does not protect the device doing the encrypting: malware on your own machine can read files before they are encrypted, and a weak passphrase can be guessed offline.
Client-side encryption also changes what "the provider" can do for you. Features that require reading your data on the server — full-text search across backups, previewing files in a web console, deduplicating across many customers — either move to the client, become impossible, or require you to hand over the key and give up the guarantee. A vendor that offers both zero-knowledge encryption and server-side file previews is offering one or the other, not both.
When each model is acceptable
The honest answer is that provider-held keys are fine for a lot of data, and the right model depends on what you are backing up and whom you are worried about.
Model | Key held by | Protects against | Fails against | Good enough when |
|---|---|---|---|---|
In transit only | Nobody after arrival | Eavesdropping on the network | Anyone with access to the provider's storage | Never, for backups; treat as a baseline, not a feature |
At rest (provider key) | The provider | Stolen drives, hardware-level access, most compliance checklists | Provider breach, insider access, legal compulsion | Data you would be comfortable emailing to the provider; low-sensitivity or already-public content |
Client-side (your key) | You | All of the above plus the provider itself | You losing the key; malware on your own device | Anything you would not want a stranger to read: customer records, financials, source code, health data, personal files |
A few situations tip the decision firmly toward client-side encryption:
You are subject to regulation. GDPR, HIPAA, and similar regimes treat data the processor cannot read very differently from data it can. Client-side encryption can shrink your compliance surface considerably, because a breach of unreadable ciphertext is often not a reportable breach of personal data.
You are backing up other people's data. If clients, patients, or users trusted you with it, extending that trust to a third party's key-management team is a decision you should make deliberately, not by default.
You cannot vet the storage provider. Cheap object storage is excellent value precisely because you are not paying for a trust relationship. Client-side encryption lets you use it anyway.
The data has a long shelf life. Backups outlive the security posture of the company holding them. A key the provider holds today is a key an acquirer, a bankrupt estate, or a future policy change holds tomorrow.
And a few situations where provider-held keys are a reasonable choice:
The data is not sensitive, or is already public.
You genuinely need server-side features such as web previews or cross-account deduplication, and have decided the convenience is worth the exposure.
Your organisation has no reliable way to keep a passphrase safe, and a lost key would be worse than a readable backup. This is a real constraint for some small teams, and it is better to acknowledge it than to lock yourself out.
Whichever model you choose, choose it on purpose.
How to verify a vendor's claim
Marketing pages are written to sound reassuring, not to be precise. The way through is to ask questions that only have one honest answer, and to run a couple of tests that do not depend on the vendor's answers at all.
Questions that expose key custody
If I forget my passphrase, can you recover my data? "Yes" means the provider holds the key. This one question settles most cases.
Where is the key generated, and does it ever leave my device? A client-side model generates it locally and never transmits it. Watch for phrasing like "keys are stored securely in our KMS": secure, yes, but theirs.
Can your support staff see file names or contents while helping me? If support can browse your backup set, so can the software, so can an attacker.
How do you respond to a legal request for my data? A provider that cannot read your data will say it can only hand over ciphertext. One that can will describe its review process instead.
Is the encryption format documented, and can I decrypt a backup without your service? Open, documented formats mean the claim can be checked and your data is not hostage to the vendor's survival. A proprietary format you cannot open independently is a claim you have to take on faith.
Tests that do not need the vendor's cooperation
Watch the wire. Back up a small file with a distinctive, made-up phrase in it. Capture the outgoing traffic, or inspect the object that lands in your storage bucket. If you can find the phrase, or the file name, in what left your machine, it was not encrypted client-side.
Try the wrong-key restore. Set up the client on a second machine with a different passphrase and point it at the same backup. It should fail completely, not partially, and the provider should be unable to help.
Check the storage directly. With client-side encryption you can usually see the raw objects in your own cloud bucket. They should be opaque blobs with meaningless names. If you see your directory structure reproduced, only the file contents are protected at best.
Read the security whitepaper, not the feature page. Look for the sentence that says what the provider can and cannot access. If the document describes key rotation, HSMs, and access logging in detail but never says the provider cannot decrypt your data, that omission is the answer.
Phrases to translate
What the page says | What it usually means |
|---|---|
"Bank-grade / military-grade AES-256 encryption" | Encrypted at rest with provider-held keys; the cipher name says nothing about who holds the key |
"Encrypted in transit and at rest" | Standard cloud hosting; the provider can read your data |
"Your data is protected with your password" | Ambiguous; ask question 1 above |
"Zero-knowledge" / "end-to-end encrypted" | Should mean client-side; verify with the wire test, as the term is sometimes stretched |
"Customer-managed keys" | Often means you manage a key inside the provider's key service, which the provider's software still uses on your behalf; ask where decryption happens |
"We cannot access your data, even if we wanted to" | The claim you are looking for; still worth one test |
What we think a backup should promise
A backup exists to be the copy you can trust when everything else has gone wrong. It is hard to square that with a design where a third party can read it, and where the list of people who might read it grows every time that third party is breached, acquired, or served with a court order.
Our view is simple: the software that makes your backup should encrypt it before it leaves your machine, with a key only you hold, in a format you can open without anyone's permission. The storage underneath should not need to be trusted, because it should never see anything but ciphertext. That is the model we build, and it is the one we choose for our own data.
It comes with a responsibility that provider-held keys let you skip: you have to keep the passphrase safe. Write it down and store it somewhere physical, put it in a password manager with a recovery plan, and test a restore on a clean machine once in a while. That is a small discipline in exchange for being able to answer, without caveats, the question this guide started with.
Who can read your backups? Only you.
