Should organisations prioritise authentication on backup storage over encryption at rest?

How the two controls work together on backup storage

Backup storage needs both data protection and access protection, but they solve different problems. Encryption at rest limits what someone can read if they obtain the storage media or snapshots. Authentication and access control decide who can mount the backup target, enumerate it, or change what is stored there. On a backup path, that distinction matters because unauthorised access often starts before any decryption step.

That is why backup protection should be treated as a layered control, not an either-or choice. If an attacker or misconfigured host can reach the backup repository, they may still delete, corrupt, or exfiltrate data even when the backups are encrypted. Strong access control reduces the blast radius of a bad credential, a compromised admin session, or an over-permissive backup integration.

For teams designing storage protections, the practical question is not which control is “better”, but whether the backup target is reachable only by the identities and systems that genuinely need it. A locked-down backup repository with weak encryption still exposes plaintext to anyone with legitimate access. Strong encryption with weak authentication still leaves the path open to abuse.

Why authentication is often the more immediate control to verify

Authentication is often the first control to validate because it blocks unauthorised access before the backup content is ever handled. If backup storage can be mounted by broadly trusted hosts, shared admin accounts, or stale service credentials, encryption at rest may only help after the attacker has already obtained access to the storage layer.

That is especially important for backup systems that support restore, replication, or object browsing. Those functions are operationally useful, but they also expand the number of identities, sessions, and APIs that can reach the backup set. The more pathways there are into the backup plane, the more important it is to separate read, write, delete, and restore privileges.

Backup storage should therefore be protected by strong authentication, tight authorisation, and a clear trust boundary around the systems allowed to connect. For many organisations, that means separate administrative access for backup operations, restricted network paths, and no assumption that “internal” automatically means “safe”.

What encryption at rest still does that authentication cannot

Encryption at rest remains essential because it protects the contents if storage is lost, copied, misdelivered, or accessed outside the intended control path. It also reduces exposure when disk arrays, object stores, snapshots, or offline media are retired, repurposed, or handled by third parties.

NHIMG’s Encryption Guide is useful here because backup encryption is not just a checkbox, it depends on key custody, envelope design, and whether the organisation can still decrypt data when it needs to restore it. If the keys are too tightly coupled to the same environment that is being recovered, resilience suffers.

Encryption also helps limit the damage of physical compromise, but it does not stop a valid session from deleting an encrypted backup set, changing retention settings, or poisoning restore points. That is why encryption should be seen as confidentiality protection, while authentication and privilege control are integrity and availability protections for the backup path.

Risk and Threat Considerations

Backup systems are high-value targets because they sit at the intersection of recovery, retention, and business continuity. If an attacker gains access to a backup target, they can often bypass normal application controls, interfere with recovery, or use the repository as a pressure point for extortion and persistence.

Failure mechanism: Weak authentication, shared credentials, or overbroad backup privileges let unauthorised users or compromised systems reach the backup target, then delete, encrypt, or exfiltrate backup data before encryption at rest can help.

Impact: The organisation can lose recoverability, expose sensitive historical data, or discover too late that its fallback copy is also compromised, which turns a security incident into a resilience failure.

Practitioner Guidance

What to verify: Confirm that backup access is limited to dedicated identities and tightly scoped admin roles, not general infrastructure access. Check that restore, delete, and configuration rights are separated, because backup compromise often comes from excessive privilege rather than missing encryption.

Decision rule: If you can only improve one control immediately, prioritise authenticated access on the backup path first, then verify encryption at rest and key handling in parallel. If the repository is reachable by too many hosts or people, encryption alone does not meaningfully reduce the operational blast radius.

What practitioners underestimate: Backup storage is frequently attacked through legitimate access channels, so the real control question is whether a valid login can reach more than it should. Treat restore capability, retention changes, and deletion rights as high-impact permissions that deserve the same scrutiny as production admin access.

Practitioner takeaway: The right posture is layered, but the backup path itself must be tightly authenticated and authorised, otherwise encryption at rest may protect the data while still leaving the recovery system open to abuse.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• When should organisations prioritise OAuth over simpler authentication for MCP?
• When should organisations prioritise recertification over authentication improvements?
• When should organisations prioritise identity controls over backup tooling for ransomware defence?