The backup password on the laptop you're backing up

Some links on this page are affiliate links: if you sign up or buy through them, Dacros may earn a commission, at no extra cost to you. We only recommend tools we use and rate. Full disclosure.

We recently sat down to audit our own infrastructure — the systems behind Dacros itself — the same way we audit a client’s. Over one week we found the same bug five times.

Not the same component. Five unrelated systems, built at different times, for different reasons. What they shared was a shape: each was a recovery control whose precondition was the thing it was designed to recover you from.

Every one of them passed its own tests. That’s the part worth writing about — because if it can happen to a firm that does this for a living, it is almost certainly sitting in your business too.

The shape of the bug

Recovery controls are conditional. A backup is useful given you can decrypt it. A standby provider is useful given you can reach them. A password manager is useful given you can get into it.

We are diligent about the first half of those sentences and careless about the second. We test that backups restore. We rarely test that the conditions for using them still hold in the scenario that produces the need.

The bug is that the condition and the failure are correlated. Not “this control might not work” — it works perfectly, every time you test it, in every situation except the one it exists for.

That’s a nastier property than simple brokenness. A broken control fails your tests. This one passes them, right up until the day it counts, and then fails completely.

Five instances

1. The backup password

Our off-site backups are encrypted, and the threat model is clean and the consequence is brutal: the repository password is the backup. Lose it and the data is cryptographically gone — not “difficult to recover”, gone.

Ours lived in a file on the laptop being backed up.

The loop: if the laptop dies, you need the backup. To read the backup, you need the password. The password was on the laptop.

Nobody decided this. It emerged. The password was generated on the machine where the backup was configured, written to a config file so the scheduled job could read it, and that was the end of it. Every individual step was correct. The composition wasn’t. (This is exactly why the 3-2-1 rule — three copies, two types of media, one off-site — has to include where the keys live, not just where the data lives.)

2. The single key to everything

One key opened every server we run — including the ones holding the backups. It existed in exactly one place: the same laptop, with no passphrase.

Same loop, one layer out. The backups were fine. Reaching the machines that held them required a key that only existed on the machine you’d just lost.

This one had an additional property worth noting: the fix is trivial and takes ninety seconds. Copy the key into the password manager. It had gone undone for over a year, not because it was hard, but because nothing ever asked.

3. The DNS provider account

This is the one that made us go looking properly.

We keep a standby DNS provider — a full replica of every zone — so that losing our primary doesn’t mean rebuilding everything from memory under pressure. Reasonable architecture. Tested. The replica served correct answers. (If “DNS” and “zones” are unfamiliar, our plain-English domain names and DNS basics for business explains what’s actually at stake here.)

Then we needed the standby provider to change something on our account, and they replied — entirely correctly — that they only action requests sent from the address registered to the account.

Our account address was on our own domain. Our own domain resolves through the primary DNS provider. So the sequence is:

1. The primary provider fails, or suspends the account, or the billing card expires.
2. Our domain stops resolving. Every mailbox on it stops receiving.
3. The standby provider will only take instructions from an address on that domain.
4. The provider that exists to recover you from losing the primary is only reachable through the primary.

We had built a perfect replica and no way to ask anyone to use it.

4. The registrar

Chasing that, we checked something we’d never thought to check: who our registrar is.

The whole standby-DNS design rests on one recovery step — if the primary fails, change the nameservers at the registrar to point at the standby. Minutes of work, and the data is already there.

Our registrar was the same company as our primary DNS provider. Same account.

So losing that one account takes DNS, the registrar and — because the mail domain resolves through it — the email you’d use to recover either. There is no nameserver change to make, because the control panel where you’d make it was inside the account that’s gone.

This is the instance we’d flag hardest to any business owner. Registrar consolidation is sold as convenience, and it’s genuinely cheaper. But your registrar is the escape hatch for your entire DNS estate. It must not be inside anything it rescues you from. That’s not a statement about any company’s reliability — it’s about correlation. Account suspension, billing disputes and credential compromise are account-level events, and they take everything in the account at once.

