Backup Identity Isolation Guide: Separating Backup Admin and Service Accounts from Production

If the identities that administer backups live in the same directory as the identities an attacker has just compromised, the backups fall with production. Most backup destruction uses valid credentials: a domain admin who also logs in to the backup console, a cloud role with delete rights on recovery points, or a long-lived API key stored on a backup server. This guide covers how to build a separate identity plane for backup administration and backup service accounts: directory and tenant design, authentication, multi-person approval, break-glass access, the credentials backup software holds, and how to detect attempts to delete or weaken backups. It is written for infrastructure, identity and cloud engineers who run backup platforms, and for security leaders who need to prove recovery will survive an identity compromise. Storage immutability and the 3-2-1-1-0 rule are covered in the Backup Security and Immutable Backup Guide and not repeated here.

Key takeaways

• Isolation is an identity property first. A vault in a separate network or account is only as isolated as the directory, tenant and roles that can administer it.
• No production identity should be able to destroy a backup. Domain admins, cloud organisation admins and production service accounts should hold no rights in the backup plane at all.
• Destructive actions need two people. Use the platform's quorum control (Veeam four-eyes authorisation, Azure Backup multi-user authorisation, AWS Backup multi-party approval) and place the approver in a different administrative domain.
• Backup software is a large non-human identity. It stores credentials for hypervisors, databases, SaaS tenants and storage; scope them, vault them and alert on their use from anywhere else.
• Watch the backup plane as closely as the domain controllers. Retention changes, lock removals, new backup admins and deletion calls are high-fidelity signals of an attack in progress.

Why backup identities are the shortest path to unrecoverable ransomware

MITRE ATT&CK lists the attacker goal as T1490 Inhibit System Recovery under the Impact tactic, usually executed just before T1486 Data Encrypted for Impact. The credentials used to reach backups map to T1078 Valid Accounts: T1078.002 Domain Accounts on premises and T1078.004 Cloud Accounts in cloud backup services. In cloud storage the deletion itself can be done with the platform's own features, which ATT&CK now tracks as T1485.001 Lifecycle-Triggered Deletion.

• Shared directory: backup servers joined to the production Active Directory accept the same domain admin token that the attacker used to deploy ransomware. Veeam's own best practice says the most secure design is a separate management domain in its own forest, because "the Veeam Availability Infrastructure does not rely on the environment it is meant to protect", and calls the production domain the least secure option.
• Shared cloud control plane: backup vaults in the same AWS account, Azure subscription or Google Cloud project as the workloads inherit every administrator of that scope, including any attacker who has added cloud roles (T1098.003 Additional Cloud Roles).
• Stored credentials: the backup platform holds credentials for everything it protects. Compromising it yields the estate, and compromising the estate often yields it.
• Long-lived keys: in the Codefinger S3 ransomware campaign, long-term AWS access keys with s3:GetObject and s3:PutObject were enough to re-encrypt buckets with SSE-C and set lifecycle rules to delete the data within seven days. No vulnerability was involved.

Designing a separate identity plane

The goal is that a full compromise of the production directory and production cloud administration gives the attacker no sign-in, no role and no token in the backup plane. The options trade isolation against operational effort.

The cloud platforms now build this in. AWS Backup logically air-gapped vaults can be shared through AWS Resource Access Manager only to named account IDs, not whole organisations or OUs, and AWS recommends that a customer managed key for such a vault come from "a separate recovery-dedicated account". Its multi-party approval feature expects a second, recovery organisation whose management account runs its own IAM Identity Center instance as the approvers' identity source. Google Cloud Backup and DR describes its backup vault as giving "project-level identity isolation", with an access restriction setting that becomes permanent once chosen. Microsoft documents three placements for the Azure Backup Resource Guard, rating a different tenant as giving maximum isolation.

• No trusts, no sync: the backup directory or tenant must not trust production, must not synchronise identities from it, and must not federate sign-in to the production identity provider. A federation trust is a path from a stolen production IdP to the vault.
• No shared infrastructure dependencies: Veeam notes that if production domain controllers are down, a domain-joined backup console may not authenticate or resolve names, so restore stalls exactly when it is needed. Give the backup plane its own DNS and time sources.
• Small versus large: a small organisation with one backup server can use a workgroup server with unique local admin accounts and a SaaS or cloud vault in a separate account. A large organisation should run a management forest or recovery tenant shared by backup, hypervisor management and other tier 0 recovery tooling, so the cost is spread. See the Active Directory and Entra ID Hardening Guide.

