Why vulnerability management is now a remediation race

At a glance

What this is: This is an analysis of why vulnerability management is failing as a remediation process, with exploited vulnerabilities, third-party exposure, and weak identity controls driving breach paths.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly own the access paths, ownership handoffs, and service identities that determine whether a known exposure becomes a breach.

By the numbers:

• Exploitation of vulnerabilities is now the top initial access vector for breaches, rising to 31% of the entire DBIR dataset.
• The DBIR says third-party involvement in breaches jumped 60% from last year’s dataset, reaching 48% of total breaches.

👉 Read Tonic’s analysis of why vulnerability management has become a remediation race

Context

Vulnerability management fails when discovery outruns remediation and ownership is unclear. The article’s core point is that teams can find more flaws than they can safely fix, while attackers keep using the same exposed systems, third parties, and identity weak points to enter.

For IAM and NHI programmes, that is not just a patching problem. Weak identity controls, service accounts, OAuth tokens, and third-party integrations often sit on the same path as the vulnerability itself, which means remediation has to cover both exposure and access governance.

Key questions

Q: What breaks when vulnerability management is limited to scan results?

A: Teams end up triaging large numbers of findings without knowing which ones can be chained into a working attack. That creates remediation noise, slows response to genuine exposure, and leaves identity, session, and workflow weaknesses under-prioritised until they are already being abused.

Q: Why do third-party connections make cybercrime harder to contain?

A: Third-party connections extend trust beyond the organisation’s direct control, which gives attackers more routes to reuse stolen credentials or approved access. If vendor accounts are not lifecycle-managed, a compromise can persist long enough for ransomware operators or extortion groups to move from entry to impact.

Q: How should teams prove that remediation actually reduced risk?

A: They should re-run the exposure test after the fix or mitigation, then compare the pre-change and post-change results for reachability, blocking, and alerting. If the path still works, the remediation is incomplete. If it no longer works, the team has defensible evidence for closure and audit review.

Q: Who should own vulnerability fixes that involve credentials or integrations?

A: Ownership should sit with the team that controls the affected asset and the connected identity path, not only the team that found the issue. When credentials, integrations, or administrative roles are involved, IAM, platform, and application owners must coordinate because the breach path crosses multiple control domains.

Technical breakdown

Why vulnerability discovery is not the same as risk reduction

Modern vulnerability management has three separate stages: detection, prioritisation, and remediation. Scanners are good at finding CVEs, but they do not resolve whether the vulnerable asset is internet-facing, tied to privileged access, or dependent on a third-party integration. That is why severity scores alone fail. A low-visibility dev box and a production system carrying customer data can share the same CVSS score but have very different breach potential. Effective programmes need ownership, dependency mapping, and exposure context before remediation queues become noise.

Practical implication: tie each finding to an owner, business process, and access path before it enters the remediation queue.

How third-party and identity exposures amplify vulnerability risk

Third-party risk turns a local weakness into a shared one. Vendors, contractors, SaaS tools, OAuth grants, service accounts, and API connections can all extend the attack surface beyond the asset that first looked vulnerable. In identity terms, the issue is not only whether a system is patched, but whether connected identities can be abused to move laterally or reach data through trusted paths. Once a third party has standing access or an unmanaged token, remediation must consider both the technical flaw and the trust relationship that makes exploitation valuable.

Practical implication: inventory third-party identities and revoke standing access where the business process does not require persistent trust.

Why remediation latency is now a control failure

The DBIR numbers show a classic control gap: organisations detect critical flaws, but median time to full resolution remains long enough for attackers to act first. That latency is not just an operations issue. It reflects handoff failure between security, IT, application owners, and business teams. In NHI-heavy environments, the same delay applies to secrets rotation, token revocation, and service account cleanup. If a vulnerability exposes credentials or an integration path, the window of abuse often stays open long after the ticket exists.

Practical implication: measure time-to-containment as aggressively as time-to-fix, especially for exposed credentials and connected service identities.

Threat narrative

Attacker objective: The attacker’s objective is to turn a known, unpatched weakness into trusted access that can be reused before defenders complete remediation.

1. Entry occurs through exploitation of a known vulnerability before remediation closes the gap, often on an exposed system or third-party-connected asset.
2. Escalation follows when the compromised host, token, or integration grants access to additional services, credentials, or higher-value data paths.
3. Impact comes from lateral movement, data access, or operational disruption that persists because ownership and remediation were too slow to contain the initial exposure.

NHI Mgmt Group analysis