5. The recovery phrase

Having found the first four, we set about fixing the credential layer properly. Set up a recovery phrase for the account holding everything. Store it somewhere safe.

The first instinct was to store it in the password manager.

Which is inside the account that the recovery phrase recovers.

That got written down — as a recommendation, in a document — while we were actively hunting for this exact pattern, four instances into the week. It was caught on review, an hour later.

That’s the most useful data point in this whole post. Knowing about the pattern is not sufficient protection against it. The pull toward “store the secret in the secure place” is strong enough to override an explicit hunt for exactly this mistake. If it can happen mid-audit, it can certainly happen on an ordinary Tuesday.

Why all five passed their tests

Each of these controls was tested, and each test was passed:

• Backups restored correctly, byte-for-byte, from an independent provider.
• The server key authenticated to every machine.
• The DNS replica held every record and served correct answers under query.
• The registrar renewed domains on time, every time.
• The password manager was properly secured, with a strong password and two-factor authentication.

Testing a control asks: does this work?

All five did. The question that finds these bugs is different:

What must be true for this control to be usable — and is that thing still true in the scenario where I need it?

That’s not a test you can automate easily, because it’s a question about correlation between failure modes rather than about any single component’s behaviour. It’s closer to a proof obligation than a test case.

Why this pattern is so common

It isn’t carelessness. It’s structural, and there are three forces producing it.

Controls are built one at a time, and each one is locally correct. Storing a backup password in a config file so a scheduled job can read it is right. Keeping a key on the machine you work from is right. Registering domains where your DNS is saves money. Putting your account email on your company domain is obviously right. The bug is never in a step; it’s in the composition, and nobody reviews compositions.

Consolidation is actively encouraged. Every provider wants to be more of your stack, and there are real benefits — one bill, one login, lower cost. The industry’s word for this is “platform” and it’s positive. Nobody markets a service by pointing out that concentrating it increases the blast radius of an account-level failure.

The correlated-failure scenario is rare enough to never be rehearsed. Individual components fail often, so you build and test for that. Whole-account loss happens once a decade, so the recovery path for it is designed on paper, filed, and never walked. And it’s precisely in whole-account loss that these circular dependencies bind. It’s the same reason ransomware is so devastating to firms that “had backups” — the disaster and the dependency arrive together.

There’s a fourth force, softer but real: it feels paranoid. Deliberately keeping your registrar somewhere other than your DNS provider, for the sake of an event that probably won’t happen, looks like over-engineering — right up until you read someone’s post-mortem about the fortnight they spent recovering.

A taxonomy

Once you have the shape, it’s easier to spot. The five above are four distinct flavours:

Credential-in-the-vault-it-opens. The secret needed to recover a system is stored inside that system. Backup password on the backed-up machine. Recovery phrase in the password manager. Two-factor seeds stored in a vault that requires two-factor to open.

Access-through-the-failed-path. The channel used to invoke recovery depends on the failed component. Account email on a domain served by the failing DNS. A support portal behind the single sign-on you can’t reach. A phone-based reset to a number in a contacts app you can’t open.

Escape-hatch-inside-the-building. The mechanism that performs recovery lives within the failure domain. Registrar inside the DNS provider’s account. Runbooks in a wiki hosted on the server they describe. Break-glass credentials in a system behind the outage.

Watcher-sharing-fate. The thing that would tell you something failed shares its failure mode. Monitoring hosted on the infrastructure it monitors. A status page served from the servers whose status it reports. Backup alerts delivered by the mail system included in the backup.

That last one has a canonical version worth stating plainly: if your monitoring runs on the machine it watches, then “the machine died” produces silence, which is indistinguishable from “everything is fine.” Monitoring must be able to report the death of the thing it monitors, which means it cannot live there.

