When the backup administrator is compromised: break-glass recovery authority

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Treat the everyday backup administrator as someone you may have to work without. The role that writes backups, reads the catalogue, and knows where the copies sit is exactly the role a criminal wants after the first privileged logon. Recovery authority is the named right to decide that a copy may be opened, and to hold the credential that can open it. That right has to survive the loss of the backup administrator's accounts, their password store, and the directory that would normally reset those accounts.

"Break-glass" in this article means that pre-assigned authority and credential. It does not mean a particular cloud console, a vendor's multi-person approval button, or an identity-provider emergency account used to fix a sign-in policy. Those products can implement parts of the design. They are not the design. This article also does not rebuild a domain or repair an operating system.

Why the daily role cannot be the recovery role

NIST IR 8374r1 (June 2026) says many ransomware intrusions start from compromised credentials or from a process that was never meant to have privileged access, and it points at least privilege and separation of duties. It also says the type of credential, and how credentials are issued, managed, revoked, and recovered, matters because credential compromise is a common path into ransomware. A backup administrator credential is privileged by nature. It can see systems, storage, and often the hypervisor or the cloud account. Once it is stolen, every copy that credential can delete is already inside the incident.

The September 2023 #StopRansomware Guide tells you to hunt, after detection, for newly created or escalated directory accounts and for recent activity on privileged groups. It also tells you to look for tools used to impair backups. That hunt is an admission that the people and services who protect recovery may already be part of the compromise. The same guide says breaches often involve mass credential theft, and that continued access may require disabling remote access and single sign-on until you understand which accounts are involved. Asking the backup administrator to log in and "confirm the backups are fine" uses the account you have just been told to distrust.

NIST SP 800-184 states the recovery consequence. If a directory is restored and the adversary still has an account that can manage it, the adversary keeps access. The examples it gives are a service account with administrative rights, a forgotten administrative account, an authorised management tool with agents still installed, and a public-key component used for authentication. Any of those can sit inside a backup platform. Restoring data with the same account that the attacker holds does not end the incident. It restocks it.

There is a human version of the same fact. The administrator may be absent, coerced, or simply the person whose laptop was the entry point, with no malice at all. Authority that exists only in their head is not authority you can use at 02:00.

What to separate

NIST SP 800-61 Rev. 3 distinguishes leadership, who may decide high-impact actions such as shutting down or rebuilding critical services, from incident handlers and from the technology administrators who carry work out. Recovery outcome RC.RP-01 says to tell every person with a recovery duty which authorisations each part of the plan needs. SP 800-184 asks the recovery plan to name two or more management staff who may activate it, with points of contact, and to list the recovery team separately.

Use those distinctions to split four acts that backup teams usually fold into one login:

Our recommendation, not a sentence copied from NIST or CISA: do not let one person propose, approve, and perform on the same day for the copy you claim an attacker cannot reach. SP 800-184 asks the plan to name at least two managers who may activate it; that supplies alternatives and does not itself require two simultaneous approvals. Dual control for release is our additional recommendation. Three acts in two people is workable in a small team if the custodian is not the proposer. Write the pairing down. A matrix that exists only in a product manual no one has read will be ignored when the directory is offline.

The CISA guide puts password resets for affected systems and accounts after the environment has been cleaned and rebuilt, and it puts the formal declaration that the incident is over with the designated authority, against criteria you set in advance. The recovery section then says to restore data from offline, encrypted backups onto a clean network. Read that as a planning constraint. Do not read that checklist order as a ban on prompt credential containment. Incident responders may need to restrict compromised access immediately under the response plan. The everyday credential must not introduce an isolated copy to an untrusted network. The authority to open the copy belongs in the plan before the incident, because the guide also says to follow your approved incident response plan rather than inventing governance in the middle of the checklist.

The credential that must sit outside the lost directory

Separation of duties on paper fails if both people authenticate to the same directory the attacker is editing. IR 8374r1's point about how a credential is issued and revoked is the technical half of break-glass.

The release credential should have these properties. They are design requirements, not a build guide for a particular product:

• It is not a member of the daily backup-operators group, and that group cannot reset it or add itself to it.
• It is not stored in the password vault that the backup administrators use for routine work. If that vault is the one integrated with the directory you are about to distrust, it is in scope.
• It can be reached when email and single sign-on are unavailable. The CISA checklist says that after a compromise, actors may watch ordinary communications, and it tells responders to isolate in a coordinated way and to use out-of-band methods such as phone calls so that the response itself does not tip the attacker into a wider detonation. SP 800-184 says the same thing from the other side: if the network is compromised, email may be unwise, and the plan needs a way to reach business, IT, and security stakeholders without production systems. IR 8374r1 tells you to put an out-of-band communications strategy in the incident response and recovery plan.
• Two named people can produce it. A token in one person's pocket is a single point of failure and a single point of coercion. A seal, a safe, or a split secret only works if the plan says who meets, where, and what they compare before the credential is used.
• Use is logged somewhere the daily backup administrator cannot erase. CISA treats log preservation as part of response. A release that leaves no record is indistinguishable from the attacker attaching the copy themselves.

Physical access is part of the same control. IR 8374r1 notes that physical access management still matters, including against people who can walk up to devices. SP 800-61 Rev. 3 includes facilities management because handlers may need to enter a locked room, and because some incidents are physical and logical together. If the break-glass token is in a drawer the backup administrator already opens every Friday, you have not moved authority. You have moved a plastic card.