Backup administrators: authentication and roles

Once the plane is separate, the human accounts inside it need the same treatment as any tier 0 administrator, plus a few backup-specific rules.

• Dedicated accounts: backup admins use accounts that exist only in the backup plane, never their daily account or their production admin account. Remove production Domain Admins, Enterprise Admins and cloud organisation administrators from all backup roles.
• Phishing-resistant MFA on a separate device: the NCSC advises that the MFA method for backup systems "should not be installed on the same device that is used for the administration of backups". FIDO2 security keys meet both needs. See the Phishing-Resistant MFA Guide.
• Privileged access workstations and network allow lists: the NCSC recommends protecting backup accounts with privileged access workstations and hardware firewalls that enforce IP allow listing. Backup consoles should accept administrative sessions only from those workstations.
• Least-privilege roles: split operator (run and monitor jobs, restore to approved targets), administrator (change jobs and repositories) and security administrator (approve destructive actions, manage approval settings). Azure RBAC provides three built-in Azure Backup roles for managing recovery points; Veeam separates Backup Administrator and Security Administrator roles.
• Just-in-time elevation: no standing rights to delete or shorten retention. Microsoft's MUA pattern has the security administrator grant the Backup MUA Operator role temporarily through Entra Privileged Identity Management, then revoke it. See the Privileged Identity Management (PIM) Guide.
• Windows Backup Operators: on production Windows servers and domain controllers, this built-in group (SID S-1-5-32-551) can read every file regardless of permissions. Keep it empty and alert on membership changes.

Multi-person approval and quorum controls

A single stolen admin account should never be enough to destroy recovery. Each major platform offers a quorum control; the design question is who approves and from which identity domain.

• Separate the approver: the approver must not be reachable through the same compromise. Microsoft explicitly recommends a different subscription or tenant for the Resource Guard. Two backup admins who both sign in through the production IdP are one compromise, not two.
• Test the approval path: an approval team whose members have left, or whose notifications go to a compromised mailbox, fails during the incident. Run a quarterly request through the full flow.

Break-glass access to the backup plane

Isolation creates a new failure mode: losing access to your own backups because the backup identity source is down, the approvers are unreachable, or the MFA devices are lost. Plan for it explicitly. See the Break-Glass Account Guide.

1. Create at least two emergency accounts in the backup plane: Microsoft's emergency access guidance for Entra ID recommends two or more cloud-only accounts, not federated or synchronised from on premises, with FIDO2 passkeys using a different method from normal admins. Apply the same logic to the backup directory or recovery tenant.
2. Store credentials physically and separately: sealed in separate secure locations, with a named custodian list, and changed when a custodian leaves.
3. Exclude from blocking policies, not from logging: emergency accounts must not be locked out by conditional access, but every sign-in should raise a critical alert to a channel outside the corporate tenant.
4. Drill every 90 days: Microsoft recommends validation at least every 90 days and after staff changes. For backups, the drill should end with a real restore, not just a sign-in.

Backup service accounts, agents and API keys

Backup platforms are among the most privileged non-human identities in an estate. They need read access to everything protected and write access to storage, and they hold the credentials to do both.

• Credentials off the client when idle: the NCSC says backup clients "should not have valid credentials while your cloud storage is not in use" and that the number of backup clients should be minimal.
• Vault and rotate: store connection credentials in a secrets manager in the backup plane, rotate on a schedule and immediately after any backup server compromise. See the Service Account Security Guide and the Secrets Management Guide.
• Bind to source: alert when a backup credential authenticates from anywhere other than the backup servers or proxies.

Implementation: a phased approach

