A breach program is likely missing key threats when it focuses narrowly on external attacks but does not test internal, contractor, and supply chain scenarios. Weak coverage also shows up when teams do not regularly exercise phishing resistance or unauthorized credential use. If incident data is not being used to refine testing, the program is probably underestimating realistic attack paths.
What the program is failing to test
A breach program misses the most likely threats when its scenarios stay too close to perimeter intrusion and ignore how attackers actually get value after entry. The gap is usually not a lack of scenarios, but a lack of variety: internal misuse, contractor access, third-party paths, and stolen credentials are the pathways that often convert an initial foothold into impact. That is especially true when identity and access abuse are not exercised as first-class attack paths, rather than assumed to be covered indirectly.
Program coverage also goes stale when it does not reflect the incidents already happening in the organisation. If prior events, near misses, help desk abuse, phishing outcomes, or leaked credentials are not feeding back into test design, the program will keep rehearsing low-probability stories and miss the attacks that are more repeatable in that environment.
For evidence-based threat modelling, the pattern is familiar in breach analyses that centre on stolen access, exposed secrets, and third-party compromise, such as The 52 NHI breaches Report and the attack-path examples in Snowflake breach. External threat context from CISA cyber threat advisories helps keep scenario design aligned to active adversary tradecraft.
Why weak coverage usually shows up in practice
One sign is structural blindness: the program tests one attack family repeatedly, but not the relationships that attackers use to move laterally, borrow trust, or reuse valid access. Another sign is imbalance between “security theatre” and measurable resistance, for example where phishing simulations exist but credential misuse, token theft, and contractor trust paths are rarely exercised. Supply chain and third-party exposure are another common blind spot because they sit outside the comfort zone of purely internal control testing.
When the program is weak, teams often confuse control presence with control resilience. A control can exist on paper yet still fail under credential replay, delegated access, exception handling, or a compromised vendor path. That is why breach testing needs to probe how access is obtained, not just whether a control exists.
That logic aligns with the broad attack patterns documented in OWASP API Security Top 10 for authorisation failure and in the MITRE ATLAS adversarial AI threat matrix for abuse of delegated tooling and trust. If your breach program never tests identity abuse or supply chain ingress, it is probably testing the wrong boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Phishing resistance is a core test area for realistic breach paths. |
| T1078 — Valid Accounts | Unauthorized credential use is a major indicator of missed breach paths. | |
| T1199 — Trusted Relationship | Contractor and supply-chain scenarios hinge on trusted access paths. | |
| Recommendation — Exercise phishing scenarios and verify users resist credential capture. Test and detect abuse of valid accounts across internal and third-party access. Validate trusted-relationship assumptions with scenarios that include third-party access. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | A breach program should be continuously updated from observed incidents and likely threats. |
| ID.RA — Risk Assessment | Scenario coverage should reflect realistic attack paths and likely compromise methods. | |
| DE.CM — Continuous Monitoring | Monitoring and incident learnings should inform what the breach program tests next. | |
| Recommendation — Use incident feedback to refresh threat scenarios and testing priorities. Assess which threat paths are most plausible and test those first. Feed monitoring and incident data into scenario updates and validation. | ||
| CIS Controls v8 | 6 — Access Control Management | Testing must include misuse of credentials, contractors, and trusted access. |
| 15 — Service Provider Management | Third-party and supply-chain scenarios are central to missed breach coverage. | |
| Recommendation — Review access paths and test for abuse of legitimate credentials and entitlements. Include vendor access paths and service-provider scenarios in breach exercises. | ||
Practitioner Guidance
What to prioritise: Rebuild scenario coverage around the paths most likely to produce real loss, then map each scenario to a concrete compromise method such as phishing, stolen credentials, contractor misuse, vendor access, or token theft. If a scenario cannot be tied to a believable entry path, it is probably too abstract to tell you much about breach readiness.
What to verify: Check whether recent incidents, alert investigations, and help desk exceptions have been translated into new tests. If the same scenario appears every quarter while actual investigations tell a different story, the program is measuring consistency, not relevance. Use that mismatch as the signal to refresh the threat set.
Practitioner takeaway: The strongest breach program is not the one with the most scenarios, but the one that keeps testing the attack paths your environment actually makes easy to succeed.
Related resources from NHI Mgmt Group
- What are the signs that an LLM evaluation program is missing real-world failure modes?
- What are the signs that a generative AI red teaming program is missing important risks?
- What are the signs that a phishing attempt is likely to succeed or has already been accepted?
- What are the signs that publish-time malware scanning is missing known supply chain threats?
