---
{
  "title": "Defense in depth",
  "summary": "Use complementary protections so one failure does not decide the outcome.",
  "topic": "foundations",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: An Introduction to Information Security",
      "url": "https://csrc.nist.gov/pubs/sp/800/12/r1/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Defense in depth uses multiple safeguards across people, processes, and systems. The purpose is to reduce dependence on one control, not to accumulate tools. Layers should address different failure modes and work together. Identity restrictions, network boundaries, monitoring, and recovery planning each contribute differently. If every layer relies on the same compromised account or the same unmanaged configuration, the apparent depth may disappear when that dependency fails.

## In practice

A phishing attempt might be limited by message filtering, employee reporting, phishing-resistant authentication, limited permissions, and detection of abnormal account activity.

## A common misunderstanding

Buying several similar products is not necessarily defense in depth. Shared blind spots can survive across them.

## Check your understanding

Why keep detection if prevention is strong?

**Think it through:** Preventive controls can fail or be bypassed, and detection helps reduce the time and harm before response.

## Choose layers for different failures

A fictional engineering firm worries about account takeover. It uses phishing-resistant authentication, limited application permissions, alerts for unusual exports, and a documented response process. These layers address different stages: preventing credential misuse, limiting authority, noticing harmful activity, and restoring rightful control. Their relationship matters more than the number of security products installed.

Examine shared dependencies. If one administrator account can disable authentication protections, erase logs, and delete backups, several apparent layers may fail together. Likewise, two monitoring tools reading the same incomplete log source can share the same blind spot. A diagram should show common authority and data dependencies as well as individual controls.

Depth also requires operational ownership. An alert with no responder is not a dependable detective layer. A recovery procedure that has never been exercised is uncertain corrective capacity. Define who maintains each safeguard, what failure it addresses, and how its operation is verified.

## Walk through a control failure

For the engineering example, assume one preventive control fails in a tabletop exercise. Ask what the attacker or mistaken user can do next, what evidence appears, and which independent safeguard limits the consequence. Repeat with a monitoring failure and with an unavailable administrator. The exercise should reveal gaps rather than force the architecture to appear successful.

More layers can also create complexity, delay, and conflicting configuration. Select controls for meaningful coverage and maintainability, not maximum accumulation. Document residual risk when a failure path remains. A useful defense-in-depth design explains how the organization continues protecting its important assets after a realistic individual safeguard fails, and provides evidence that the remaining safeguards work under those conditions.

## Keep exploring

- [[security-controls]]
- [[least-privilege]]
- [[logs-and-telemetry]]
- [[backups]]