We hit this one too, deploying uptime monitoring in the same week. The dashboard runs on a server; if that server dies, the dashboard dies quietly and nothing complains. The fix is an outbound heartbeat to an external dead-man’s-switch — something elsewhere that shouts when the regular signal stops. Same principle as putting your backup verification on a different provider from your backups.

The rule

One line covers every instance:

An account or credential you would need because X broke must not depend on X.

The important word is because. It’s not “don’t depend on anything” — you can’t build that, and trying produces paralysis. It’s specifically about correlation between the failure that creates the need and the dependency that satisfies it.

Applied to provider accounts, this narrows to something surprisingly small. Work through your list and ask, for each: if this provider fails, does my recovery channel survive?

For most of them the answer is yes, trivially. Your cloud file storage going down doesn’t stop your mail arriving. Your accounting software, your booking system, your card processor — all of them can fail without touching the mailbox you’d use to recover them. Those can stay exactly where they are.

The ones that fail this test are the ones whose failure takes out your communications path — which in practice means DNS, the registrar, and your mail provider. For us that was three accounts.

That narrowing is not a detail; it’s the whole reason the fix gets done. A rule that touches every account you own becomes a project, projects get scheduled, and scheduled security work slips. Three accounts is an afternoon, and an afternoon happens.

Where those accounts should point

An address on a domain you don’t control the DNS for.

A Proton Mail, Fastmail or Gmail address — anything whose availability is somebody else’s problem, uncorrelated with your own infrastructure. It feels unprofessional to put a free-provider address on the account that holds your company’s domains. Do it anyway. It is the correct answer, and the alternative is an address that goes dark in precisely the scenario it exists for.

Two follow-ups that are easy to miss:

Check that account’s own recovery. If your Proton or Gmail recovery email points back at your company domain, you’ve rebuilt the loop one level up — and now it’s the level everything else hangs from. Recovery chains have to terminate somewhere independent, and it’s worth tracing yours to the end at least once.

Prefer the primary address over an alias. Additional addresses often depend on a paid tier. If a subscription lapses — expired card, a distracted month — you may drop to a plan that only supports the primary address, and any account pointing at an alias loses its recovery path at the same moment you’re already having a billing problem. For three accounts whose entire job is to work when everything else has failed, that property beats tidiness.

Emergency access: the part everyone gets wrong

Most serious password managers now offer emergency access — Proton Pass and the other major managers included. You nominate a trusted contact, they can request entry, a waiting period runs during which you’re notified and can decline, and if you don’t decline, they get in.

It is the single highest-leverage thing most people reading this haven’t configured. It takes five minutes and it’s usually free. Four things about it are non-obvious.

It is the only route in. These vaults are zero-knowledge — the provider genuinely cannot decrypt your data, which is the entire point and the reason you chose them. The consequence people don’t follow through: no legal instrument can compel what nobody holds. Without emergency access, an executor with perfect authority faces a vault that no court order and no cooperative support team can open.

The distinction to hold onto: emergency access grants access; a will grants authority. Both are required. Neither substitutes for the other. Split them across two different people and you get the worst of both — one can open the vault but has no standing to act, the other has standing and can’t get in.

The mechanism is pull, not push. Nothing detects that something has happened to you. There is no dead-man’s-switch, no inactivity timer in most implementations. Your contact has to log in and actively request access. Which means a contact who doesn’t know they’re a contact will never make that request. Tell them. Tell them where the instructions are, because they’ll be reading them on the worst day of their year.

Your contact needs an account with the same provider. The request is made from inside their account. Naming someone who can’t log in produces a control that looks green in your settings and cannot fire. A free account is usually enough — but check that they’ve actually created it.

Check the scope and the waiting period. Some grant access to the vault only; some to mail and files too. Thirty days is a long time for a business to sit still, and “no wait” removes the safeguard that lets you decline a request you didn’t expect. Something in the middle is usually right. This all belongs in the same conversation as your password policy and your choice of password manager — it’s the part of both that firms most often skip.

Where the recovery phrase goes

Not in the password manager — that’s instance five.

