The programme breaks at the handoffs. Controls may exist, but if no one has mapped which identities, access paths, and attack stages each layer actually covers, attackers move through the uncovered spaces between teams, tools, and governance processes. Coverage has to be explicit before it can be trusted.
When Layered Defence Exists on Paper But Not in Coverage Maps
layered defence only works when each layer has a defined job and a defined boundary. The failure is not that controls are absent, it is that teams assume coverage without proving which identities, access paths, data flows, or attack stages each control actually reaches. Once that assumption goes untested, gaps are created at the seams, not just inside individual tools.
That is why coverage mapping matters more than the slogan of “defence in depth.” A mature programme makes handoffs explicit, so one team knows where its control stops and the next team knows what residual exposure it inherits. In practice, that means mapping control coverage to concrete attack paths and identity states, not to broad policy statements.
When the subject includes identity and access, the same principle applies to who can act, what they can reach, and which layer is supposed to stop misuse. Controls such as authentication, privilege restriction, session oversight, and logging can all exist, yet still leave a path open if nobody has traced how they overlap or where they do not. A useful reference point for that kind of attack-path mapping is MITRE ATT&CK Enterprise Matrix, which helps teams reason about the stages attackers chain together.
Why Handoffs Fail Even When Individual Controls Are Working
Most coverage gaps appear between ownership domains. A network control may block one route, an identity control may slow another, and a detection rule may trigger only after the attacker has already crossed a boundary. If those controls are not mapped together, each team can honestly report success while the combined environment still has an exploitable path.
This is especially dangerous when security work is organised by tool, not by path. One team may think it covers authentication failures, another may think it covers privilege misuse, and a third may think it covers anomalous movement after compromise. The attacker does not need any single control to fail, only a route that no one has explicitly assigned to a defender.
The most reliable way to expose this problem is to map coverage against specific scenarios and then compare that map with the operational boundary of each control. Defensive models such as MITRE D3FEND are useful here because they help translate attack behaviour into countermeasure coverage, which is exactly where handoff assumptions tend to break down.
Even mature programmes miss this because they treat coverage as a checklist rather than a relationship. A control can be “present” and still be irrelevant to the actual path an adversary uses. Once that happens, the organisation has a defence stack, but not a defence system.
What a Coverage Gap Means for Programme Design
A coverage gap is not just a missing control, it is a missed accountability decision. If no one owns the mapping from threat path to control layer, then no one owns the residual risk that remains after the individual tools do their jobs. That creates false confidence, especially when reporting focuses on deployment counts rather than attack-path completeness.
For practitioners, the important question is not “Do we have a control for this?” but “Do we know exactly which part of the path this control interrupts, and what happens if it does not?” That distinction drives whether a control belongs in prevention, detection, or response, and whether another layer must compensate for what it cannot see.
This is why control catalogues such as NIST SP 800-53 Rev 5 Security and Privacy Controls are most useful when they are tied to explicit coverage objectives, not treated as a generic list of good ideas. The same is true for the CIS Controls v8, which help prioritise safeguards but still require local mapping to actual attack exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001 — Initial Access | The question is about attack paths slipping through unmapped gaps between layers. |
| TA0004 — Privilege Escalation | Coverage gaps often let attackers move from partial access to higher privilege. | |
| Recommendation — Map exposed paths to ATT&CK techniques and close uncovered initial-access routes. Trace privilege-escalation paths and verify each step has a compensating control. | ||
| NIST SP 800-53 Rev 5 | CA-7 — Continuous Monitoring | Coverage gaps are often only visible when control coverage is monitored continuously. |
| Recommendation — Use CA-7 to validate that key controls still cover the active threat surface. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The page centers on missing coverage across identities and access paths. |
| Recommendation — Review access paths against CIS-6 and remove any unowned or unreviewed exposure. | ||
| NIST Zero Trust (SP 800-207) | 4.1 — Zero Trust security model | Zero Trust directly addresses the need to verify coverage at every trust boundary. |
| Recommendation — Apply Zero Trust principles to define and test each trust boundary explicitly. | ||
Practitioner Guidance
What to prioritise: Start with the highest-value handoffs, where one team’s control is expected to compensate for another team’s blind spot. Those seams usually expose the real programme weakness faster than reviewing controls in isolation.
What to verify: For each critical attack path, verify that at least one control covers prevention, one covers detection, and one team owns escalation when the first two fail. If you cannot name the owner of the uncovered segment, the gap is already operational.
Common mistake: Do not treat “we have multiple tools” as evidence of resilience. Multiple tools can still leave the same path uncovered if they all observe the same layer or depend on the same assumption.
Practitioner takeaway: Defence-in-depth becomes trustworthy only when coverage is mapped end to end, because the real failure mode is not control absence, it is undocumented gaps between controls.
Related resources from NHI Mgmt Group
- How should security teams identify hidden gaps in layered defence programs?
- How should security teams implement CSPM in multi-cloud environments without creating alert fatigue or gaps in coverage?
- How should security teams implement audit logging across infrastructure without creating gaps in coverage?
- How should security teams implement contextual access policies without creating coverage gaps across new applications and infrastructure?