Verizon DBIR shows privilege paths matter more than patching

At a glance

What this is: This analysis argues that the 2026 Verizon DBIR shifts attention from initial access to privilege escalation, showing that permissions and configurations often matter more than patches once an attacker is inside.

Why it matters: IAM, PAM, and NHI teams need to treat privilege paths as a primary control surface because low-privilege footholds can still reach high-value accounts even when patching is mature.

By the numbers:

• Exploitation of vulnerabilities took the top spot at 31% of breaches, up from 20% the year before.
• In nearly a fifth of organizations, an attacker with low-level privileges had an 80% or better chance of reaching a key administrative account.
• Patches address about 10% of escalation techniques, while privilege management covers a whopping 65%.

👉 Read XM Cyber's analysis of the 2026 Verizon DBIR and privilege escalation

Context

Verizon’s 2026 DBIR changes the breach conversation by showing that initial access is only the first problem. The report says exploitation of vulnerabilities was the top breach entry vector at 31%, but the more important finding is what happens after access is gained: attackers often move through permissions, configurations, and trust relationships that patching does not touch.

That distinction matters to IAM, PAM, and NHI programmes because many environments still optimise for vulnerability remediation while leaving privilege pathways under-mapped. Once a low-privilege account can traverse groups, delegation chains, or over-permissioned service accounts, the real control failure is governance of access structure, not software hygiene.

Key questions

Q: How should security teams reduce privilege escalation risk in identity systems?

A: Start by analysing effective privilege across users, service accounts, and shared credentials. Remove dormant elevated access, tighten role scope, and review combinations of permissions that create admin-like control. The goal is to shrink the entitlement gaps attackers can already find, not to rely only on detection after access has been abused.

Q: Why do patched environments still experience privilege escalation?

A: Because patching only addresses one slice of the problem. If permissions, configurations, and trust relationships remain broad, an attacker can escalate without another exploit. In practice, the identity layer often determines whether compromise stays local or becomes administrative.

Q: What do teams get wrong about privileged access management?

A: They often treat PAM as a product purchase rather than a governance and operating-model change. If the workflow does not fit how IT and Security collaborate, the organisation ends up with partial coverage, weak usage, and privileged accounts that remain too easy to abuse.

Q: Who is accountable when privilege pathways let an attacker reach admin access?

A: Accountability sits with the programme that owns identity governance, not only the team that patches systems. IAM, PAM, and cloud platform owners must answer for reachable admin paths, excessive trust, and access structures that make escalation possible.

Technical breakdown

Attack graph analysis turns identity relationships into exploit paths

Attack graph analysis models the environment as connected identity and access nodes: users, groups, permissions, delegations, and trust links. Instead of asking only how an attacker gets in, it traces the possible routes from a foothold to a high-value target. That approach exposes choke points where one over-permissioned account, nested group, or misconfigured delegation can enable many escalation paths. The key insight is that identity structure itself becomes the attack surface. If the graph is dense and poorly governed, low-privilege access can become administrative reach without another vulnerability being required.

Practical implication: Map privilege relationships as attack paths, not just entitlements, and prioritise the nodes that collapse multiple routes.

Why patching does not stop privilege escalation

The DBIR’s escalation data shows that most post-entry privilege gains are not driven by vulnerabilities. In other words, the attacker often does not need a new exploit after the door is open. They need an already existing path through permissions, configurations, password practices, and trust settings. This is why patching is necessary but not sufficient. A well-patched estate can still be structurally weak if the identity layer grants broad access, inherited rights, or excessive delegation. The problem is architectural, not merely remedial.

Practical implication: Balance patch programmes with access path reduction so remediation effort reaches the control layer that actually enables escalation.

Privilege management is the control that changes the escalation curve

Verizon’s breakdown attributes far more of escalation mitigation to privilege management than to patches. That means controls such as least privilege, group hygiene, delegation cleanup, and high-value account protection have a much bigger effect on the attacker’s route than vulnerability closure alone. For NHI, this matters even more because service accounts and tokens often accumulate standing access over time. For human IAM, the same logic applies to dormant roles, inherited groups, and mis-scoped admin paths. The control question is whether a low-privilege identity can grow into a high-impact one without a deliberate approval boundary.

Practical implication: Treat privilege management as a primary risk-reduction programme and measure how many escalation paths each change removes.