Not in a file on the laptop — that’s instance one wearing a different hat.

Not photographed. The photo syncs to a cloud account, which is now a third copy in a third system, each with its own credentials and its own failure modes. You have turned one secret into a distributed-systems problem.

Paper. Written by hand. Read back against the screen word by word before you close the window — a single mistranscribed word makes the whole thing worthless, and you find out at the exact moment you can least afford to. Stored somewhere physical: a safe, a sealed envelope with your emergency contact, a bank deposit box.

The phrase’s entire value is that it exists outside every system it can unlock. Paper isn’t a grudging compromise here. It’s the requirement, and it’s the one technology in your stack with no dependencies at all.

Then — and this is the step that gets skipped — write down where it is, in whatever document your successor will actually read. Not in the vault. In the letter, the runbook, the handover note. A recovery phrase nobody can locate is indistinguishable from no recovery phrase, and you will not be available to hint.

How to find these in your own business

There’s no scanner for this. The method is a question, asked deliberately, of each control in turn:

1. List your recovery controls. Backups, standby providers, replicas, break-glass logins, monitoring, alerting, runbooks, the password manager itself. Anything whose purpose is “for when something goes wrong.” Don’t forget the ones hiding in your cloud apps — Microsoft 365, for example, is not backed up unless you back it up.

2. For each, write down what it needs in order to be used. Not to exist — to be used, by a person, during an incident. A credential. A network path. A login. A device. An email that arrives. A document someone can find.

3. For each of those needs, ask whether it survives the failure this control addresses. This is the whole exercise and it takes about a minute per control.

4. Trace to the end. These chains are longer than they look. The backup needs a password, which is in the password manager, which needs a master password — in your head, fine — plus two-factor, which is on a phone, which you may have lost alongside the laptop. Follow it until you reach something genuinely independent, or until you find the loop.

5. Write down what you find, including the ones that turned out fine. Half the value is the record showing you asked.

One warning from experience: do this reading forward from where you are, not by checking off where you’ve been. Three of our five were found while investigating something else entirely. Reviewing a document against itself confirms the document; running the thing finds the bug.

The checklist

1. List accounts whose recovery path is “email support”.
2. For each, ask: does this provider’s failure take out the mailbox that recovery email goes to?
3. Move only those. Point them at a domain you don’t control. Usually three accounts: DNS, registrar, mail.
4. Check your registrar isn’t inside your DNS provider’s account. If it is, move the domains that matter — while everything still works, because transfers need a functioning account on both sides.
5. Trace your mail provider’s own recovery to something independent.
6. Configure emergency access. Tell the person. Confirm they have an account with that provider. Check the waiting period and scope.
7. Recovery phrase on paper, off-site, location recorded somewhere a successor will read.
8. Move monitoring off the thing it monitors, and give it an outbound heartbeat so its own death is noisy.
9. Store backup credentials somewhere that survives losing the backed-up machine.
10. Write down the chain — including the parts that were already fine.

Two hours, most of it waiting for verification emails. It sits naturally alongside a proper business continuity plan — the difference between the two is that a continuity plan lists what you’d do, and this exercise checks whether you actually could.

Closing

None of these five were found by a scanner, a pen test, or a compliance checklist. All five passed every test that had ever been pointed at them, and would have kept passing indefinitely.

They were found by asking a question that testing doesn’t ask: what does this need in order to work, and will that thing still exist on the day I need it?

It’s an uncomfortable question, because a lot of the reassurance we take from having controls comes from not having asked it. But the alternative is finding out during the incident, which is the only time it costs anything.

Try it on one control. Pick your backups, and follow the chain all the way to the end. If it terminates somewhere independent, you’ve lost ten minutes. If it loops, you’ve just found the reason your recovery plan wouldn’t have worked — on a day when fixing it is a small piece of admin rather than an emergency.

This is precisely the kind of thing we look for in a free security review — not just whether the controls exist, but whether they’d actually hold on your worst day.