Vulnerability exploitation overtakes credentials as the new entry point

At a glance

What this is: Kusari argues that the latest Verizon DBIR marks a pivot from credential-led intrusion to vulnerability-led initial access, with exploitable weaknesses now the dominant entry point.

Why it matters: IAM teams still need to govern credentials, but this shift means vulnerability exposure, software inventory, and remediation speed now directly shape the identity attack surface.

By the numbers:

• Vulnerability exploitation became the most common initial access vector at 31% of breaches, according to Kusari.
• Credential abuse dropped to 13%, according to Kusari.

Context

For security and identity programmes, the important shift is not just that attackers are using different entry points. It is that the primary access problem now sits earlier in the software lifecycle, where exposure, reachability, and patch latency determine whether a weakness becomes an incident.

That changes how identity teams should think about control boundaries. Credentials remain important, but an exploitable application or dependency can bypass otherwise sound authentication controls and create a direct path into systems that hold identities, secrets, and privileged access.

The article frames this as a change in the attacker's front door, but the deeper governance issue is visibility into software exposure and the speed of closure once a weakness is known. That makes the topic relevant to both vulnerability management and identity security leadership.

Key questions

Q: What breaks when vulnerability exploitation becomes the main breach path?

A: When vulnerability exploitation overtakes credential abuse, the organisation can no longer rely on identity controls alone to stop initial access. The weak point is often an exposed VPN, web app, or third-party tool that bypasses login defences entirely. Security teams need exposure management, rapid patch prioritisation, and asset visibility to close that gap before attackers use it.

Q: Why does slow remediation increase the chance of a cyber incident becoming a breach?

A: Slow remediation leaves known weaknesses exposed long enough for attackers to find and abuse them. The longer a vulnerability, misconfiguration, or insecure credential remains unresolved, the larger the window for compromise, data theft, and service disruption. Remediation reduces that exposure window, helping organizations contain risk before an attacker can turn a discovered issue into an operational incident.

Q: What are the signs that vulnerability management is not working well enough in an enterprise?

A: Common warning signs include long remediation cycles, weak visibility into where vulnerabilities exist, and inconsistent prioritisation of high-risk findings. If teams keep repeating the same issues, rely on ad hoc reports, or lack a clear treatment path, the programme is probably underperforming. Another signal is when vulnerabilities are discovered only after attackers or audits surface them.

Q: How should security teams respond when a supply chain compromise exposes management tooling and privileged access paths?

A: Start by assuming the compromised tooling may have exposed more than software. Identify every asset it monitored or managed, then validate patches, credentials, certificates, internet exposure, and unexpected configuration changes. Prioritise the attack surface that gives an attacker the easiest route back into the environment, because management platforms can become force multipliers for lateral movement and persistence.

Technical breakdown

Why initial access shifts when exploitability beats credentials

Initial access is the first foothold an attacker gains in an environment. When exploitation of vulnerabilities outranks stolen credentials, the practical security model changes from preventing logins alone to reducing the number of externally reachable weaknesses that can be turned into a foothold. That matters because authentication controls only help after a request reaches an identity boundary. If an internet-facing service, dependency, or API is exploitable, the attacker may never need to steal a password or token at all. In modern estates, this often includes third-party code and transitive dependencies, which makes visibility a prerequisite for control.

Practical implication: Track exposed assets and exploitable dependencies as part of access risk, not just vulnerability hygiene.

Why remediation lag matters more than scan volume

A scan tells you what exists at a point in time. Remediation tells you whether the organisation can actually close risk before exploitation. If known exploited vulnerabilities remain open for weeks, the control failure is not discovery alone but the gap between identification, prioritisation, and closure. That gap widens in complex software estates because teams inherit issues from libraries and package chains they did not choose directly. Reachability and exploitability are the right filters because they identify which flaws can be used now, not which ones merely exist on paper. This is where governance becomes operational.

Practical implication: Prioritise closure based on exploitability and reachability, not raw vulnerability counts.

How software supply chain exposure becomes an access problem

Software supply chain exposure means the risky component is often not the application your team owns, but a nested dependency several layers deep. That creates an access problem because the vulnerability may sit in a component that is invisible in traditional top-level inventories, yet still reachable by attackers through a public-facing service. Identity and privilege controls do not disappear in this model, but they are no longer the only gatekeepers. If the dependency tree is not continuously known, teams cannot answer the first question that matters during a new disclosure: are we exposed, and where?

