Phishing, stolen credentials, insider misuse, cloud misconfiguration: the list hasn't changed in a decade, and neither has the spending aimed at it. What keeps it alive isn't the entry techniques. It's the access waiting on the other side of every one of them.
Every year, the same list resurfaces: phishing, stolen credentials, unpatched software, insider error, cloud misconfiguration, third-party compromise. The percentages shift by a few points; the list itself hasn't meaningfully changed in a decade, despite a decade of investment aimed directly at it. That persistence is worth taking seriously, because it suggests the list is describing something other than what actually needs fixing.
The list is a classification by entry vector: how the attacker (or the mistake) got in. It is not a classification by what happened next, which is the part that actually determines whether an incident is a contained anomaly or a breach that makes the news. And what happens next is almost always the same story: a compromised identity, credential, or misconfigured permission turns out to carry far more access than the task in front of it required, and the incident's scope is set by that excess, not by the entry technique.
This piece works through the causes that show up most consistently across IBM, Verizon DBIR, and incident response data, not capped at an arbitrary five, and asks the harder question for each: not "how did they get in," but "why did what they got in with reach so far." The pattern that emerges is that six of the seven causes below are, underneath the entry vector, the same access failure. The seventh is genuinely different, and the difference is instructive.
The Convergence, Stated Plainly
An attacker phishing a helpdesk credential, an insider misusing a role they've outgrown, a service account with a leaked API key, a vendor with standing admin access, a cloud IAM role with excessive permissions: none of these share an attack technique. All of them share a precondition. In each case, the identity involved held more standing access than its actual, current, verified need justified, and the breach's size was determined by that gap, not by the cleverness of the entry.
This isn't a claim that entry-vector defenses don't matter. Phishing-resistant MFA, patch cadence, and cloud posture scanning all reduce the probability of initial compromise, and probability reduction is real value. But entry-vector defenses have a ceiling: they can only ever address the technique of the day, and techniques evolve faster than any filter can be tuned. Access governance addresses something that doesn't evolve: the size of the blast radius once any technique succeeds. That's the argument this piece makes across seven causes.
The Causes, Examined for What's Underneath
1. Phishing and Social Engineering
Phishing remains the most common delivery mechanism for initial access, and generative AI has removed the tells (poor grammar, generic framing) that used to make it detectable. Deepfake vishing, AI-personalized spear phishing, and adversary-in-the-middle attacks that intercept live authentication sessions have all made the entry technique materially harder to stop at the perimeter.
What phishing actually delivers, though, is never data directly. It delivers a credential, or a session token, or a moment of trust that gets an attacker inside one account. The MGM Resorts incident in 2023 is the clean illustration: the technique was a ten-minute LinkedIn lookup and one phone call to a helpdesk, not a sophisticated exploit chain. What turned that single social-engineering success into an estimated $100 million incident wasn't the phone call. It was what the compromised helpdesk-reset access could subsequently reach.
The identity question phishing prevention doesn't answer: if this specific credential is phished tomorrow despite every control, what can the attacker do with it? For most organizations, the honest answer is "far more than the phished user's actual job requires," which is a least privilege failure sitting underneath a phishing statistic.
2. Stolen, Weak, or Reused Credentials
Credential abuse remains a leading initial access vector, and the scale of exposed credentials on the dark web (billions of unique password-and-username pairs from cumulative breach dumps) makes credential stuffing a near-zero-cost attack for anyone willing to run it. Attackers don't need to break anything; they need to try a large number of already-known passwords against enough logins until one works.
The Change Healthcare breach in 2024, the largest healthcare data breach in U.S. history, began with a single compromised credential on a remote access portal that had no MFA enabled. No exploit, no zero-day: a valid username and password. The technique was the simplest one on this entire list. The scale of the resulting breach was a function of what that one account could reach once inside.
The identity question credential hygiene doesn't answer: password managers and MFA reduce the odds of theft. Neither one limits what a stolen credential is worth once theft succeeds, which is a function of the account's standing privileges and how quickly orphaned or dormant access is caught rather than left live indefinitely.
3. Unpatched Software and System Vulnerabilities
This is the one genuine exception on the list, and it deserves to be treated as one rather than forced into the identity frame. A vulnerability is a flaw in software, not an access failure, and the growing speed of exploitation (median time from disclosure to active exploitation now measured in days, not weeks) is a patching and asset-inventory problem that identity governance does not solve.
But look at what determines a vulnerability's actual damage once exploited, and the identity question returns. Log4Shell and the MOVEit Transfer exploitation by the Cl0p group both worked by giving an attacker code execution or file access on a system; what that access could then reach, laterally, was determined by the standing privileges and network reach of the compromised process or service account, not by the vulnerability itself. MOVEit alone touched over 2,000 downstream organizations, largely through the file transfer service's own broad access to the data it was trusted to move.
The honest framing: patching prevents the entry. Least privilege on the compromised system's service accounts, plus segmentation of what any single compromised process can reach, determines whether a successful exploit stays local or becomes a headline. The vulnerability is the one cause here that isn't identity-caused. Its blast radius still is.
4. Insider Threats and Human Error
This cause is definitionally an access problem, and it's covered in full depth in our dedicated insider threat cluster, so this section stays brief by design. The short version: whether the insider is malicious, negligent, or compromised, the harm flows entirely through access the organization granted, and the access, not the intent, is the one variable fully within the organization's control.
The Tesla 2023 incident (two former employees leaking data on over 75,000 individuals) and the Cash App/Block breach in 2022 (a former employee downloading customer reports using access that outlived their employment) are both, at the mechanism level, departure-window failures: access that should have ended on the last working day didn't.
5. Cloud Misconfiguration and Excessive Permissions
Publicly exposed storage buckets, over-permissive IAM roles, and "admin by default" cloud configurations are usually described as a configuration problem, fixable with posture-management tooling. That's true as far as it goes, but the more consequential half of this cause is what excessive permissions do after a misconfiguration or compromise: an over-permissive IAM role doesn't just risk exposure of the bucket it was meant to guard, it hands an attacker who lands anywhere in the environment a path to move laterally through everything that role can reach.
Excessive IAM permissions are, definitionally, a standing-privilege problem: the cloud-native expression of the same "admin rights nobody scoped down" failure that shows up in SaaS applications, infrastructure, and human roles alike. The fix (least privilege on every IAM role, time-bound elevation instead of standing admin roles, and coverage of the non-human identities that hold most cloud permissions) is identical in structure to the fix for insider threats and credential abuse, applied to machine identities.
6. Third-Party and Vendor Access
Third-party involvement in breaches has been rising, and the mechanism is consistent: a vendor's compromise becomes the organization's breach because the vendor was granted standing access broader than the specific integration required. The Okta support-system breach in 2023 propagated to downstream customers, including MGM and Caesars, through session tokens the support system held; the Ledger breach in 2020 traced to a third-party payment partner's database, not Ledger's own systems.
Vendor risk management is usually framed as a due-diligence exercise: questionnaires, certifications, contractual clauses. Those matter, but they address the vendor's security posture, not the organization's own exposure to that posture. The actual control is architectural: vendors should hold time-limited, narrowly scoped access to exactly what the integration requires, not standing administrative reach, so that a vendor's compromise (which the organization cannot control) has a bounded effect on the organization's own environment (which it can).
7. Standing and Excessive Privileged Access
This is less a distinct entry vector than the mechanism that makes every cause above worse, which is why it belongs on the list explicitly rather than as a footnote to the others. An account, human or non-human, that holds admin rights it uses rarely, but holds continuously, is the multiplier sitting underneath phishing, credential theft, cloud compromise, and insider misuse alike: it's what turns "an attacker got a foothold" into "an attacker got the environment."
Zero standing privilege exists as a target precisely because of this multiplier effect: an environment where elevated access is granted on demand and expires automatically has no standing admin credential sitting around waiting to be phished, stolen, or misused, regardless of which of the six causes above delivers the initial compromise.
Why the List Persists Despite a Decade of Investment
If the underlying failure is this consistent, why hasn't a decade of security spending closed it? Because most investment has gone into entry-vector defense, phishing filters, patch automation, endpoint detection, precisely the layer that has to be rebuilt every time attacker technique evolves. Access governance, by contrast, is a structural property that doesn't need to be rebuilt when the technique changes, because it doesn't depend on recognizing the technique at all. A well-governed access surface contains a novel attack method exactly as well as a familiar one, because containment was never about recognizing the attack.
This is also why breach cost and breach duration correlate so strongly with detection speed rather than attack sophistication. The organizations with the lowest breach costs aren't the ones facing less capable attackers. They're the ones where a successful compromise, whatever technique delivered it, lands on an identity that can't reach very far.
What an Identity-First Response Actually Requires
Treating access as the convergent cause changes what "breach prevention" means in practice, and it's a materially different program than an entry-vector checklist:
Least privilege as a maintained state, not a policy statement. Every identity, human and non-human, scoped to current role and continuously checked against drift. Covered in full in our least privilege guide.
Elevated access that expires by default. Standing admin rights converted to on-demand, time-bound grants, shrinking the multiplier effect that turns any single compromise into an environment-wide one. See our JIT access and zero standing privilege guides.
Lifecycle automation that closes the departure window. Access revoked completely and immediately when the need ends, across every application, not just the ones behind SSO.
Non-human identities governed with the same discipline as humans. Service accounts, API keys, and vendor integrations scoped, owned, and time-bound, since they hold a growing majority of standing access in modern environments and receive a fraction of the scrutiny.
Segregation of duties as a structural limit. No single identity, compromised or malicious, able to complete the most damaging actions alone. See our segregation of duties coverage.
Continuous verification over periodic certification. Access reviewed as drift happens, not once a year, which is the identity-layer expression of zero trust applied to the question this whole piece is about: not whether a request should be trusted once, but whether the access behind it should still exist at all.
None of this replaces entry-vector defense. Patch management, phishing-resistant authentication, and cloud posture scanning still reduce how often something gets in. But they cannot be the whole program, because they defend against yesterday's technique while access governance defends against tomorrow's, by never depending on recognizing it in the first place.
Frequently Asked Questions
What is the most common cause of data breaches?
By initial entry vector, compromised or stolen credentials and phishing remain the most cited causes across industry breach reports. But entry vector is not the same as root cause: underneath most breach categories, including credential theft, insider misuse, cloud misconfiguration, and third-party compromise, the actual determinant of breach severity is how much standing access the compromised identity held beyond what its current task required.
Is unpatched software also an identity problem?
Not at the point of entry; a vulnerability is a software flaw, and patching remains the correct fix for the entry itself. But the damage a successfully exploited vulnerability causes is governed by identity: what the compromised process or service account can reach afterward. Two organizations hit by the identical vulnerability can have completely different outcomes based entirely on how tightly the compromised system's access was scoped.
Why do insider threats and external attacks trace back to the same root cause?
Because both ultimately depend on what an identity, whether it's a legitimate insider or an attacker who has taken over an account, is permitted to do. An insider's own access and a phished or stolen credential's access are governed by identical controls: least privilege, time-bound elevation, and segregation of duties. The distinction between "insider" and "external attacker" matters for detection and response; it doesn't matter for the access architecture that limits what either one can do.
Does fixing access governance mean an organization can deprioritize entry-vector defenses like MFA and patching?
No. Entry-vector defenses reduce how often a compromise happens; access governance reduces how much damage any given compromise causes once it happens. They're complementary layers, not substitutes. An organization with excellent MFA and patch cadence but standing admin access everywhere is one successful phishing email away from a severe breach. An organization with excellent access governance but no MFA will simply get compromised more often, even if each compromise is contained.
How does non-human identity access factor into data breach causes?
Increasingly heavily. Service accounts, API keys, and third-party integrations now outnumber human identities in most environments, typically carry broad, standing scopes, and are excluded from the access reviews built for human accounts. Several major breaches in this list, including cloud misconfiguration and third-party compromise incidents, trace their actual blast radius to over-permissioned non-human identities rather than to the human account initially targeted.
.webp)
.svg)
