Defence in Depth Guide: Layered Controls That Survive a Single Failure

Defence in depth is the security strategy of placing several independent layers of controls between an attacker and what they want, so that when one layer fails, another still stops, detects or limits the attack. NIST and CNSS define it as a strategy that integrates people, technology and operations capabilities to establish variable barriers across multiple layers and missions of the organisation. Every control eventually fails, through a misconfiguration, a stolen password, an unpatched flaw or a missed alert, and most serious breaches happen when one failure meets no second layer. This guide explains the idea in plain language, then covers the layers, how to design them so they do not fail together, how defence in depth relates to zero trust, and what real incidents show. It is for learners and for practitioners reviewing security architectures.

Key takeaways

• Assume each layer will fail. The design question is not "is this control strong?" but "what catches the attack when this control is bypassed?".
• Layers must be independent. Five controls that all trust the same admin account or the same vendor are one control with a common-mode failure.
• Prevention alone is not depth. Every layer needs detection behind it, and recovery must work when everything else has failed.
• Identity is now a layer everywhere. Stolen human and machine credentials walk through network layers, so authentication, least privilege and credential monitoring belong in every tier.
• Zero trust is a way of doing depth well. It removes implicit trust inside the network rather than replacing the need for layers.

What it is

Think of a bank vault: there is a locked front door, guards, cameras, a vault door with a time lock, alarms wired to the police, and insurance. No single measure is perfect, but a thief has to beat all of them without being seen. Defence in depth applies the same thinking to IT. The term comes from military strategy, where a defender gives up ground slowly across successive lines rather than relying on one fortified line, and it was adopted by the US national security community for information assurance, notably in the NSA's Information Assurance Technical Framework, which organised it around people, technology and operations.

Two official definitions capture the two sides of the idea:

• Strategy view (CNSSI 4009, NIST SP 800-53 Rev. 5): an information security strategy integrating people, technology and operations capabilities to establish variable barriers across multiple layers and missions of the organisation.
• Engineering view (ISA/IEC 62443-1-1, quoted in NIST glossary): the application of multiple countermeasures in a layered or stepwise manner, layering heterogeneous security technologies in the common attack vectors so that attacks missed by one technology are caught by another.

NIST SP 800-53 makes it a control: PL-8(1) Defense in Depth requires organisations to design security architectures that allocate controls to multiple locations and layers and ensure the controls operate in a coordinated and mutually reinforcing manner. Its guidance gives the reasons: adversaries must overcome multiple controls, which increases their work factor and the likelihood of detection.

How it works

The layers

See the Network Segmentation Guide, the EDR Guide, the SIEM Guide and the Backup Security and Immutable Backup Guide.

Independence and common-mode failure

Layers only add up if they fail for different reasons. A common-mode failure is one cause that defeats several layers at once. NIST SP 800-53 SC-29 Heterogeneity addresses this directly: using a diverse set of technologies reduces the impact of a compromise of any one technology and protects against common mode failures, including those induced by supply chain attacks, though the same guidance warns that diversity adds complexity that can lead to mistakes. Common examples:

• Shared admin identity: the same domain admin or cloud root account manages firewalls, EDR, backups and the SIEM. Steal it once and every layer can be switched off.
• Shared management plane: one device management or orchestration tool that can push changes to every endpoint, as in the Stryker Intune wiper attack, where a hijacked admin account used Microsoft Intune to wipe devices.
• Shared credential store: backups, CI/CD and production reading secrets from one vault path with one token.
• Shared assumption: two teams each believing the other performs a check, as with the missing token scope validation in the Microsoft Storm-0558 key breach, which the Cyber Safety Review Board described as a cascade of errors.

Designing layers: a step-by-step approach

1. Pick the crown jewels (data stores, identity providers, signing keys, backups, OT systems) and rate them, for example with CIA impact levels.
2. Draw the attack paths to each one from likely entry points: phishing, exposed remote access, a supplier, a leaked key, a vulnerable internet-facing service.
3. List the controls on each path and mark each as prevent, detect or recover. A path with only prevent controls has no depth.
4. Test independence: for each control ask "what single credential, product, team or assumption would disable it?". Where two controls share one, separate them (separate admin accounts for backups, a separate identity tenant for recovery, logs shipped to storage the production admins cannot delete).
5. Add the missing layer where a path has fewer than two independent controls before the asset, starting with identity (MFA and least privilege) and recovery, which cover the most paths.
6. Validate with tabletop exercises, purple team tests and restore tests. Introduce blocking controls in audit or monitor mode first and keep a documented rollback, because PL-8(1) guidance notes uncoordinated controls can cause lockouts and cascading alarms.
7. Review on change: new SaaS, cloud accounts, AI agents and suppliers add paths that bypass older layers.

Why it matters

Real breaches rarely involve one clever trick. They involve one control failing and nothing behind it.

