What it means
Defense in depth uses multiple safeguards to reduce the chance that one failure leads directly to serious harm. The layers may prevent entry, restrict what a compromised account can reach, detect misuse, or support recovery. The goal is a reasoned combination of protections with different jobs and failure modes.
Independence matters. Two controls that depend on the same unprotected administrator account may fail together. More tools can also create operational complexity without adding meaningful protection. Start with a realistic harmful scenario, identify how it could progress, and place controls where they can interrupt or limit that progression.
The idea at a glance / Access
Different controls. Different jobs.
A stolen valid session does not settle reachability or export permission. Keep the network block, application refusal, and written record separate.
Fictional controlled test: a client already on the contractor VLAN has stolen testbench session (reference SS8) for YD-7. Network rule N4, application policy P7, and protected record storage cannot be administered with YD-7’s permissions.
READ THE PICTURE
Read what still holds
Stolen session SS8 is still valid. Network N4 blocks the admin-API probe. A separate testbench export request reaches the app, but policy P7 refuses it. The testbench writes denial record R44. That record alone does not establish an alert or investigation.
Keep in mindThis fixture tests two restrictions after session theft. It does not prove that every layer is independent or every attack is contained. A written denial is not an alert or an investigation, and the account in it does not identify the current human.
Read the complete example
- Read what still holds. Stolen session SS8 is still valid. Network N4 blocks the admin-API probe. A separate testbench export request reaches the app, but policy P7 refuses it. The testbench writes denial record R44. That record alone does not establish an alert or investigation. These are controlled snapshots on 25 September 2026, UTC. SS8 is an internal reference for linking events, not the secret that lets a browser use the session. The stolen session secret is neither drawn nor logged. Session SS8 remains valid and maps to testbench account YD-7; theft of a session does not mean its authentication algorithm failed, and the service cannot infer the current human from that session alone. The test client is already on the contractor VLAN; VPN entry is an assumption, not a sign-in demonstrated here. At 10:00:00, probe A targets Testbench’s admin API. Network rule N4 prevents that connection, so the API’s own authentication and authorization are untested. At 10:00:05, separate request B asks the testbench to export Pad 3. N4 permits network traffic to the testbench. Application policy P7 grants YD-7 only view and scan at Pad 3 during the Friday 09:00 inclusive to 14:00 exclusive window; it denies export before files are returned. The testbench writes R44 with event time 10:00:05 UTC, session SS8, account YD-7, requested action export, resource Pad 3, policy P7, and result denied. Writing that record neither blocks the request nor establishes detection, delivery to a reviewer, or incident status. Separate administrators own N4, P7, and protected records in this fixture; the compromised account cannot change them. That assumption must be tested in an actual deployment. The remaining controls have distinct jobs and limit two specific paths; other actions, interfaces, common dependencies, and recovery are outside this picture.
This fixture tests two restrictions after session theft. It does not prove that every layer is independent or every attack is contained. A written denial is not an alert or an investigation, and the account in it does not identify the current human.
Diagram references: NIST SP 800-12 Rev. 1 - integrated security and control interdependencies · NIST SP 800-53 Rev. 5 - AC-6, SC-7, AU-3, AU-9, and CM-6 · OWASP Authorization Cheat Sheet · OWASP Session Management Cheat Sheet - session hijacking
AN ILLUSTRATIVE SCENARIO
A charity finance account
A charity protects its finance application with stronger authentication. It also limits each account's permissions, requires a second person for sensitive payment changes, and reviews unusual activity. If an account session is stolen, authentication alone may no longer block its use, but scoped permissions and transaction approval can still limit damage. Protected records and tested recovery procedures support investigation and restoration. The team checks that the same person cannot quietly disable every layer using the compromised account.
Put it to work
- Describe a credible path from initial failure to business harm, then identify where prevention, restriction, detection, and recovery controls can help.
- Map the dependencies of each layer, including administrative accounts, identity services, logging, and backup access; look for common failure points.
- Exercise a safe scenario in which one layer fails, and verify that the remaining layers produce the expected restriction, alert, or recovery result.
How to check your work
Document what still works when a selected control is unavailable or bypassed in a controlled test. The result should identify remaining protections and dependencies, rather than merely list installed products.
Connect the ideas
- Control
A process, configuration, or technology meant to reduce a named risk or detect a named failure.
- Least privilege
Granting each identity only the actions, objects, and time window required for the current job.
- Residual risk
The risk that remains after implemented safeguards, including uncertainty in its assessment.
- Blast radius
How much additional loss a failure or a response action can cause beyond the original asset.