Known vulnerabilities still drive major breaches because attackers exploit the gaps organisations already understand but have not remediated fast enough. The issue is rarely discovery alone. It is the delay between knowing a weakness exists and reducing the access, privilege, or exposure that makes it exploitable.
Why This Matters for Security Teams
Known vulnerabilities remain one of the most reliable paths to breach because exploitation is operationally simple once a weakness is public and an internet-facing asset has not been fixed, isolated, or monitored. Security teams often focus on vulnerability discovery and reporting, but attackers care about exposure windows, reachable services, and whether compensating controls exist. The practical question is not whether a flaw is documented, but whether it is still exploitable in the environment. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that remediation, access control, and continuous monitoring are part of the control problem, not separate activities.
This matters even more when attackers automate discovery and targeting. Public proof-of-concept code, mass scanning, and AI-assisted reconnaissance reduce the time between disclosure and exploitation. In environments with exposed edge devices, legacy services, or unmanaged identity paths, the breach often follows a failure to reduce blast radius, not a failure to know the CVE exists. In practice, many security teams encounter the compromise only after the vulnerability has already been weaponised, rather than through intentional risk reduction.
How It Works in Practice
Breaches usually happen when a known flaw sits in a reachable system long enough for an attacker to find it, test it, and move through it before remediation lands. The control challenge is broader than patching. It includes asset inventory, exposure management, privileged access reduction, compensating safeguards, and detection tuned to likely exploitation patterns. Where systems cannot be patched quickly, organisations need to remove the path to exploitation by restricting network reachability, limiting privileges, and increasing monitoring.
A useful operational sequence is:
- Identify the affected asset and determine whether it is actually exposed to the threat actor.
- Prioritise by exploitability, internet exposure, business criticality, and privilege impact.
- Apply the fastest available mitigation, such as isolation, configuration hardening, or access restriction.
- Patch or upgrade on a risk-driven schedule, not just a calendar schedule.
- Verify remediation with rescans, logging, and incident detection.
For teams using AI-assisted operations, the risk window can shrink quickly because attackers can triage targets faster, chain exploitation steps, and adapt payloads at scale. That is one reason current guidance increasingly treats vulnerability management as part of broader cyber resilience rather than a standalone hygiene exercise. Research on Anthropic — first AI-orchestrated cyber espionage campaign report is a reminder that automation changes the speed and volume of attacker decision-making, even when the underlying weakness is familiar.
These controls tend to break down when organisations have poor asset visibility across cloud, on-premises, and third-party environments because they cannot confirm what is exposed, privileged, or already in use.
Common Variations and Edge Cases
Tighter patch governance often increases operational overhead, requiring organisations to balance rapid remediation against uptime, testing depth, and change-control constraints. That tradeoff is especially sharp for OT, legacy platforms, and customer-facing services where a rushed fix can be as disruptive as the vulnerability itself.
Best practice is evolving on how much compensating control is enough when patching is delayed. Current guidance suggests there is no universal standard for this yet: some environments can rely on isolation, WAF rules, or privileged access reduction, while others need immediate shutdown of the exposed service. The right answer depends on exploitability, not just severity score.
Edge cases also arise when vulnerabilities affect identity infrastructure, automation tooling, or machine-to-machine credentials. If a flaw exposes secrets, tokens, or service accounts, the issue becomes an access-control incident as much as a software defect. That is why NHI governance matters alongside conventional patching. A vulnerable workload that can mint credentials, call internal APIs, or trigger automated actions may create a faster breach path than a user-facing system with the same CVE.
Security teams should also watch for cases where a patch exists but cannot be safely deployed because of version coupling, vendor dependencies, or certification constraints. In those situations, the acceptable response is not silence. It is documented risk acceptance, temporary containment, and continuous verification until the exposure is removed.
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 NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-12 | Known vulns persist when remediation processes are too slow or inconsistent. |
| MITRE ATT&CK | T1190 | Exploitation of public-facing applications is a common breach path for known CVEs. |
| NIST AI RMF | GOVERN | AI-assisted attack speed changes how organisations should govern remediation risk. |
Build a repeatable remediation workflow that tracks, patches, verifies, and escalates overdue vulnerabilities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