Practical implication: Build continuous dependency visibility so exposure questions can be answered before exploitation starts.

Threat narrative

Attacker objective: Gain reliable initial access through a reachable flaw and use that foothold to expand into higher-value systems or data.

1. Entry occurs through an exploitable vulnerability rather than stolen credentials, giving the attacker a foothold without needing valid login data.
2. The attacker uses that weakness to access the affected service or dependency path, bypassing controls that would normally guard authenticated entry.
3. Once inside, the attacker can pivot toward sensitive systems, secrets, or privileged functions that were reachable from the vulnerable component.
4. The impact is breach, data exposure, or deeper compromise driven by a software weakness that remained open longer than its exploitation window.

Breaches seen in the wild

• Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.

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-led intrusion is now a governance problem, not just a patching problem. When exploitable flaws become the leading entry vector, the security question moves upstream into software inventory, dependency knowledge, and closure speed. That affects identity programmes because an exposed application path can undermine otherwise well-governed credentials, sessions, and privileged access. Practitioners need to treat exposure management as part of access governance, not a separate hygiene function.

Continuous remediation is the real control gap in modern exploit risk. The article's numbers point to a failure of operational throughput: finding weaknesses is no longer the hard part, closing them before exploitation is. That is especially true where transitive dependencies and cloud-native release cadence create a moving target. The governance lesson is that vulnerability management must be measured by time-to-closure and reachability, not backlog size alone.

Dependency visibility is the new prerequisite for exposure control. The named concept here is dependency exposure blindness, where organisations cannot see the nested components that actually carry exploitable risk. This is a software supply chain issue, but it also intersects with NHI and IAM because services, APIs, and workloads often authenticate through those same dependency layers. Practitioners should assume that unknown dependencies expand the attack surface faster than scan tools can flatten it.

Identity remains relevant, but it is no longer the single front door. Credential abuse still matters, yet this shift shows that attackers will take the easiest viable path, whether that is an exposed service, a vulnerable library, or a stolen login. That means identity governance and vulnerability governance have to be coordinated. The practical conclusion is to align access controls with exposure management so control ownership follows the actual attack path, not the org chart.

Reachability and exploitability are the right prioritisation lens for the next phase of defence. A vulnerable component that cannot be reached is not the same risk as one exposed on an internet-facing path. That distinction is why broad CVE counting underperforms in fast-moving estates. Practitioners should use risk-based remediation to focus attention on flaws that are both present and reachable, because that is where attacker value concentrates.

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

Dependency exposure blindness: the next control failure is often not the vulnerability itself, but the organisation's inability to see where it sits in nested software paths. When the exploitable component is buried several layers deep, scan coverage alone cannot answer whether the risk is real or merely theoretical.

For practitioners, the operational question is whether exposure management now sits alongside identity governance in the same risk conversation. If a public service, dependency chain, or API can be exploited before a credential is ever used, then access control and vulnerability control are part of the same defence story.

For practitioners

• Map reachable exposure across the full dependency tree Inventory top-level and transitive dependencies so teams can answer whether a vulnerable component is actually reachable from exposed services.
• Prioritise remediation by exploitability Use exploit signals, reachability, and internet exposure to rank issues ahead of raw CVE counts or scan age.
• Shorten the close-out cycle for KEV-listed issues Set tighter service-level targets for known exploited vulnerabilities so findings move from discovery to verified closure faster than the current 43-day median.
• Align identity and vulnerability workflows Make sure access governance teams and vulnerability teams share a view of the systems, services, and dependencies that can be used as entry points.

Key takeaways

• The article's core point is that attackers now more often enter through exploitable software weaknesses than stolen credentials.
• The remediation evidence is worrying because known exploited vulnerabilities are still closing too slowly for the pace of exploitation.
• Teams that can see dependency reachability and close exploitable issues faster will be better placed to reduce breach entry risk.

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.
• 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.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• 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.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course covers NHI governance, secrets management, and workload identity in the context of broader identity security. It helps practitioners connect access control, lifecycle governance, and operational risk across modern identity programmes.