What signals show that a vulnerability management programme is not working?

Why This Matters for Security Teams

A vulnerability management programme can look busy while still failing to reduce exposure. The real test is whether findings are eliminated, verified, and kept from reappearing on the same systems. When teams measure success by ticket volume or headline MTTR alone, they can miss weak ownership, poor retesting discipline, and exceptions that quietly become permanent risk.

This matters even more when vulnerabilities affect identity-rich environments, where exposed secrets, service accounts, and CI/CD paths turn one missed fix into repeated compromise. NHI Management Group’s Ultimate Guide to NHIs notes that 91.6% of secrets remain valid five days after notification, which is a strong signal that remediation processes often do not close the loop. That is why mature programmes tie triage, repair, and verification together instead of treating discovery as the finish line. The baseline for operational discipline also aligns with the NIST Cybersecurity Framework 2.0, which emphasises outcomes over activity. In practice, many security teams discover programme failure only after the same exposures keep resurfacing on the same assets.

How It Works in Practice

Working vulnerability management is a closed loop: discover, prioritise, remediate, verify, and trend. Weak programmes usually break at one of those steps. They may discover issues quickly, but do not route them to the right asset owner. They may assign deadlines, but never confirm the fix. Or they may accept exceptions without expiry dates, so unresolved risk accumulates across patch cycles.

Security leaders should look for signals that show whether the process is actually reducing exposure:

• Repeated findings on the same hosts, containers, accounts, or applications after a “fixed” status is recorded.
• High-risk issues that sit open across multiple remediation windows, especially when internet-facing or privileged systems are involved.
• MTTR that improves while recurrence stays flat, which suggests ticket throughput rather than risk reduction.
• Weak retesting discipline, where closure is based on ticket updates instead of independent verification.
• Exception sprawl, meaning compensating controls are used so often that they become the default path.

For identity and secrets exposure, the bar is higher because vulnerabilities can persist through cloned pipelines, embedded tokens, and stale credentials. The Top 10 NHI Issues highlights how overlooked NHI hygiene can multiply downstream risk, especially when remediation does not include rotation or revocation. Current guidance suggests measuring not only days-to-fix, but also days-to-verify, recurrence rate, and the percentage of findings that reopen within 30 to 90 days. Teams should also map the programme to CISA cyber threat advisories when active exploitation changes prioritisation. These controls tend to break down in heavily outsourced environments because ownership gaps and shared tooling make verification ambiguous.

Common Variations and Edge Cases

Tighter remediation governance often increases operational overhead, so organisations must balance speed against certainty. That tradeoff is real: insisting on verification, retesting, and aging reviews can slow closure, but it also prevents false confidence.

Not every open vulnerability means the programme is failing. Long-lived issues can be acceptable when compensating controls are strong, exploitability is low, and the risk decision is explicit. The problem starts when exceptions are undocumented, never reviewed, or used repeatedly for the same control gaps. Best practice is evolving for cloud-native and agentic environments, where ephemeral assets make traditional asset-based reporting less reliable. In those cases, guidance suggests tracking remediation by workload identity, pipeline, and secret lifecycle, not just by server name.

Another edge case is “green” dashboards that hide recurrence. If the same misconfiguration reappears after autoscaling, image rebuilds, or CI/CD redeployments, the issue is usually in the build and release process, not the scanner. That is why programme health should include control failure patterns, not just severity counts. The NHI Lifecycle Management Guide is useful here because it frames rotation, offboarding, and revocation as recurring operational controls rather than one-time cleanup. Mature teams also use the Ultimate Guide to NHIs to support audit-ready evidence. A programme usually breaks down when exceptions become permanent and verification is treated as optional.

Related resources from NHI Mgmt Group

• What signals show that SOX control remediation is working?
• What signals show that renewal management is not working?
• What signals show that SaaS license management is working?
• Who should own vendor risk management in an identity programme?