Managed providers and the same problem

Many organisations do not employ the person who can delete backups. An MSP or a platform operator does. The CISA guide says MSPs have been an infection vector affecting many clients, and that if a third party maintains your backups you should require the relevant practices in the contract, with least privilege and separation of duties so the third party only reaches systems inside its role. SP 800-61 Rev. 3 says a provider may hold a primary response role, that the contract has to define authority to act for you, and that you should consider both a malicious insider at the provider and compromise of the provider. It also says providers often have privileged access. A break-glass design that assumes "our admin" and forgets "their admin" has a hole the size of the contract.

Write three lines into the agreement, in your own words, and check that the provider can actually perform them:

1. Who at the provider may refuse a delete or a retention change requested by your everyday backup contact, and under what evidence.
2. Who at your organisation can order the provider to stop using the production directory for administrative sign-in, and how that order is authenticated when email is untrusted.
3. Where your offline or otherwise isolated copy lives if the provider's own console is the thing that has been compromised. If the answer is "only inside that console", you do not have an independent recovery authority. You have a vendor relationship.

SP 800-184 allows the plan to name pre-arranged external support that can augment the recovery team. That support is useful. It does not replace the two named managers who may activate the plan. An external firm that arrives with domain-admin rights and no dual control is another backup administrator, hired later.

What "activate" authorises, and what it does not

Activation, in SP 800-184's list, is the decision that the recovery plan is in force. It should unlock a short list of actions and refuse others until a later gate.

Authorised on activation, if you have written them this way:

• Notify the custodian and the second manager by the out-of-band path.
• Disable further use of the daily backup-admin role for deletes, retention changes, and repository attachment. How that disable is done depends on the platform. This article does not supply the commands.
• Start an inventory of copies, including the ones the daily console may already have corrupted. IR 8374r1 and SP 800-61 Rev. 3 both require the integrity of restoration assets to be checked before they are used. A break-glass login that immediately restores the newest job skips that requirement.
• Record who approved the activation, at what time, and which copy they were talking about.

Not authorised by activation alone:

• Putting the isolated copy on the production network.
• Paying a ransom, which is a leadership and legal decision. SP 800-61 Rev. 3 puts legal review on the response plan for a reason, and the CISA guide tells you to report to law enforcement and to consider whether a decryptor already exists. Neither document makes the backup administrator the payment authority.
• Declaring systems clean. CISA separates rebuilding and account cleanup from the later restore onto a network that receives only clean systems.
• Telling the press. Public affairs is a named role in SP 800-61 Rev. 3, and IR 8374r1 treats public updates as their own recovery outcome.

Write the refusals down. In a real event, the first person who can type will be asked to do all four.

A small organisation still needs names

IR 8374r1 is written for organisations of any size, and it says many of the actions do not need a large budget. Two named activating managers, a custodian, an independent contact path and separately controlled credentials are a starting framework for a small team. Access enforcement, custody, logging and rehearsed availability still need to be designed and checked. The failure mode is pretending the owner "will just know". Owners travel. Owners are the compromised mailbox. SP 800-184's "two or more" is the correction: name a deputy who has rehearsed the phone call.

Rehearsal is part of the sources, not an extra. IR 8374r1 says to develop, implement, and regularly exercise the incident response and recovery plan, including roles and decision strategies, and including out-of-band communications. SP 800-184 says to practise alternate communications before the event. A tabletop that ends with "the backup admin restores the latest job" has not tested break-glass. A tabletop that starts by removing that person from the room, and that uses a phone rather than the corporate chat tool, has.

Hypothetical, not a case: the only person who knows the safe combination is the backup administrator, and the safe holds the token for the offline catalogue. On the day their account is the one creating new domain admins, the safe is not a control. The combination has to be held by the two activating managers, or split between a manager and a facilities custodian who is not in the backup group. That is an authority design. It is also a facilities design, which is why SP 800-61 Rev. 3 puts facilities in the role list.

Risks and limits

• Break-glass credentials are themselves a high-value target. A copy of the token in a ticketing system, a photo in a chat log, or a "temporary" standing permission issued during the last restore test and never removed is a standing admin account with a reassuring name.
• Dual control fails if both parties share a mailbox the attacker reads. The out-of-band path has to be real.
• Disabling the daily backup role during an incident can stop the only job still writing a clean increment, if you have not already confirmed an isolated copy. Make that trade-off in the plan, with the business owner, before the night it happens.
• This article gives no console steps, no directory commands, and no vendor approval-workflow settings. Those need the platform's own documentation and a test that this research did not run.
• CISA's checklist and NIST's profiles are US publications. They are not a legal opinion on who in an Australian company may authorise a payment, a notification, or a law-enforcement disclosure. SP 800-61 Rev. 3 expects legal and leadership roles because those decisions are not technical.

Research and verification

This article was drafted with AI assistance on 11 November 2026 and independently reviewed against public sources on 13 November 2026. It is source research, not a lab-validated recovery procedure or evidence of a NetLeverage product capability. No article commands or recovery operations were executed.

Sources

Independently reopened 13 November 2026.

• CISA, FBI, NSA, and MS-ISAC, #StopRansomware Guide (September 2023). Live official page independently reopened 13 November 2026.
• NIST IR 8374r1 (June 2026).
• NIST SP 800-61 Rev. 3 (April 2025).
• NIST SP 800-184 (December 2016).

This article was originally published on 13 November 2026.