What Is Backup Security? Definition, Eight Controls and a Self-Check

What is backup security?

Backup security means protecting backup systems and backup copies from ransomware, deletion and unauthorised change, and proving that restores actually work. It covers monitoring backup health, hardening the backup infrastructure, keeping an immutable copy, and testing recovery under attack conditions. Its threat model is an attacker who already holds administrator credentials: an outsider, a rogue or coerced insider, or someone using a compromised MSP or remote-management account.

The definition covers any backup system, SaaS backups such as Microsoft 365 included; the recommendations below are written for Veeam Backup & Replication 13.1.1 (build 13.1.1.18, released 2026-08-13), the highest version listed in Veeam KB2680.

Backups as the first target

A working restore removes the attacker's leverage. CISA's #StopRansomware Guide: "Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions; they also use publicly available exploits to target unpatched backup solutions." In Veeam's 2025 survey, 89% of the attacked organisations (900 of 1,300) had their backup repositories targeted; in Sophos's early-2024 survey, 57% of attempts to compromise backups succeeded, and median recovery cost $3M with compromised backups versus $375K without.

The software is a target too. CISA's KEV catalog (version 2026.09.25) lists four Veeam Backup & Replication vulnerabilities marked "Known" for ransomware campaign use: CVE-2022-26500, CVE-2022-26501, CVE-2023-27532, which lets an unauthenticated user inside the backup network "obtain encrypted credentials stored in the configuration database", and CVE-2024-40711, an unauthenticated remote code execution (NVD CVSS 9.8) fixed in build 12.2.0.334 (KB4649). Sophos X-Ops documented intruders who came in through compromised VPN appliances and used it "to create a new local administrator account named 'point'", with some cases ending in Akira, Fog or Frag ransomware.

Eight controls

The controls fall into four parts: harden (1 to 3), keep an immutable copy (4 and 5), monitor (6), test recovery (7 and 8).

1. Identity and access

Administrator rights on the backup server or a proxy let an attacker "erase most of the production data, backups, and replicas" (Veeam security guidance).

• Separate the backup identity from production. For large environments Veeam recommends "a management domain in a separate Active Directory forest"; medium-sized and small ones may use a separate workgroup. CVE-2025-23120 (KB4724, CVSS 9.9) allowed remote code execution "by an authenticated domain user" and "only impacts domain-joined backup servers".
• Enable MFA, service accounts first. MFA does not cover non-interactive connections from the REST API, Enterprise Manager (to the backup server), the Veeam ONE agent or Veeam Backup Validator, and it does not cover PowerShell at all. Mark the accounts those tools use as service accounts before enabling MFA, which disables MFA for them; otherwise those connections fail, and so does a configuration database restore, which Veeam says to run under a service account with MFA disabled. Restrict and monitor these exempt accounts.
• Enable four-eyes authorization. In v13 the operations that need a second Backup Administrator or Security Administrator include deleting backups, removing repositories, user and user group changes, MFA and automatic logoff changes, disabling or shortening immutability on a Linux or hardened repository, and switching four-eyes off. While it is on, delete operations through PowerShell, the REST API and Enterprise Manager are blocked outright, which covers the MFA-exempt accounts. In v12, immutability changes are not on the list.

Note: MFA can be enabled only for individual user accounts, not user groups, and covers the remote console and web UI, not operating-system logons, which need their own control. Enterprise Manager's own login needs a SAML identity provider for MFA. Only Backup Administrators can manage MFA, so keep at least two enrolled. Four-eyes approvers can be granted through a user group, so anyone who can edit that group in Active Directory can make themselves an approver. KB4649 lists CVE-2024-40713, which let a low-privileged Veeam user "alter Multi-Factor Authentication (MFA) settings and bypass MFA" before build 12.2.0.334.

Check: the backup server is outside the production Active Directory domain (separate forest or workgroup); MFA is enforced on every individual Veeam user account (not granted through a group) and on operating-system and remote logons to the backup server and repositories, with every MFA-exempt service account known and restricted; four-eyes authorization is enabled, with approvers who are different people on individual accounts that no production domain admin can add themselves to.

2. Hardening and patching

