Vulnerability exploitation overtakes credentials as the new entry point

At a glance

What this is: This analysis says vulnerability exploitation has overtaken credential abuse as the leading first foothold in breaches, with remediation of known exploited issues falling behind.

Why it matters: For IAM, PAM, and broader security teams, the shift matters because identity controls still matter across the kill chain, but initial access is increasingly being won through unpatched software and dependency exposure.

By the numbers:

• Verizon found that exploitation of vulnerabilities is now the most common initial access vector for breaches at 31% of the dataset.
• Credential abuse dropped to 13%, down from 22% the year before, according to Verizon’s analysis.
• Only 26% of the vulnerabilities on CISA’s Known Exploited Vulnerabilities list were fully remediated by organisations last year.
• Edgescan found that 45% of the vulnerabilities enterprises discover are still unpatched a year later, and roughly one in six of those is high or critical.

👉 Read Kusari's analysis of the DBIR shift from credential abuse to vulnerability exploitation

Context

Vulnerability exploitation has become the front door because many organisations still operate with incomplete software visibility and slow remediation cycles. That creates a governance problem as much as a technical one: if teams cannot see transitive dependencies, they cannot confidently say which systems are exposed, let alone close them quickly. The identity angle remains real, but it is now part of a larger access and exposure problem rather than the only first step.

In practical terms, this shifts priority from counting credentials and scanning for isolated CVEs to understanding reachability, blast radius, and dependency provenance. For identity programmes, the lesson is that access control can be strong at the perimeter and still fail if the underlying software estate is exploitable. That is not a temporary anomaly; it is the current operating pattern.

The starting position is typical for modern enterprises, not exceptional, because most software estates now depend on deeply nested third-party components and outsourced runtime paths.

Key questions

Q: What fails when vulnerability remediation is slower than AI-assisted exploitation?

A: Patch-first security fails when exploit generation outpaces validation, change control, and deployment. The practical failure is not that teams cannot detect issues, but that they cannot close exposure before an attacker can operationalise it. In that environment, containment and blast-radius reduction become the only controls that still work reliably.

Q: Why does software visibility matter more when initial access comes from vulnerabilities?

A: Because teams cannot fix or defend what they cannot identify. If the vulnerable component sits in a transitive dependency, build artefact, or deployed image, a simple app scan will miss the real exposure. Visibility turns vulnerability management from a guess into a governable process and shortens the time between disclosure and remediation.

Q: How do security teams know whether vulnerability assessment is actually working?

A: Teams should look for short triage cycles, high-confidence findings, and a clear link between scan results and remediation action. A working programme reduces uncertainty around what to fix first. If the same issues keep reappearing or the queue is dominated by false alarms, the tool is not helping governance.

Q: How should organisations connect vulnerability management to identity and access controls?

A: Treat identity controls as containment for when software prevention fails. Strong PAM, service account governance, and segmentation limit how far an attacker can move after initial exploitation. That does not replace patching, but it reduces the blast radius and gives security teams a second line of defence when a flaw is already in the wild.

Technical breakdown

How exploited vulnerabilities become the first foothold

An exploitable vulnerability gives an attacker an entry path that bypasses authentication controls entirely. Instead of stealing a password or token, the attacker uses a flaw in exposed software, a library, or a service endpoint to execute code, access functionality, or trigger unintended behaviour. In modern environments, the issue is rarely just one application. The real exposure often sits in transitive dependencies and cloud-facing services, which means the affected component may not be obvious from a simple package list or vulnerability scan. That is why initial access is now as much a software supply chain problem as a patching problem.

Practical implication: maintain software inventory from source to runtime so exposed components are identifiable before exploitation begins.

Why remediation lags matter more than vulnerability counts

Counting CVEs tells you how many issues exist, but not whether attackers can use them before you act. Remediation lag is the more important control variable because it measures the time window between disclosure, exploitation, and closure. When known exploited vulnerabilities remain open for weeks, attackers can industrialise that gap faster than most teams can drain the backlog. The report’s pattern reflects a structural mismatch: attackers compress time using automation and AI-assisted discovery, while defenders still rely on manual triage, ticket queues, and fragmented ownership across application, cloud, and security teams.

Practical implication: prioritise by exploitability and reachability, not raw CVE volume, and measure closure time as a security outcome.

Why software supply chain visibility now drives exposure management

Once the first foothold comes from software exploitation, the key question becomes whether you can prove where vulnerable code exists. That requires visibility into direct dependencies, transitive dependencies, build artefacts, and the runtime environment that actually executes them. Traditional scanning often stops at the obvious layer and misses nested packages or deployed images that no longer match the source tree. This is where software supply chain governance meets security operations: without a living map of components and versions, organisations cannot reliably answer exposure questions during a zero-day window.

Practical implication: build a live dependency graph and connect it to remediation workflows so exposure questions can be answered in minutes, not days.

Threat narrative

Attacker objective: The attacker wants to turn a disclosed software flaw into rapid, pre-remediation access that opens the way to lateral movement or data theft.

