Skip to content
atlas

Defence in depth

Also known as: defense in depth, layered security

Stacking several independent layers of protection so that when one fails, the next one still stops the attacker.

Draft - this entry has not been reviewed yet.

Formal

A design principle that combines several different controls - technical, organisational and physical - at different points, so that no single failure leaves an asset unprotected.

In plain English

Like protecting a home with a locked gate, a locked door, an alarm and a safe for the valuables - a thief who gets past one still meets the next.

In practice

At a Danish shipping company, a phishing mail slips past the mail filter and a clerk clicks the link, but MFA stops the stolen password from being used and EDR on the laptop blocks the download.

Why it matters

Every control fails sometimes, so relying on just one means a single mistake is enough for a breach.

Technical deep dive

The idea is borrowed from military doctrine, where a defender trades space for time instead of holding a single line. In information security it was codified around 2000 in the US NSA's Information Assurance Technical Framework, which organised it around people, technology and operations, and today NIST SP 800-53 Rev. 5 includes it as control enhancement PL-8(1) under security and privacy architectures. The logic is probabilistic: if layers fail independently, the chance that an attack passes all of them is the product of the individual miss rates, so three layers that each stop 90 % of attempts together let through about 0.1 %.

Independence is the assumption that most often breaks. James Reason's Swiss cheese model (1990), originally from accident analysis, describes each layer as a slice with holes; incidents happen when the holes line up. Common-mode failures align them systematically: the same administrator credential that controls the firewall, the EDR console and the backup server; one vendor's product at several layers sharing a vulnerability; a single identity provider behind every login; or backups reachable from the domain that ransomware has already taken over. Real depth therefore means diversity of mechanism, administration and failure mode, not just a count of products.

A practical layering runs across prevention, detection and recovery as well as across location: governance and training, physical access, perimeter and email filtering, network segmentation, identity with MFA and least privilege, hardened and patched endpoints with EDR, application controls such as input validation and a WAF, data encryption and classification, logging and monitoring in a SOC, and offline or immutable backups with tested restores. The recovery layers matter because the model assumes some layer will fail; this "assume breach" stance also shapes the design of detection and incident response.

Defence in depth contrasts with perimeter security, the "hard shell, soft centre" model in which a single boundary firewall protects a flat, trusted internal network, so one foothold such as a phished laptop or a compromised VPN account gives broad lateral movement. Zero Trust, as described in NIST SP 800-207 (2020), is compatible with defence in depth but shifts the emphasis from network location to per-request authentication and authorisation of every subject and resource, effectively adding layers inside the network. The principal costs are complexity, operational overhead and alert fatigue; poorly integrated layers can create gaps between them, and each added layer is also added attack surface and an added thing to patch.

What to learn first

Everything this builds on, foundations first.

  1. CIA triad
  2. →Threat
  3. →Asset
  4. →Vulnerability
  5. →Impact
  6. →Likelihood
  7. →Risk
  8. →Security control
  9. →Defence in depth

Relationships

Don't confuse with
Perimeter security
Mitigates
Threat

Sources & further reading

Standards & official texts

Course material

  • Cyber Security Fast Track - Kursuskompendium, Modul 4

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queueSuggest a correction on GitHubThis term as JSON

Check yourself

Loading…

Atlas is in beta.