• Patch to Veeam's security bulletins, not to KEV alone. CVE-2025-23120 is not among the KEV entries above.
• Block inbound internet access. Veeam's hardening guidance: "Inbound connectivity to backup servers from the internet must not be allowed."
• Segment the backup network from the inside. CVE-2023-27532 needed no credentials, only a foothold inside the backup network. The UK NCSC's on-premises principles open with "Make it possible to isolate your backup solution".
• Run the Security & Compliance Analyzer (also present in 12.x); Veeam advises running it regularly, "especially after you make significant changes".
• Use single-use credentials when adding a hardened repository. The hardened repository then keeps no stored password: "Even if the Veeam Backup & Replication server is compromised, the attacker cannot get the credentials and connect to the hardened repository."
• For DISA STIG and FIPS compliance, deploy the Veeam appliances. Veeam recommends its preconfigured Rocky Linux builds, the Veeam Software Appliance and Veeam Infrastructure Appliance, for that purpose. If deployed, set up the Security Officer account during initial configuration.

Note: Do not clear the Analyzer's list in one pass. Some items remove remote access: Remote Desktop Services and WinRM disabled on Windows, the SSH server disabled on hardened repositories. Secure console or out-of-band access first, and check which scripts and tools depend on those services.

Check: the backup server is on a supported build with every Veeam security fix applied, not only the KEV-listed ones; the Analyzer has run since the last significant change, with every item not marked Passed either fixed or consciously excluded, and out-of-band access in place before any change that disables remote access.

3. Encryption and key custody

Encryption protects a stolen copy but creates a new way to lose one: if the password is lost or the KMS fails, "you will not be able to recover data from backups or tapes unless you use Enterprise Manager keys in the encryption process" (Veeam encryption documentation).

• Enable password loss protection, and install Enterprise Manager on a different machine from the backup server "to reduce the risk of a key change attack" (hardening guidance).
• Encrypt configuration backups and keep their repository off the backup server's network. The configuration database holds the credentials for hypervisors, hosts and other infrastructure; they are encrypted, "However, a user with administrator privileges on the backup server can decrypt passwords which is a potential threat" (hardening guidance). An unencrypted configuration backup is missing the secrets: "Credentials, encryption keys, and certificates will not be stored in the configuration backup."
• Configuration backups can be made immutable on hardened, object storage, HPE StoreOnce and Dell Data Domain repositories.
• Keep the configuration backup password somewhere that does not depend on the backup server. The encrypted configuration backup is how a lost backup server is rebuilt with its credentials and keys.

Check: an encrypted configuration backup has been restored, and a backup decrypted, on a clean server without the original backup server.

4. Immutability and isolation

On a hardened repository, files inside the immutability period "cannot be moved, modified or deleted, but can be copied". On object storage the equivalent is Object Lock. CISA recommends "delete protection or object lock on storage resources often targeted in ransomware attacks", with a caution about cloud vendors' immutable storage offerings: "Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost."

• Check the Object Lock retention mode. On Amazon S3, anyone with s3:BypassGovernanceRetention can delete objects locked in governance mode, and the S3 console sends the bypass header by default. Governance mode protects only if no credential an attacker can reach holds that permission.
• Test retention settings in governance mode, and try compliance mode on a disposable bucket with a short retention first. Compliance mode cannot be undone before the retention date passes; AWS says the only way to delete such an object early is to delete the account.
• Isolate the account that owns the storage. An attacker who reaches it can bypass governance-mode locks, deny access or delete the account itself. NCSC asks that a backup system be configured so it "isn't possible for an attacker to deny all customer access", including by deleting the whole account.

Check: at least one copy is immutable, the lock is verified on the storage itself and not only in the console, and its retention mode is known.

5. Copies and media

Veeam's hardening guidance says to follow the 3-2-1 rule and to "Use offline media to keep backup files in addition to virtual storage"; the 3-2-1-1-0 rule adds an immutable or air-gapped copy. For each copy, identify who can delete it, and keep at least one that survives the loss of the backup administrator's credentials.

Check: there is an offline copy, and a copy that the backup administrator's own credentials cannot delete.

6. Monitoring and drift detection

Job results show health; backup security also needs a change signal: new administrator accounts on the backup server's operating system, new Veeam users or roles, MFA or four-eyes disabled, repository settings edited, immutability shortened, jobs deleted.

• Watch the operating system, not only Veeam. The "point" account was a local Windows account, which Veeam's own events never see; it appears in the Windows Security log as event 4720, "A user account was created".
• Alert on event IDs, not on severity. A "Warning and above" rule misses Info events 42401, 40201, 31200 and 28100.
• Forward events off the backup server. On a Windows backup server, Veeam writes its security events to the Windows Event Log and can forward them to a syslog server.