1. Map the backup identity graph: list every human and non-human identity with rights in backup consoles, vaults, repositories, cloud backup roles and key stores, and every credential the backup software holds. Mark which ones originate in the production directory or tenant.
2. Remove production administrators: take Domain Admins, cloud organisation admins and general IT groups out of backup roles. Expect breakage in scripts and monitoring; fix them with scoped service principals in audit mode first.
3. Stand up the backup identity source: management forest, workgroup, recovery account, recovery organisation or tenant, chosen from the design table. Pilot with one backup server or one vault, and keep the old access path disabled but not deleted until a restore has worked through the new one.
4. Issue new admin accounts with phishing-resistant MFA and PAW-only access: enrol keys, enforce network allow lists, then disable the old accounts.
5. Turn on quorum controls: enable MUA, multi-party approval or four-eyes with approvers outside the backup admin group. Test that a deletion request fails without approval and succeeds with it.
6. Convert service accounts: replace static keys, reduce to create and append, add deny guardrails at organisation level, vault what remains.
7. Create and drill break-glass: two emergency accounts, sealed credentials, alerting, first drill completed.
8. Prove it: run a tabletop and a technical exercise in which the red team holds domain admin and cloud organisation admin, and confirm they cannot delete, re-encrypt or shorten retention on the protected copy. Rollback at each phase is re-enabling the previous access path; do not lock any compliance-mode retention until this test passes.

Detecting attempts to delete or weaken backups

Attackers usually probe the backup plane hours or days before encryption. These signals deserve high-severity alerts routed to responders outside the production tenant.

The NCSC's cloud backup principles ask for alerts on mass deletions, stopped backups, changes to retention or encryption policies and changes to administrator accounts, whether or not the action succeeded. A failed deletion against a locked vault is often the earliest warning you will get.

Metrics

• Production identities with backup rights: count of accounts or groups from the production directory or tenant with any backup role. Target zero.
• Standing destructive rights: number of identities able to delete or shorten retention without approval. Target zero outside break-glass.
• Static backup credentials: long-lived keys or passwords held by backup software, and their age against the rotation policy.
• Quorum coverage: percentage of vaults and backup servers with multi-person approval enabled and tested in the last quarter.
• Break-glass drill recency: days since the last successful emergency restore drill. Target under 90.
• Time to alert: minutes from a test deletion attempt to a responder acknowledging it.

Common failure patterns

• The vault is separate, the admins are not: a recovery account or tenant administered by users who sign in through the production IdP, so one compromise reaches both.
• Approvers in the same blast radius: four-eyes or MUA enabled, but both people use production accounts and production email, and the attacker controls both.
• Long-lived keys with delete or overwrite rights: a backup writer key that can also delete, re-encrypt or set lifecycle rules, which is the Codefinger pattern.
• Backup server joined to production for convenience: the domain admin used for deployment can log in to the console and remove jobs.
• Break-glass that does not work: sealed credentials never tested, keys expired, or the only approver has left.
• Alerts that go to the compromised tenant: deletion alerts are delivered to a mailbox or chat the attacker is already reading.

Framework mapping

Practitioner checklist

• Inventory every identity and stored credential with rights in the backup plane, and flag those from production.
• Remove production domain and cloud organisation admins from all backup roles.
• Run backup administration from a separate forest, workgroup, recovery account or recovery tenant with no trust or sync to production.
• Require phishing-resistant MFA on a device separate from the admin workstation, and PAW-only access to consoles.
• Enable multi-person approval for deletion, retention reduction and lock or immutability changes, with approvers in a separate domain.
• Replace static backup keys with roles or workload identity, limit writers to create and append, and vault the rest.
• Create two tested break-glass accounts for the backup plane and drill a restore at least every 90 days.
• Alert on deletions, lock and retention changes, new backup admins and off-host use of backup credentials, delivered outside the production tenant.
• Prove isolation with an exercise in which the attacker holds domain and cloud admin.

Standards and references

• NCSC: Mitigating malware and ransomware attacks
• NCSC: Offline backups in an online world
• MITRE ATT&CK: Inhibit System Recovery
• Microsoft Learn: Multi-user authorization using Resource Guard
• AWS: Multi-party approval for AWS Backup
• AWS: Logically air-gapped vault
• Veeam: Workgroup or Domain?
• Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID

Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Cyber Recovery Vault Guide · Ransomware Prevention Guide · Privileged Access Management Guide · Ransomware Response and Recovery Guide