Primary backups are usually the first recovery source and often remain tied to the main identity, directory, or infrastructure stack. Tertiary backups are a separate, independent copy designed to survive a broader compromise. In ransomware events, that separation matters because attackers may encrypt authentication systems or delete connected backup sets, leaving only isolated recovery paths available.
Why primary and tertiary backups are different recovery layers
Primary backups are usually close to the production environment and are optimised for routine recovery. They may share the same directory services, cloud tenant, backup console, or administrative trust chain as the systems they protect. Tertiary backups are the isolation layer, designed to remain reachable when that shared trust fabric has been compromised and a faster restore path cannot be trusted.
The difference is not just storage location. It is recovery dependency. A backup can be recent and still be unsafe if the same credentials, control plane, or network path that protected production also protects the backup set.
That is why ransomware planning treats primary backups as the first practical restore source, but not the last line of defense. If attackers can authenticate into the same environment, they can often encrypt, delete, or poison backup data before defenders can rely on it.
For broader incident context, the patterns seen across The 52 NHI breaches Report show how compromised credentials and lateral access can turn a recoverable environment into a fully shared failure domain.
Why ransomware changes backup strategy
ransomware recovery is not just about having copies, it is about preserving at least one copy outside the attacker’s reach. Primary backups may still be useful if the attack is contained early, but they are often too closely coupled to production to be trusted after a wide compromise. Tertiary backups are built for the scenario where the attacker has already breached administrative boundaries.
This matters because ransomware operators frequently target the systems that defend recovery first. They look for backup consoles, credential stores, domain controllers, and cloud management access because those are the fastest ways to disable restore options and increase pressure on the victim.
A practical indicator that tertiary backups are needed is any architecture where backup operations depend on the same login system, same privileged operators, or same network segment as production. In that design, the backup copy may exist, but the recovery path may not survive the incident.
That dependency pattern is visible in credential-focused incidents such as Cisco Active Directory credentials breach, where access to core directory services becomes a gateway to broader compromise.
What tertiary backups must protect against
Tertiary backups should survive three common failure modes: credential compromise, destructive backup administration, and correlated infrastructure loss. They are typically more isolated, more tightly controlled, and sometimes slower to access because that latency is the trade-off for survivability.
- They should not depend on the same authentication stack as production.
- They should not be writable from ordinary backup administration paths.
- They should be recoverable even if the primary backup catalog is lost or tampered with.
- They should be tested as an actual restore path, not just validated as a stored copy.
In cloud environments, the separation question is especially important because the same compromised credentials can be used to encrypt live data and backup data. The Codefinger AWS S3 ransomware attack is a strong example of how access to storage controls can erase the distinction between data protection and data destruction.
Operationally, tertiary backups are the place to introduce independence, slower change cadence, and stricter access review. That is not inefficiency, it is the point: the more isolated the copy, the more likely it survives an organisation-wide compromise.
Risk and Threat Considerations
Backup designs fail when organisations assume that multiple copies automatically mean multiple recovery options. If ransomware reaches the identity layer, the backup layer may be administratively visible even when it is physically separate, and attackers can use that visibility to destroy restore confidence.
Failure mechanism: The attacker compromises the same administrative trust used by primary backups, then encrypts, deletes, or invalidates connected backup sets before defenders can restore from them.
Impact: Recovery time extends sharply, restore options shrink to the most isolated copy, and the organisation may have to rebuild authentication and management services before data restoration can even begin.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-1 — Recovery Plan Executed | Primary and tertiary backups support a defined recovery path after ransomware. |
| PR.AC-4 — Access Permissions and Authorizations | Backup reachability depends on limiting who can modify or delete recovery copies. | |
| Recommendation — Test restore paths so the tertiary backup can actually support recovery under incident conditions. Restrict backup administration privileges so compromise of production access does not expose recovery copies. | ||
| CIS Controls v8 | 11 — Data Recovery | Directly addresses backup separation, recovery testing, and resilient restore design. |
| 6 — Access Control Management | Separated backups require tighter administrative access than production and primary backups. | |
| Recommendation — Maintain isolated recovery copies and verify they can restore after a destructive event. Limit backup admin access to prevent ransomware operators from tampering with recovery data. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Secrets Rotation and Lifecycle | Ransomware often abuses the same credentials and secret lifecycles that protect backup access. |
| NHI-05 — Overprivileged Non-Human Identities | Backup systems are frequently controlled by service identities with excessive reach. | |
| Recommendation — Rotate and isolate backup-related secrets so a compromised path cannot reach every recovery tier. Reduce backup service privileges so a single compromise cannot encrypt or delete all copies. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Recovery access depends on trustworthy administrative authentication before restore actions are allowed. |
| Recommendation — Require stronger assurance for backup administration and emergency restore access. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection | Tertiary backups rely on network and trust boundary separation from production and backup management. |
| Recommendation — Segment tertiary backup access from production to limit ransomware blast radius. | ||
Practitioner Guidance
What to verify: Treat “tertiary” as a recovery property, not a storage label. Verify that the copy is independent from production identity, backup administration, and routine write access, otherwise it behaves like another primary backup.
Decision rule: If a backup set can be altered by the same credentials that administer production or the backup platform, do not count it as your ransomware survivability layer.
What good looks like: The best design is one where the first restore source is convenient for ordinary incidents, while the tertiary copy is deliberately harder to reach, more tightly governed, and available even after directory or control-plane compromise.
Practitioner takeaway: In ransomware planning, the real question is not how many backups exist, but whether at least one backup survives the same compromise that destroys the rest.
Related resources from NHI Mgmt Group
- What is the difference between ransomware containment and recovery planning?
- What is the difference between strong primary authentication and secure account recovery in a passwordless programme?
- What is the difference between immutable backups and automated recovery testing in cloud resilience?
- What is the difference between disaster recovery and cyber recovery for security and resilience planning?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