1. Entry occurs through exploitation of a public-facing vulnerability rather than stolen credentials, giving the attacker a direct first foothold.
2. Escalation follows when the vulnerable service or dependency permits code execution, privilege gain, or access to adjacent systems.
3. Impact comes from persistent compromise, lateral movement, or data theft before remediation can close the exposed path.

NHI Mgmt Group analysis

Identity is no longer the only front-door problem, but it remains central to what happens after entry. The report shows that exploitable software flaws now lead initial access, yet identity controls still determine whether the compromise stays local or turns into broad enterprise access. That makes IAM and PAM a downstream containment layer, not the sole entry defence. Practitioners should treat identity governance and software exposure management as linked control planes.

Exposure visibility has become a governance control, not just a technical hygiene task. If transitive dependencies and deployed artefacts are invisible, remediation is guesswork and accountability breaks down across engineering, security, and operations. This is the kind of control gap that turns vulnerability management into backlog management. Practitioners should demand source-to-runtime visibility as a governance requirement.

Remediation lag is now the measurable failure mode behind most exploit-based breaches. The problem is not simply that vulnerabilities exist, but that the closure window is long enough for attackers to industrialise it. In framework terms, this aligns closely with NIST-CSF continuous monitoring and vulnerability management expectations, and with MITRE ATT&CK techniques tied to initial access and exploitation. Practitioners should track time-to-remediate as a board-level risk metric.

Dependency blindness is the new exposure trap. The article’s strongest warning is that organisations often do not know where exploitable code lives until after disclosure. That assumption fails because modern software estates are assembled from layers of third-party components that move faster than periodic scans. Practitioners should build a living dependency map and tie it to exploitability-based prioritisation.

Identity governance still matters, but it now sits inside a wider access-to-exploitation chain. Once attackers enter through software, the next question becomes whether privileged accounts, service identities, or weak segmentation let them expand. That is where NHI governance, PAM, and least privilege can limit blast radius even when prevention fails. Practitioners should align identity controls to containment, not just authentication.

What this signals

Dependency visibility is becoming the next operational control plane for security teams. When attackers can reach software faster than defenders can remediate it, the deciding factor is whether the organisation already knows where the vulnerable components live. That pushes security leaders to combine software inventory, exposure management, and identity containment into one operational workflow, not three separate programmes.

Zero Trust assumptions weaken if exploitability is not part of the access model. Continuous verification does not help if the first compromise comes through an exposed service or dependency that was never in the access review scope. The practical response is to tie exposed software, privileged paths, and service identities to the same risk view so blast radius is reduced even when prevention fails. See the NIST SP 800-53 Rev 5 Security and Privacy Controls control catalog for how access, audit, and integrity controls fit together.

Remediation speed is now a competitive security metric, not an internal housekeeping measure. If known exploited vulnerabilities remain open for weeks, the organisation is operating inside an attacker-friendly window. The implication for readers is straightforward: measure closure time by asset class, route the highest-risk items into automated handling, and make the backlog visible enough to drive ownership rather than excuse it.

For practitioners

• Build source-to-runtime exposure visibility Track direct and transitive dependencies, container images, and deployed artefacts in one inventory so teams can answer where a vulnerable component exists before remediation starts.
• Prioritise by exploitability and reachability Replace CVE counts as the main queue driver with a model that scores whether the issue is reachable, internet-exposed, or already in KEV, then route only those items into urgent remediation.
• Measure remediation as a time-based control Set explicit targets for time to close KEV-listed issues and track drift by application owner, because long-tail closure windows are where exploitation wins.
• Link identity containment to software exposure Review whether privileged access, service accounts, and weak segmentation can turn a software flaw into broad access, then tighten those paths before the next disclosure cycle.

Key takeaways

• The breach-entry story has shifted from stolen credentials to exploited software flaws.
• Remediation lag is the control failure that turns disclosed vulnerabilities into active compromise windows.
• Identity governance still matters, but it now works best as blast-radius control after software exposure has already occurred.

Key terms

• Initial Access: Initial access is the first successful entry point an attacker gains into a target environment. In application security, that foothold often comes from an unpatched flaw rather than a stolen password, which is why exploitability and exposure time matter as much as control coverage.
• Transitive Dependency: A transitive dependency is a package or component that your software depends on indirectly through another dependency. These hidden layers matter because vulnerabilities often live deeper in the tree than standard scans or manual reviews typically cover, making them easy to miss until exploitation begins.
• Known Exploited Vulnerability: A Known Exploited Vulnerability is a flaw that has confirmed active exploitation in the wild and is tracked for urgent remediation. In governance terms, KEV status turns patching from a general hygiene task into a time-bound operational obligation.
• 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.

What's in the full article

Kusari's full analysis covers the operational detail this post intentionally leaves for the source:

• How Kusari maps the AI-accelerated vulnerability storm to a specific remediation playbook
• The source article's reachability-based prioritisation logic for deciding which flaws to fix first
• Why Kusari argues for a living dependency graph across the full software estate
• The vendor's framing of autonomous remediation and how it changes response timelines

👉 Kusari's full post covers the remediation backlog, dependency exposure, and response model in more detail.

Deepen your knowledge

The 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 identity controls to the broader security programme that surrounds them.