Every backup vendor 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 most product pages are written to avoid.

"Encrypted at rest and in transit" is table stakes. It usually means the vendor encrypts your data with a key the vendor holds, on servers the vendor runs. That protects you from a stolen hard drive. It does not protect you from the vendor's support staff, a compromised admin account, a misconfigured bucket, or a court order served on the vendor rather than on you.

"Zero-knowledge" (also called client-side or end-to-end encryption) means the data is encrypted on your machine, with a key only you hold, before it leaves. The vendor stores ciphertext it cannot read. That is a different architecture, not a marketing tier, and it has real consequences for recovery, support, and compliance.

The five questions below separate the two. Ask them of any SaaS backup vendor, including us. A vendor with a good answer will give it in writing; a vendor with a bad one will talk about certifications instead.

1. Who holds the encryption key?

This is the whole question. Everything else follows from the answer.

Ask: Can anyone at your company, with any level of access, decrypt my backup data without my passphrase? The honest answers fall into three groups.

The third row is the only one where the vendor's security is not your security. It is also the only one where the vendor cannot help you if you lose the key. Any vendor offering it should say both things plainly.

Follow-up questions that expose the fine print:

• Is client-side encryption the default, or an option most customers never turn on?

• Is the encryption done by open, auditable code, or by a closed agent you have to trust?

• Which algorithm, and is it a standard one (AES-256, GPG) rather than something proprietary?

• If I use your managed or "we handle it for you" tier, does the key move to your side? Many vendors quietly switch models between tiers.

• Can I restore my data with a tool that does not depend on your service existing?

The last one is underrated. If the vendor goes out of business, gets acquired, or suspends your account, a customer-held key is only useful if there is also a client that can read the backup format without the vendor's servers.

2. Can your support staff see my file names?

File contents are only half the story. The other half is metadata: file names, folder paths, sizes, timestamps, which machines back up what, and when. For most organisations, a folder tree is nearly as sensitive as the files inside it. /Clients/Acme/Litigation/2026-settlement-draft.docx tells a reader most of what they want to know without opening it.

Metadata leaks in two places that "encrypted" rarely covers:

1. The backup archive itself. Some vendors encrypt file contents but store the file list, or a searchable index, in the clear so their web console can show you a browsable tree. Ask whether the index is encrypted with the same customer-held key as the data.

2. The management console and logs. Even with a fully encrypted archive, the backup agent reports status back to the vendor: what ran, what failed, which files errored. A log line like Access denied: C:\HR\Terminations\... has just sent that path to the vendor in plain text.

Ask:

• Can a support engineer, from your admin tools, see my file or folder names? Under any circumstances, including when I open a support ticket?

• Are file paths removed or hashed before log lines and reports leave my machine?

• Does your admin "impersonation" or "view as customer" feature exist, and if so, exactly what does it expose? Is its use audit-logged?

• Can your staff initiate a remote session to my backup agent without my action?

• Is there a mode that reduces what the agent reports to your servers, at the cost of less detailed diagnostics?

A vendor that has thought about this will have a precise answer, often with a list of what the console does hold (job names, byte counts, error codes) and what it never holds (paths, content). A vendor that has not will say "our staff are trained and background-checked," which answers a different question.

3. What happens under a subpoena?

The cleanest test of an encryption claim is a legal one. Ask the vendor: If you receive a valid court order or subpoena for my backup data, what are you technically able to hand over?

With vendor-held keys, the answer is "everything." The vendor may push back, may notify you, may have a published transparency report, but when the order is upheld, the data is readable and it goes. Your lawyers never get a chance to argue, because the request was served on someone else.

With customer-held keys, the answer is "ciphertext and whatever metadata we store." The vendor cannot decrypt what it does not have the key for, so the request has to come to you, where you can contest it on your own terms. This is not the vendor being heroic. It is the vendor being unable, which is far more reliable than willing.

The same logic applies to breaches, insider threats, and government access requests outside the courts. In every case, the question is not whether the vendor would expose your data but whether it could.

Ask:

• What is the complete list of things you could produce about me in response to a legal order?

• Do you have a policy of notifying customers before complying, where legally permitted?

• Which jurisdictions can compel you? Where is your company incorporated, and where is the data physically stored? These are often different.

• If I bring my own storage (my own S3 bucket, my own data centre), is there anything of mine on your servers at all for an order to reach?

That last option, bringing your own storage, is the most defensible position available. If the ciphertext sits in your account with your cloud provider, and the key sits on your machines, the backup vendor holds nothing worth subpoenaing.

4. What is persisted on your servers?