Exploitability has become the governing metric, not vulnerability volume: the article shows why counting findings is no longer enough when attackers move faster than remediation queues. The real question is which exposed asset can be reached first, which identity can be abused next, and which business process depends on the path. That is a NIST CSF and MITRE ATT&CK problem as much as a scanning problem. Practitioners should treat exploitability, ownership, and access path as the primary prioritisation logic.

Remediation now depends on identity governance as much as patch governance: the article’s mention of weak identity controls is the critical bridge for IAM and NHI teams. Vulnerabilities increasingly matter because they expose service accounts, API tokens, OAuth grants, and privileged workflows that can be used after the original flaw is found. Exposure handoff failure: this is the governance gap where security teams know a weakness exists, but no one owns the connected identity path well enough to close it quickly. The implication is that vulnerability programmes must include identity lifecycle controls, not just infrastructure fixes.

Third-party risk is no longer a perimeter issue but an access-control issue: the DBIR’s rise in third-party involvement shows that supplier trust has become part of the attack path. When a vendor can touch production, customer data, or administrative workflows, the security outcome depends on access scope, token hygiene, and offboarding discipline. OWASP-NHI and NIST CSF both fit here because the question is not whether a partner exists, but whether its credentials and privileges are still valid. Practitioners should re-evaluate every external integration as a live identity relationship.

Security teams need a remediation model that reflects business dependency, not ticket order: the article is really about prioritisation failure under operational pressure. Fixing the highest CVSS score first is not the same as reducing breach probability first. Organisations need a named concept here: remediation drag, meaning the growing delay between issue discovery and effective containment. That drag widens the exploitation window across patching, secrets rotation, and third-party access reviews. Practitioners should optimise for the fastest reduction in real exposure, not the fastest ticket closure.

What this signals

The remediation gap will keep widening unless organisations connect vulnerability management to identity control points, especially service accounts, tokens, and vendor access. Remediation drag: the longer the handoff between discovery and containment, the more likely an attacker is to exploit the exposed path before ownership is resolved. That is why NIST Cybersecurity Framework 2.0 and MITRE ATT&CK remain useful reference points for prioritisation and response planning.

For IAM and NHI programmes, the next pressure point is cross-functional governance. Vulnerability teams cannot close what identity teams do not govern, and identity teams cannot secure what asset owners do not prioritise. The practical signal is whether your programme can revoke access, rotate credentials, and patch the exposure in one coordinated motion rather than three disconnected workflows.

The article’s broader message is that exposure management has become a business-logic problem. When systems, third parties, and identities are tightly coupled, the programme that wins is the one that can translate technical findings into a clear sequence of ownership, containment, and recovery before the adversary reaches the next trust boundary.

For practitioners

• Map vulnerabilities to access paths Link each critical vulnerability to the service accounts, API keys, OAuth grants, and admin roles that make it exploitable, then prioritise fixes where those identities can reach production or sensitive data.
• Shorten remediation by asset ownership Require every high-risk finding to have a named business owner, technical owner, and due date before it enters the backlog, so security is not waiting on an ambiguous handoff.
• Review third-party identities as part of vuln response When a vulnerability involves a vendor, contractor, or SaaS integration, reassess the connected credentials and revoke standing access that is not strictly required for the business process.
• Measure containment, not just detection Track how long it takes to reduce actual exposure after discovery, including patching, token revocation, and offboarding, because attack windows stay open until all three are complete.

Key takeaways

• Vulnerability management breaks when organisations count findings instead of reducing exploitable exposure across systems, identities, and third parties.
• The evidence points to a slower defence than offence, with critical remediation lag giving attackers a practical advantage.
• The control that changes outcomes is coordinated ownership across patching, access governance, and third-party trust, not scanning volume alone.

Key terms

• Remediation Drag: The delay between identifying an exposure and actually reducing the attacker’s ability to use it. It includes patch lag, ownership confusion, access revocation delays, and offboarding gaps. In practice, it is the period during which defenders know about a problem but the breach path remains open.
• Exposure Handoff Failure: A breakdown in the transfer of responsibility from discovery teams to the people who can close a risk. The finding may be accurate, but if no one owns the asset, the identity path, or the business dependency, the exposure persists. This is a governance failure, not a tooling failure.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.

What's in the full article

Tonic's full article covers the operational detail this post intentionally leaves for the source:

• How the Unified Exposure Management workflow links vulnerabilities to business context and ownership
• The platform’s approach to correlating alerts, assets, and exposures into a remediation queue
• Examples of how agentic AI is used to reason across fragmented security and business data
• Why the article argues for machine-speed remediation rather than manual handoffs

👉 Tonic’s full post covers the exposure-management workflow, third-party risk context, and remediation logic in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, secrets management, and workload identity. It helps practitioners connect access control decisions to the broader security programme that depends on them.