TL;DR: Vulnerability exploitation is now the most common known initial access vector, rising to 31%, according to Cogent, while only 26% of detected CISA Known Exploited Vulnerabilities were fully remediated and median time to full resolution reached 43 days. The control problem has shifted from finding exposure to proving closure fast enough to beat exploitation.
At a glance
What this is: Vulnerability management has become a remediation and verification problem because exploitation is now happening faster than teams can close exposed weaknesses.
Why it matters: IAM, PAM, NHI, and security teams need to treat exposure closure as an operational control, because unresolved weaknesses increasingly create the entry point for broader identity and environment compromise.
By the numbers:
- Vulnerability exploitation is now the most common known initial access vector for breaches at 31%, according to Cogent.
Context
Vulnerability management is the process of discovering weaknesses, prioritising what matters, and closing exposures before they are used. In practice, that model breaks when exploitability moves faster than triage, ownership, patch windows, and verification. The article’s key point is that the bottleneck is no longer detection alone, but verified remediation across assets that are reachable, business-critical, or controlled by other teams.
For identity and access programmes, the governance lesson is similar: discovery without closure does not reduce risk. When exploitable systems remain online, attackers can move from a technical weakness into credential abuse, privileged access, or lateral movement depending on what the vulnerable asset can reach. That makes remediation quality, ownership clarity, and proof of closure part of the security control, not just the workflow.
Key questions
Q: What breaks when vulnerability scanning produces more findings than teams can fix?
A: Remediation turns into a triage bottleneck. Teams spend time sorting noise instead of reducing risk, which means exploitable issues stay open longer and developers learn to distrust alerts. Once that happens, the security programme loses both velocity and credibility, even if scanning coverage keeps increasing.
Q: Why do reachable vulnerabilities create more risk than severity scores suggest?
A: Because exploitability depends on context, not just the label. A high-severity issue that is isolated or hard to reach may matter less than a moderate issue that is exposed, actively targeted, and connected to sensitive systems. The practical risk comes from whether an attacker can turn the weakness into initial access or movement in that environment.
Q: How do security teams know whether Teams remediation is working?
A: They should measure dwell time, removal latency, and the percentage of malicious messages removed before any user interaction. If detection is happening but content stays visible long enough to be clicked, the control is not effective enough. Audit trails should show fast, consistent containment.
Q: Should vulnerability remediation be coordinated with IAM and PAM teams?
A: Yes, when the vulnerable asset can reach privileged systems, automation, or sensitive integrations. In those cases, the impact of exploitation depends partly on what identities and access paths the asset can touch. IAM and PAM teams help reduce blast radius by reviewing privileges, service accounts, and downstream access that could turn one exposed system into broader compromise.
Technical breakdown
Why vulnerability management becomes a remediation bottleneck
Traditional vulnerability management assumes the main task is to find issues, assign severity, and queue fixes. That model fails when the limiting factor is no longer discovery but safe execution: the right owner may sit in another team, the fix may require downtime, and the asset may support dependencies that make immediate patching risky. In that environment, the operational question is not whether a finding exists, but whether it can be closed without creating new instability. This is why remediation throughput, not scan volume, becomes the governing metric.
Practical implication: Measure the process by closure rate and verified fix outcomes, not by how many findings the scanner produces.
How exploitability changes prioritisation logic
Severity scores alone cannot tell teams what to fix first when dozens of high-risk exposures compete for limited capacity. The article distinguishes between static labels such as KEV membership and the live question of whether attackers are using a weakness in the current environment. That means prioritisation has to combine external threat context with internal reachability, business criticality, ownership, and compensating controls. A vulnerability that is reachable and actively exploited is materially different from one that is technically serious but practically isolated.
Practical implication: Prioritise reachable, currently exploitable exposures using environment context, not severity and catalogue membership alone.
What verified remediation adds to the control chain
A scan can identify exposure, but it cannot prove that the issue is fixed, that the fix is safe, or that the weakness is no longer reachable. Verified remediation closes that gap by tying assignment, implementation, and validation into one controlled outcome. This is especially important where remediation spans multiple tools, teams, and environments, because a ticket can be closed long before the underlying exposure is actually removed. In governance terms, the control objective shifts from awareness to evidence of closure.
Practical implication: Require validation that confirms the exposure is gone before treating remediation as complete.
Threat narrative
Attacker objective: The attacker wants to turn an unremediated vulnerability into reliable initial access before defenders can close it.
- Entry occurs when attackers exploit a known vulnerability that remains exposed inside an organisation's environment.
- Escalation follows when the weakness provides a path into a reachable asset that can support deeper access or movement.
- Impact is realised when the unresolved exposure becomes the initial access point for a broader breach or ransomware event.
Breaches seen in the wild
- ShinyHunters FBI breach claim 2026: ShinyHunters claims it used a PeopleSoft flaw to breach the FBI and pivot into AWS GovCloud; the FBI has confirmed only an investigation.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Vulnerability management is now a closure discipline, not a discovery discipline. The article shows that organisations already know how to generate findings, but they struggle to convert those findings into verified risk reduction. That shifts the centre of gravity from scanner coverage to operational ownership, safe change execution, and proof that exposure is actually gone. Practitioners should treat remediation throughput as the primary control objective.
Verified remediation is the missing governance layer. A closed ticket is not the same thing as a closed exposure, and the article makes that distinction explicit. Once vulnerabilities are exploited faster than teams can resolve them, the security programme has to govern evidence of closure rather than paperwork closure. That is a process control issue as much as a technical one, especially where multiple teams and dependencies are involved.
Exposure debt is becoming the more useful operating concept than vulnerability count. The meaningful measure is how long exploitable weaknesses remain reachable after they are discovered, because that is the window attackers use. This reframes prioritisation from backlog size to unresolved attack surface, which is a better lens for both cyber risk and identity-adjacent compromise paths. Practitioners should map every open KEV-like exposure to an owner, fix path, and validation step.
Identity governance is implicated because remediation failures preserve attacker pathways into privilege. Once a vulnerable system stays exposed, the blast radius often depends on what identities, credentials, or integrations that system can reach. That means IAM, PAM, and NHI teams cannot stay outside vulnerability operations when exploitable assets front critical services or automation. The practical conclusion is that exposure closure and access governance need to be coordinated, not sequenced in isolation.
From our research library:
- Credential abuse across the entire attack chain, not just initial access, appears in 39% of all breaches, according to the 2026 Verizon Data Breach Investigations Report.
What this signals
Exposure debt is now a governance problem, not just an operations backlog. When exploitable weaknesses stay open for weeks, the programme is really managing a queue of attacker opportunities. The useful shift is to track closure latency by asset criticality and ownership, not just total open findings.
Remediation has to be validated at the point of closure. Teams that cannot prove the issue is gone are still carrying risk, even if the ticket is closed. That pushes vulnerability management closer to change control, where evidence of state matters more than intention.
The average time to mitigate a leaked secret is 36 hours, according to the 2024 State of Secrets Management Survey, which shows how quickly exposure windows can become operational burdens when closure is manual.
For practitioners
- Establish verified remediation as the closing control Do not treat ticket closure as remediation completion until validation proves the exposure is no longer reachable or exploitable.
- Prioritise by exploitability and reachability Combine threat intelligence, asset exposure, business criticality, and ownership so teams fix what attackers can actually reach first.
- Assign a named owner for every high-risk exposure Require a responsible team and a safe fix path for each exploitable vulnerability, including compensating control options where patching is delayed.
- Measure remediation throughput and validation lag Track how long exploitable findings remain open and how long validation takes after fix deployment so backlog health reflects real risk reduction.
- Coordinate vulnerability work with identity and privilege teams When a vulnerable asset can reach privileged systems, service accounts, or automation, review the access paths that would expand the impact of exploitation.
Key takeaways
- Vulnerability management now fails most often at the point where a finding must become a verified fix, not at the point of discovery.
- The article’s evidence shows that exploitability is outrunning remediation capacity, which leaves organisations exposed for longer than their control process assumes.
- The most effective response is to prioritise reachable exposures, assign clear ownership, and require validation before calling a vulnerability closed.
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 |
|---|---|---|
| MITRE ATT&CK | TA0001 — Initial Access | The article centers on exploited weaknesses becoming the entry point for breaches. |
| Recommendation — Map exposed vulnerabilities to initial access risk and prioritise fixes on reachable attack paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Remediation quality depends on who can reach the vulnerable asset and what it can access. |
| Recommendation — Review access paths around vulnerable assets so reachable exposures are fixed before they are exploited. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article is fundamentally about remediation throughput and validation for known weaknesses. |
| Recommendation — Operate continuous vulnerability management with ownership, prioritisation, and closure validation. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The article contrasts finding vulnerabilities with actually remediating and verifying them. |
| Recommendation — Pair vulnerability monitoring with verified remediation so findings do not remain open past exploitable windows. | ||
Key terms
- Verified Remediation: Verified remediation means a finding is only considered closed after the environment is rescanned and the issue is confirmed fixed. This matters because ticket closure alone does not prove risk reduction. Verification is the control that separates documented intent from actual security outcome.
- Exposure Debt: Exposure debt is the buildup of known but unresolved security risk when teams postpone remediation because systems are difficult to change safely. For legacy applications, it accumulates quickly when patching, refactoring, or replacement would disrupt core business operations.
- Remediation Throughput: Remediation throughput is the rate at which a team can fix validated security issues relative to the number being found. It is a practical measure of whether AppSec is actually reducing exposure, rather than merely increasing visibility into a growing backlog.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect access control, lifecycle governance, and operational risk across modern security programmes.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org