TL;DR: Security teams often run 30+ controls, yet default configurations only cover roughly 70% of known threats, leaving a proof gap between expected protection and demonstrated resilience, according to Cymulate. The practical shift is from static coverage and dashboards to continuous validation, remediation, and re-testing against real attacker techniques.
At a glance
What this is: This is an analysis of why security programmes that measure coverage still fail to prove control effectiveness, with Cymulate arguing that continuous validation is the missing operating model.
Why it matters: It matters because IAM, NHI, and broader security teams cannot manage risk credibly if they only know what tools are deployed, not what attacks those controls actually stop.
By the numbers:
- The average enterprise runs 30+ security controls, according to Cymulate.
- Default configurations protect against roughly 70% of known threats, according to Cymulate.
Context
Security programmes often accumulate tools faster than they can prove control effectiveness. The practical gap is not whether a control exists, but whether it demonstrably blocks the techniques that matter in a specific environment. That distinction matters across IAM, PAM, NHI governance, and adjacent security domains because ownership, scope, and validation all drift when proof is replaced by assumption.
Cymulate frames this as a proof problem rather than a visibility problem. The argument is relevant to identity security because controls around access, privilege, and workload credentials are frequently assumed to work once deployed, while actual resistance to attacker techniques is rarely re-tested after environment change. The result is a governance gap between documented coverage and evidenced resilience.
Key questions
Q: What is the first thing security teams should do when control coverage is high but proof is weak?
A: Start with one control family that protects a high-value asset, then test it against the attack techniques most likely to matter in your environment. The first goal is not a larger dashboard but a defensible answer to what the control actually blocks. Once you have that baseline, improve the weakest link and re-test to confirm the gap is closed.
Q: Why does a strong control inventory still leave organisations exposed?
A: Because inventory shows what is deployed, not what is actually stopped under real conditions. A control can be present, healthy, and compliant while still failing against a specific attacker path. Exposure remains when teams confuse configuration evidence with operational proof, especially where compensating controls and identity dependencies are part of the chain.
Q: What are the signs that a validation program is losing control?
A: Common signs include duplicated testing across platforms, findings that never reach an owner, repeated remediation on the same control, and inconsistent results from different tools. Those symptoms usually mean the organisation has added detection capacity without establishing a single operating model for triage, ownership, and retesting.
Q: Should organisations prioritise continuous validation over adding more tools?
A: Yes, when the main problem is uncertainty about what existing controls really stop. Adding tools can expand coverage, but it does not close the proof gap unless the new control is also tested against the techniques that matter. The better sequence is to validate, improve, and only then decide whether a new tool is actually needed.
Technical breakdown
Why coverage metrics do not prove control effectiveness
Coverage tells you a control exists and is configured, but not whether it stops a specific attacker technique in your environment. In practice, security stacks often combine preventive, detective, and compensating controls whose interactions are rarely validated together. A dashboard can show deployment health, policy status, or alert volume while still missing whether an adversary can move from initial access to impact. Continuous validation closes that gap by testing real techniques against the actual control chain, not a lab assumption or vendor promise.
Practical implication: Treat coverage as a starting point and verify control behavior against real attack techniques before you rely on it.
The risk-to-fix gap and why it widens
The risk-to-fix gap is the time between learning a threat exists and proving your defenses can handle it. That window widens when teams depend on periodic assessments, generic test cases, or delayed remediation cycles. The longer the gap stays open, the more likely a known weakness becomes an exploitable path. For identity and access controls, the problem is sharper because privilege, credentials, and entitlements can change faster than review and patch workflows can keep up.
Practical implication: Measure the time from threat awareness to validated protection, not just the time to ticket creation or control review.
Validate, improve, prove as an operating loop
A mature programme does not stop at testing. It validates a specific technique, improves the relevant control or detection, then re-tests to confirm the gap has closed. That loop creates evidence leadership and auditors can trust because it ties remediation to observed reduction in exposure. This is especially relevant where identity-bound access, service credentials, or privileged workflows are part of the attack surface, because those paths often require proof at issuance, authentication, and response points, not just at audit time.
Practical implication: Build a repeatable test-remediate-retest cycle for the control paths that matter most to your environment.
NHI Mgmt Group analysis
Control proof is becoming the real security currency: the industry has moved far enough beyond simple deployment counts that the next governance question is whether a control demonstrably stops the technique it is supposed to stop. That is a different standard from configuration compliance or tool coverage, and it changes how boards, auditors, and security leaders should assess resilience. The practitioner conclusion is straightforward: evidence of blocked technique matters more than inventory of installed controls.
Risk-to-fix gap is the more useful failure concept than alert fatigue: many programmes already know they have findings, but they cannot prove which ones translate into exploitable risk right now. That creates a governance lag where exposure is documented but not operationally understood, especially when identity or credential paths are involved. The practitioner conclusion is to prioritise proof of exploitability over volume of findings.
Identity controls need runtime proof, not just lifecycle paperwork: access reviews, entitlement records, and PAM policies can look strong on paper while real attacker techniques still succeed through standing privilege, stale credentials, or compensating-control blind spots. The article’s logic applies directly to NHI governance because service accounts and workload credentials are often assumed secure once provisioned. The practitioner conclusion is to validate access paths continuously, not only during review cycles.
Continuous validation is the named operating model shift: the article is really describing a move from static assurance to validate, improve, prove. That concept is useful because it captures the discipline required when attack surfaces change faster than control baselines. The practitioner conclusion is to make re-testing a required part of control change, not an occasional exercise.
Evidence-based resilience will reshape security accountability: teams that can show what their controls block, how quickly gaps close, and whether risk actually drops will have a stronger governance position than teams reporting tool counts or compliance status. This does not replace existing frameworks, but it does change how those frameworks should be evidenced in practice. The practitioner conclusion is to align assurance reporting with tested defensive outcomes, not activity metrics.
What this signals
Continuous proof is becoming a governance requirement, not an optional assurance exercise: programmes that cannot demonstrate what controls stop are effectively managing by assumption. That is a weak position for boards, auditors, and identity teams that must justify where risk is reduced and where it remains.
Validate, improve, prove is the right operating concept for modern control assurance: it captures the shift from static reviews to measurable resilience. For teams managing IAM, NHI, and privileged access, the key change is to test whether controls still hold after change, not only whether they existed at deployment time.
For practitioners
- Implement continuous control validation Test the controls that matter in your environment against real attacker techniques, then re-test after every material change to prove the gap is closed.
- Prioritise technique-level proof for high-risk controls Focus first on EDR, email security, SIEM, and identity controls where a failed assumption creates immediate business risk, and document what each one actually stops.
- Shorten the risk-to-fix window Measure the time between identifying a threat and validating effective protection, not just the time to create tickets or complete reviews.
- Build evidence trails for auditors and leadership Record each validate, improve, prove cycle so governance teams can see which attack techniques were tested, what changed, and what evidence supports the result.
Key takeaways
- The central problem is not control absence but proof absence, because many organisations cannot show which attacker techniques their existing controls actually block.
- The article’s scale argument is that default configurations protect against roughly 70% of known threats, yet the remaining exposure is often unverified and operationally misunderstood.
- The practical response is continuous validation, followed by targeted improvement and re-testing, so resilience is evidenced rather than assumed.
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 CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | The article is about proving controls through ongoing validation rather than static assessment. |
| RC.RP-01 — Response Planning | The validate, improve, prove loop depends on repeatable remediation and re-test cycles. | |
| Recommendation — Use DE.CM-01 to validate whether controls continue to perform as expected after environment change. Align remediation workflows to RC.RP-01 so fixes are followed by re-validation, not just closed tickets. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Evidence-based assurance depends on trustworthy records of what was tested and what changed. |
| Recommendation — Use CIS-8 to retain validation evidence that shows which controls were tested and when gaps were closed. | ||
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | The article’s core theme is assessing whether controls actually work in practice. |
| Recommendation — Apply CA-2 to move from periodic checklist assessment to evidence-backed control testing. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's testing model is grounded in proving defenses against attacker techniques. |
| Recommendation — Map validation scenarios to TA0006 and TA0008 so you can test the attack paths most likely to bypass controls. | ||
Key terms
- Callback Validation: Callback validation is the set of checks performed when the federated identity flow returns to the application. It confirms that the response came from the expected flow, belongs to the correct organisation, and can be exchanged safely for a local session. Weak validation creates a direct path from successful authentication to misissued access.
- Risk-to-fix Gap: The time and operational distance between discovering a weakness and making the control change that reduces it. The wider the gap, the more opportunity exists for attackers to exploit known exposures before remediation becomes effective.
- Continuous Resilience Validation: Continuous Resilience Validation is the practice of automatically testing whether identity recovery actually works before an incident occurs. It turns recovery from a theoretical plan into a verified capability by exercising rollback, failover, and restoration paths and producing auditable proof for assessors and operational leaders.
- Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to operational evidence and stronger security decisions.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org