"We don't store your data" is never literally true for a SaaS product. The useful question is: what, exactly, do you keep, for how long, and in what form? Ask for the list and expect something like this.

Two items on that list deserve special attention.

Storage credentials. If the vendor stores the credentials to your backup destination, the vendor can read the ciphertext. Combined with a vendor-held encryption key, that is full access. Combined with a customer-held key, it is still a risk worth knowing about, since a stolen credential can delete your backups even if it cannot read them.

Transit relays. Many consoles can open a remote session to a backup agent behind a firewall, which means traffic passes through the vendor's servers. Ask whether that traffic is end-to-end encrypted between you and the agent, or whether the relay decrypts it in memory along the way. "Encrypted in transit" with TLS terminated at the relay is the latter.

Finally, ask about sub-processors. The vendor's own hosting provider, log platform, and support desk each see some slice of this data. A good vendor publishes the list and has data processing agreements, or where relevant business associate agreements, with every one of them.

5. What do I give up, and can I choose?

Zero-knowledge is not free, and a vendor that pretends otherwise is hiding something. The honest trade-offs:

• Lost key, lost data. No password reset, no recovery email. You need your own key management, and you need to test it.

• Less helpful support. If the vendor cannot see your file names or logs, troubleshooting is slower. Expect to be asked to run commands yourself.

• Fewer console features. Server-side search, content preview, and "restore any file from the web" all require the server to read your data. In a zero-knowledge design they either run on your machine or do not exist.

• Deduplication across customers is impossible. Each customer's ciphertext is unique, so the vendor cannot pool storage. This is sometimes why zero-knowledge tiers cost more per gigabyte.

None of these are reasons to avoid zero-knowledge. They are reasons to ask whether the vendor lets you choose the trade-off rather than choosing it for you.

Ask:

• Can I hold my own key for some backups and let you manage the key for others, with the difference clearly marked?

• Is there a confidential or reduced-telemetry mode I can turn on for an organization, and does it fail closed (rejecting agents that report too much) rather than merely asking them not to?

• If I enable managed features that require your side to hold a key, is that reversible, and can I export a restore-only key for an independent client?

The best position a vendor can be in is to offer both models, document precisely what each one exposes, and default to the one that exposes less.

The checklist

Paste this into your next vendor questionnaire. Each question has a short good answer; a long answer is usually a bad one.

• Can anyone at your company decrypt my backup data without my passphrase? Under any circumstances?

• Is client-side encryption the default or an opt-in?

• Is the backup format readable by an open, independent client if your service disappears?

• Can your support staff see my file names or folder paths, from any tool, including during a support ticket?

• Are paths and file names stripped from logs and reports before they leave my machine?

• Does admin impersonation exist? What does it expose, and is it audit-logged?

• Can your staff open a remote session to my agent without my action?

• What is the complete list of what you could produce in response to a subpoena?

• Where is my data stored, and where is your company incorporated?

• Can I use my own storage account so you hold no backup data at all?

• Do you store my storage credentials? For which tiers?

• Is remote-session traffic end-to-end encrypted, or decrypted at your relay?

• Which sub-processors see which data, and do you have DPAs (and BAAs where relevant) with each?

• Is there a reduced-telemetry or confidential mode, and does it fail closed?

• If I use a managed tier where you hold a key, can I export a restore-only key?

How Duplicati answers these

We wrote this list because we get asked these questions, so here are our answers in the same format. Hold us to them.

• Who holds the key? You do. Duplicati encrypts on your machine with AES-256 (or GPG) before anything is uploaded, and the client is open source, so the encryption code is auditable and the backups are restorable without our servers. The one exception is our fully managed backup tier, where the key is stored in the Console so we can run the backup for you; that tier is clearly marked, and you can export a restore-only key for the open-source client.

• Can support see file names? No. The agent redacts file paths before reports and logs are sent to the Console. Admin impersonation exists for troubleshooting, is audit-logged, and cannot start a remote session, obtain your storage keys, or read backup data; those limits are enforced in code, not policy.

• Subpoena? By default your backup data sits in your own storage account, and we hold neither the data nor the key. What we could produce is Console metadata: job names, schedules, byte counts, error codes, account and billing details.

• What is persisted? Console metadata as above. If you buy Duplicati-provided storage, it holds client-encrypted data only. Remote-session traffic is end-to-end encrypted; our relay forwards ciphertext it cannot read.

• Can I choose? Yes. A confidential organisation mode strips log strings down to error types and help IDs, disables Duplicati-held keys and managed runners, and rejects any agent that tries to report more. It is opt-in, because it removes features, and it is available to any customer.