NHI Mgmt Group analysis

Privilege path exposure is the real breach multiplier. The DBIR’s attack graph framing shows that once an attacker reaches a low-privilege account, the environment itself may already contain a route to admin-level access. That is not a patching failure alone, it is a permissions design failure that allows one foothold to fan out into broad control. Practitioners should read this as a governance problem, not just a detection problem.

Patch-first remediation misallocates effort when escalation is permission-driven. The report’s own breakdown shows patches cover only a small slice of escalation techniques, while privilege management covers far more. That means many programmes are optimising the wrong queue of work and measuring the wrong form of progress. The practitioner conclusion is simple: if privilege pathways remain open, patch completion metrics will flatter the programme without reducing blast radius.

Identity blast radius is now a measurable design concept. The 16% of organisations with roughly 80% exposure is the clearest signal in the report because it shows how a small number of access relationships can dominate organisational risk. This is exactly where IAM, PAM, and NHI governance meet: the same over-permissioned account, nested group, or delegated trust path can serve as a highway for both human and non-human identities. Teams should treat blast radius as an architectural property of identity design.

Standing access and inherited trust remain the escalation substrate for NHIs and humans alike. Service accounts, API keys, and human admin roles all become dangerous when they can move laterally through pre-existing trust. The DBIR reinforces a core NHIMG position: the attack is often not the exploit itself, but the access topology that follows it. Practitioners should focus on where access persists, inherits, or amplifies beyond its original purpose.

From our research:

• Strong NHI governance remains uneven: From our research: Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Our research also found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes delegated identity paths hard to govern.
• For a broader remediation lens, review Top 10 NHI Issues to see where visibility, rotation, and privilege controls break down.

What this signals

Identity blast radius is now a programme metric, not just a breach after-action term. If an attacker with low privilege can still reach a key administrative account, your IAM and PAM stack is reporting control completion without proving control containment.

The next maturity jump is not more patching cadence, it is tighter graph visibility across human and non-human identities. The same delegated access patterns that weaken admin governance also weaken service account governance, especially in cloud estates where inherited permissions are easy to miss.

For practitioners

• Build an identity attack graph Model users, groups, service accounts, delegations, and high-value accounts as connected paths so you can see which footholds can reach crown-jewel access. Use the graph to identify choke points where one remediation closes many routes rather than one.
• Prioritise privilege-path reduction Review nested groups, inherited roles, over-permissioned service accounts, and mis-scoped admin delegations first. Remove or constrain the access relationships that create the widest escalation surface, especially where low-privilege identities can traverse into administrative control.
• Separate patch metrics from exposure metrics Track patch completion, but do not confuse it with risk reduction. Add measures for reachable admin accounts, excessive trust links, and identities that can cross privilege boundaries without a deliberate approval step.
• Put NHI privilege hygiene on the same footing as human admin control Apply the same scrutiny to service accounts, tokens, and workload identities that you apply to privileged human roles. Standing access in non-human identities can create the same escalation routes as human over-privilege, especially in cloud and hybrid environments.

Key takeaways

• The DBIR’s most important shift is not the top entry vector, it is the proof that escalation paths often outlast the exploit.
• Attack graphs make privilege relationships visible, and that visibility shows why broad trust and inherited access can be more dangerous than unresolved patches.
• Practitioners should measure reachable admin paths and privilege-path reduction, because those controls speak directly to whether breach impact can expand.

Key terms

• Action Graph: The set of actions an autonomous system is permitted to sequence, combine, and execute. Unlike static permission lists, an action graph captures what the actor can actually do at runtime, which is why it matters when agents can chain tool use into outcomes no human explicitly approved.
• Privilege path: A privilege path is the route an identity uses to move from ordinary access to sensitive systems, data, or administrative functions. It can involve accounts, tokens, roles, or delegated permissions, and it often determines whether a vulnerability becomes a real incident.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

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

• The DBIR attack graph interpretation behind the 16% of organisations with about 80% exposure
• The patching, password, configuration, and privilege-management breakdown that explains escalation control coverage
• The reasoning behind the argument that patching alone cannot close privilege routes after initial access
• The discussion of how route prioritisation changes remediation strategy across real environments

👉 XM Cyber's full article expands the DBIR findings into attack graphs, exposure routes, and remediation priorities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or identity governance programme, it is worth exploring.