Note: 42401 Four-Eyes Authorization Disabled, 40201 Multi-Factor Authentication Disabled (for all users), 31200 User or Group Added and 28100 Backup Repository Settings Updated are all Severity: Info; 23090 Job Deleted is Warning. Because switching four-eyes off needs a second approver, the earlier warning is Info event 42402 Four-Eyes Authorization Request Created with the operation "Disable four-eyes authorization"; the same event ID covers every other approval request too.

Check: Info-level security events such as 42401, 40201, 31200 and 28100 raise an alert off the backup server, with someone who acts on it.

7. Restore testing

A successful job does not establish that a restore point boots or that its applications work. NIST CSF 2.0 makes the same point as a recovery outcome: verify backup integrity "before using them for restoration" (RC.RP-03). How fast the restore must finish is an RTO question, worked through in our RTO vs RPO guide.

• Verify recoverability with SureBackup. It has two modes, in v13 as in 12.x. Full recoverability testing boots machines from the backup in an isolated virtual lab and runs heartbeat, ping and application tests; "Backup verification and content scan only" can check integrity and scan content for malware without a lab.
• Assess suspect restore points before recovery. Malware detection adds Secure Restore and scan-backup options. A locked copy of a compromised system restores the compromise.

Check: the date of the last isolated boot from backup is known.

8. Adversarial testing

Restore testing assumes the attacker has left. Veeam concedes the limit of in-application controls: "four-eyes authorization cannot protect the backup infrastructure if the Veeam Backup & Replication server is compromised."

• Test from the attacker's position: whether a harvested credential reaches the repository, whether immutability can be shortened, whether four-eyes fires and whether anyone gets an alert.
• Test in a lab, or against a disposable test job, test repository or test bucket with short retention, under written authorisation.

Note: Never test against the only immutable copy, and never run exploit code against a production backup server. Testing against production copies can destroy recovery points, and a test bucket with long compliance retention keeps charging until the retention expires.

Check: the date of the last test in which someone played the attacker is known.

Standards

NIST CSF 2.0 has one Protect outcome written for backups, PR.DS-11: "Backups of data are created, protected, maintained, and tested." ISO/IEC 27001:2022 Annex A covers them in A.8.13 Information backup. The UK NCSC publishes separate principles for cloud and on-premises backups; both make key management, and alerts when significant changes are made or privileged actions are attempted, principles of their own. How the eight controls map to these frameworks is our interpretation, not an official crosswalk.

Limits

• Survey figures are directional: vendor-commissioned and self-reported. Veeam does not state the base for its 89%, which can only be a share of the 900 attacked; Sophos's 57% is a share of attempts, from early 2024, and Sophos has not asked that question again since.
• Retention is a race against dwell time. A lock keeps a clean restore point only if that point was written before the compromise, and only until the lock expires. An attacker who quietly stops jobs or shortens retention, then waits, can outlast every lock; the change alerts in control 6 close that gap.
• Controls inside the backup application fall with the backup server. What holds after the server is lost is enforced elsewhere: the repository, the storage, a separate identity. Immutability also protects availability, not confidentiality: in Sophos's 2026 survey, data was both encrypted and stolen in 16% of attacks.
• Scope. v12 (12.3.2) was checked only for four-eyes, the Analyzer and SureBackup, so check the rest against the v12 documentation; whether the Linux-based Veeam Software Appliance sends the same event IDs to syslog is unverified. The ISO/IEC 27001 control number and title are not checked against the paywalled standard, and absence from KEV is not evidence of safety.

For a broader scored questionnaire, the free Backup Security Assessment asks 28 questions across seven domains, and the ransomware cost calculator puts a figure on a failed restore. For the ransomware-specific design, see building ransomware-resilient backups.

How BackupSec approaches this

ZeroMON is an on-premises client that reads Veeam Backup & Replication through the REST API and never writes to it. It runs with a read-only Veeam account; giving that account the Backup Administrator role unlocks a few extra fields (configuration backup status, general options, license details). Like any integration account it is MFA-exempt, so restrict and watch it. ZeroMON tracks job health, configuration changes, the immutability status Veeam reports and the backup server's build and patch level, with alerts by email and in-app notification. It does not verify locks on the storage or run restore tests. ZeroTAM is advisory work on architecture and hardening. ZeroPEN is the adversarial test: a kill-chain, non-destructive penetration test of Veeam, mapped to MITRE ATT&CK. ZeroVault is managed S3-compatible object storage with Object Lock support for Veeam, for the off-site copy. Stork365 covers Microsoft 365 backup and restore with bring-your-own-storage.

See how the five layers fit together →