Who holds your backup encryption key?

Every encrypted backup has a key, and somebody holds it. Most owners have never been told who.

That matters in two directions. A key that is too easy to reach lets the wrong person read your data. A key that is too hard to reach, or held by one person who has since left, can make a perfectly good backup impossible to restore. This article explains the choice, and how to keep a key safe and findable at the same time.

What encryption does, and does not

Encryption turns data into something unreadable without the key. Backups are usually encrypted twice over:

• In transit: while data travels from your office to storage, using TLS, the same protection your browser uses for online banking.
• At rest: while it sits in storage, typically with AES-256, so a stolen disk or a leaked storage account shows only scrambled data.

CISA’s #StopRansomware Guide tells organizations to “maintain offline, encrypted backups of critical data.” Encryption is the part of that advice that stops someone from reading your copies.

Encryption does not stop someone from deleting or scrambling a backup they can reach. That is a separate protection, covered in immutable backups, explained without jargon. Good backups need both.

Provider-held or customer-held

Provider-held key. The backup service stores and manages the key. It can restore your data without asking you for anything, which is fast and forgiving. The trade-off is trust: in principle, the provider could read your data, so what matters is how it controls that ability.

Customer-held key. You set the key or passphrase, and the provider never sees it. Nobody at the provider can read your data. The trade-off is total: if you lose the key, nobody can restore your data, including the provider.

	Provider holds the key	You hold the key
Who can read the data	The provider, under its own controls	Only someone with your key
Who can start a restore	The provider, on your request	Only with your key supplied
If the key is lost	The provider still has it	The backup cannot be read
What you must do	Check the provider’s controls	Store, share and test the key

At Ezbre, clients can hold their own key on Server Backup and Immutable Offsite Copy. Where we hold it, every engineer passes a background check and works under a written confidentiality agreement, and access to client data is logged and requires two-factor sign-in. How we protect your data sets out the full picture, including what we do not claim.

Questions that decide it

There is no universally right answer. These questions usually settle it:

• Do your clients, contracts or regulators expect that your backup provider cannot read your data? Your counsel or compliance officer decides that, not your IT provider.
• Do you have at least two people who can be trusted with the key for years, not months?
• Will one of them be reachable on the worst day, at the worst hour?
• What happens to the key when one of them leaves?

If the first answer is yes and the rest are solid, hold the key yourself. If the second or third answer is shaky, a provider-held key with strong controls may be the safer choice in practice.

Where to keep your key

Holding your own key is a small, permanent responsibility. A few rules keep it manageable:

• Two copies, two places. For example, one in the company’s business password manager, shared with two named roles, and one printed and sealed in a safe or a bank safe-deposit box away from the office.
• Never only in one person’s head, or in one person’s private password manager.
• Never on the server it protects. If the server fails, the key fails with it.
• Never in email. Mailboxes are searched, forwarded and breached.
• Write down where it is, not what it is. Your recovery runbook should name the vault and the entry. It should not contain the key.
• Test it. Use the stored copy, not someone’s memory, during every restore drill.

A word on the key itself. If it is a passphrase you choose, make it long: several unrelated words beat a short string of symbols, and it is easier to type correctly under pressure. Write the printed copy exactly, with capitals and spaces as they are, and have a second person check it against the vault copy before it is sealed. A typo in the only printed copy is a quiet way to lose a backup.

On our plans, we help you store the key in two safe places and use the stored copy in each quarterly drill, so you know it works before the day you need it.

When someone with the key leaves

A key that a former employee or contractor knows is not a disaster, but it is a loose end. Decide what to do with it on purpose.

• Remove their access to the vault on their last day, along with every other account.
• Decide whether to change the key. On many backup systems a new key applies only to new backups, while older copies still need the old key. If you change it, keep both until the older copies have expired.
• Update the runbook so it names the new holders and the new vault entry.
• Test the stored copy in the next drill, so a mistake during the change is found early.

If your provider holds it

If you leave the key with your provider, ask these before you sign:

• Who at the provider can use the key to open our data, and under what approval?
• Is every access logged, and can we see the log on request?
• Do engineers need two-factor sign-in to reach client data?
• What happens to the key and our copies when we leave?

Clear, written answers are a good sign. Vague ones are worth a second question.

Example: the contractor who kept the key

Take a 35-person food distributor. Several years ago an outside IT contractor set up its server backups with a customer-held key, which was the right call for its contracts. He kept the key in his own password manager. Last spring he retired and closed his business.

In the autumn, the distributor’s order server fails. The nightly backups are all there, complete and intact. Nobody at the company has the key, and without it the copies are unreadable to everyone, including the backup provider. The outcome now depends on whether a retired contractor answers his email.

Run the same story with a key plan. When the backup was set up, the key went into the company’s password manager under two roles, the office manager and the finance lead, and a sealed printed copy went into the bank box. The contractor’s offboarding list included one line: confirm key custody. Every quarterly drill used the stored copy. When the server fails, the office manager opens the vault, the restore starts, and the contractor’s retirement never comes up.

A key custody checklist

• Who holds the key today? Name the role as well as the person.
• Where are the two copies, and who can reach each one?
• How quickly can someone reach a copy at night or on a weekend?
• When was the stored copy last used in a real restore?
• Is “confirm key custody” on the offboarding list for IT staff and contractors?
• Does the runbook say where the key is, without containing it?
• If your provider holds the key, how is access logged, and can you see the log?

Plans with a key you hold

On the Server Backup plan and the Immutable Offsite Copy plan, you can choose to hold your own key, with the trade-off above in writing before you decide. If terms such as immutable or air gap are new, the backup and recovery glossary defines them in a line or two.

A calm next step

If you are not sure who holds the key to your current backups, it is a good question to answer this month. The free backup check covers it in 45 minutes, remotely, along with one test restore and a written page of findings. Book a free backup check when it suits you.