• Identity layer missing: in the Colonial Pipeline attack, an unused VPN account that had never been disabled, whose password had leaked and which had no MFA, gave access to the IT network. Account lifecycle, MFA and leaked-credential monitoring were all absent at the same entry point.
• Several layers failing in sequence: in the Capital One breach, a misconfigured web application firewall exposed the credentials of the cloud role it ran as, the role could read many storage buckets a firewall never needed, and no alert fired on the bulk reads. The intrusion was found through an external report months later. Any one of least privilege, metadata service hardening or bulk-access monitoring would have reduced the outcome.
• No detection after entry: in the Change Healthcare breach, a Citrix portal without MFA let attackers in, and they moved laterally and exfiltrated data for nine days before deploying ransomware.
• Detection as the layer that worked: in Storm-0558, prevention failed inside the provider, and the intrusion was spotted by a customer with premium audit logging and a custom alert on MailItemsAccessed events.

The joint CISA, NSA, FBI and MS-ISAC ransomware guide reflects the same logic: phishing-resistant MFA, segmentation including IT/OT separation, centralised logging and offline encrypted backups, each covering a failure of the others.

Choosing where to invest

• Small organisations: fewer layers, but independent ones: MFA on email and remote access, managed EDR, SaaS defaults hardened, and backups that a compromised admin cannot delete. One well-tested offline backup is worth more than a third prevention product.
• Large organisations: the risk shifts to complexity and shared management planes. Prioritise tiered administration, separate break-glass identities, centralised detection with coverage metrics, and control ownership so no layer is orphaned.
• OT and safety systems: availability and safety dominate; use zones and conduits (ISA/IEC 62443) and keep IT identity compromise from reaching control networks.

Measuring depth

• Percentage of crown-jewel attack paths with at least two independent preventive controls and one detective control.
• Percentage of privileged and machine identities covered by MFA or vaulting and least-privilege review.
• Log source coverage for crown-jewel systems in the SIEM, and mean time to detect in exercises.
• Successful restore tests from isolated backups within RTO.
• Number of controls that share an administrative identity or management tool with the systems they protect (target: falling).

Common misconceptions

• "More products means more depth." Stacking three tools that inspect the same traffic at the same point adds cost, not independence. Depth comes from covering different stages of an attack.
• "The perimeter is the main layer." Remote access, SaaS and cloud APIs mean valid credentials (ATT&CK T1078 Valid Accounts) bypass network edges. Treat the perimeter as one layer among eight.
• "Zero trust replaces defence in depth." NIST SP 800-207 describes zero trust as moving defences from static, network-based perimeters to users, assets and resources, with no implicit trust based on network location. The NCSC principles add that every network should be treated as untrusted and every request authorised. That is defence in depth applied per request and per resource, not an alternative to it. See the NIST SP 800-207 Zero Trust Architecture Guide.
• "Backups are an IT task, not a security layer." NCSC warns that ransomware encrypts connected backup drives and reachable cloud storage, and advises keeping at least one backup offline and letting backup clients add but not delete. Recovery is the last layer and must survive the loss of all the others.
• "Machine identities sit outside the layers." Service accounts, cloud roles and API keys often have the widest access and the least monitoring. Put them inside the identity and monitoring layers. See the Non-Human Identity (NHI) Guide.
• "Layers set once stay effective." Exceptions, disabled rules and unmonitored new paths erode depth quietly. Measure it.

Related concepts

Defence in depth builds on the CIA Triad Guide (what each layer protects), the Core Security Principles Guide (least privilege and fail-safe design), the Security Control Types Guide (mixing preventive, detective and corrective controls in every layer) and the Threat vs Vulnerability vs Risk Guide (deciding which paths deserve more layers). Related ideas include cyber resilience, which assumes compromise and focuses on continuing operations; see the Cyber Resilience Guide.

Practitioner checklist

• Map attack paths to each crown-jewel asset and list prevent, detect and recover controls on each.
• Require at least two independent controls before each crown jewel and detection behind every preventive control.
• Separate the administration of security layers (backups, EDR, SIEM, identity provider) from the production admin accounts they protect.
• Enforce phishing-resistant MFA on remote access and admin portals, and disable unused accounts automatically.
• Scope cloud roles and service accounts to least privilege and alert on bulk data access by machine identities.
• Ship logs to storage that production administrators cannot alter or delete, and measure log coverage.
• Keep at least one offline or immutable backup on separate credentials and test restores against RTO.
• Pilot new blocking controls in monitor mode, document rollback, and re-review layers after every major change.

Standards and references

• NIST: SP 800-53 Rev. 5 (PL-8(1) Defense in Depth, SC-29 Heterogeneity)
• NIST CSRC Glossary: Defense-in-Depth
• NIST: SP 800-207 Zero Trust Architecture
• NIST: Cybersecurity Framework 2.0
• CISA: #StopRansomware Guide
• NCSC: Zero trust architecture design principles
• NCSC: Offline backups in an online world
• MITRE ATT&CK: Valid Accounts

Related NHI Mgmt Group resources: CIA Triad Guide · Core Security Principles Guide · Zero Trust Identity Guide · Privileged Access Management Guide