Cloud Security

AWS, Azure, and Google Cloud’s Shared Responsibility Gap Drove 61% of Enterprise Breaches in 2024

By NeuralWired Cybersecurity Desk  |  June 28, 2026  |  9 min read

A contract that splits security duties between a cloud provider and its customer sounds sensible in theory. In practice, that contract quietly became the most exploited gap in enterprise security, and 2024 proved it at scale. According to SentinelOne, 61% of organizations reported a major cloud security incident in 2024, up from just 24% in 2023, a 154% year-over-year surge that correlates directly with the operational confusion built into the cloud security shared responsibility model that every hyperscaler uses.

If you’re a CISO, cloud architect, or DevSecOps lead managing workloads across AWS, Azure, or Google Cloud, this article is for you specifically. Not because the model is fraudulent. It isn’t. But because the gap between what the contract says and what your team actually does is where attackers are setting up camp, and the data on dwell times, breach costs, and misconfiguration rates makes that devastatingly clear.

---

What the Shared Responsibility Model Actually Says

Before naming the problem, it’s worth being precise about what the model is. All three major hyperscalers operate on the same foundational principle: the provider secures “of the cloud,” the customer secures “in the cloud.”

AWS states it plainly: AWS manages security of the cloud, covering physical infrastructure, the host operating system, the virtualization layer, and networking down to the data center level. The customer assumes responsibility for the guest operating system, application software, and security group firewall configuration.

Microsoft Azure documents nearly identical logic but breaks it down further by service model. In IaaS, customers carry full responsibility for deployed applications. In PaaS and SaaS, Microsoft absorbs parts of the stack, but the customer remains responsible for application configuration, code security, and access controls. Crucially, for every deployment model without exception, the customer always owns data and identities.

That last sentence is worth reading twice. Always. Data and identities. That’s not a technicality in the fine print. It’s the front door.

Responsibility Area	AWS / Azure (IaaS)	AWS / Azure (PaaS/SaaS)	Google Cloud (Shared Fate)
Physical infrastructure	Provider	Provider	Provider
Virtualization / hypervisor	Provider	Provider	Provider
Guest OS / patching	Customer	Shared / Provider	Shared (active partnership)
Application configuration	Customer	Customer	Customer (Google advises)
Data encryption and classification	Customer	Customer	Customer
Identity and access management	Customer	Customer	Customer
Network firewall / security groups	Customer	Shared	Customer (Google advises)

The documentation is actually more transparent than critics give it credit for. AWS and Azure spell out the dividing lines with precision. The problem isn’t that providers hide this information. The problem is that most engineering teams never operationalize it, and in a multi-cloud environment where the same DevOps engineer might touch AWS Lambda, Azure App Service, and Google Cloud Run in the same sprint, the responsibility matrix shifts three times with no visible alert.

---

Google Cloud Breaks Ranks: Shared Fate vs. Shared Responsibility

Here’s the development that most cloud security coverage has underreported. Google has publicly, explicitly rejected the “shared responsibility” framing entirely. Not softened it. Rejected it.

Google’s official documentation describes the traditional model as drawing “a line in the sand,” arguing that this creates an “unhealthy, adversarial dynamic leading to finger-pointing and blame.” Google’s alternative is called “shared fate,” in which the company commits to not being the delineator of where its responsibility ends and the customer’s begins.

“The shared responsibility model [is] where a cloud provider runs the underlying infrastructure and is responsible for the security of that, and then on the other side of that line is what the customer is responsible for. That clearly is contractually and legally correct, but it doesn’t, in our opinion, embody the right philosophical approach for security.” Phil Venables, CISO, Google Cloud — SDxCentral, March 2024

That’s one hyperscaler’s CISO, on record, saying the model that the other two hyperscalers still use as their official framework is philosophically inadequate for real-world security.

Our read: this is significant not as a marketing position but as a signal. When Google Cloud’s CISO goes on the record calling the shared responsibility model’s dynamics “adversarial,” they’re describing something practitioners have experienced for years. Whether “shared fate” resolves that in practice, or simply rebrands it, is an open question. But the candor itself tells you something about where the industry knows the model is breaking.

---

The Numbers Behind the Gap

The scale of the shared responsibility gap problem isn’t anecdotal. The data from 2024 and 2025 is specific enough to bring to a board meeting.

Each of those numbers deserves context. The 61% figure from SentinelOne (measuring 2024 incidents) represents a 154% jump in a single year. That’s not a statistical blip. It tracks directly with the 88% of organizations now running hybrid or multi-cloud environments (Fortinet, 2026), each of which multiplies the responsibility matrix complexity.

Gartner’s “99% customer’s fault” forecast has circulated for nearly a decade and remained stubbornly unchallenged by AWS or Azure, which tells you something about whose interests the liability framing serves. The underlying mechanism is almost always misconfiguration: exposed storage buckets, over-permissive IAM roles, unmonitored API endpoints, and security groups left open “temporarily” until they’re not.

The IBM Cost of a Data Breach Report 2025, conducted by the Ponemon Institute across 600 organizations and 3,470 security leaders in 16 countries, puts the average global breach cost at $4.44 million. For U.S. organizations, that figure climbs to $10.22 million once regulatory fines and detection costs are included. A counterintuitive finding: public cloud breaches average $4.18 million while private cloud breaches average $4.68 million, likely because hyperscalers’ investment in provider-side tooling reduces containment time on the infrastructure layers they do control.

What the providers don’t control, and what those breach costs confirm, is everything in the customer’s column: 70% of cloud breaches in 2024 originated from compromised identities, which sits squarely in customer-owned territory under every version of the shared responsibility model, including Google’s “shared fate.”

The Toyota incident from 2023 remains the cleanest proof point. A misconfiguration, not a provider infrastructure failure, exposed data on approximately 260,000 customers across two separate disclosures. The exposure persisted for over seven years before detection. That’s the real-world illustration of a 276-day dwell time: customer-side gap, customer-owned data, customer’s fault, years of blind spot.

---

Where the Model Breaks Down in Practice

The documentation is clear. The failure is operational. Here’s specifically where the breakdown happens at the team level.

Multi-cloud multiplies the matrix

88% of enterprises now run hybrid or multi-cloud architectures. That means the same security architect who understands the AWS shared responsibility model for EC2 must mentally context-switch to a different matrix for Azure App Service, and again for Google Cloud Run, often within the same week. Each abstraction level (IaaS to PaaS to serverless) shifts the provider-customer boundary, and there’s no automated notification when it moves.

IAM sprawl is the direct consequence

Identity is always the customer’s responsibility. But in a multi-cloud, multi-team environment, IAM configurations accumulate technical debt faster than any other security control. Over-permissive roles granted for a deployment sprint six months ago become the attack vector next year. The 70% of breaches originating from compromised identities isn’t surprising once you map it to this operational reality.

The “temporary” configuration problem

Security groups opened for testing. S3 buckets left public for a data pipeline handoff. Firewall rules adjusted for a migration and never reverted. These aren’t ignorance failures. They’re process failures, and they occur in teams that know the shared responsibility model perfectly well. Knowing who owns something doesn’t guarantee it gets done.

“The complexity of cloud environments makes it difficult to maintain visibility and control, while reliance on third-party services introduces additional risks.” Oli Buckley, Professor of Cyber Security, Loughborough University — Infosecurity Europe

Buckley has separately argued that the shared responsibility model is one of the main weaknesses in cloud security, not because CSPs hide their infrastructure security failures, but because the framework gives organizations a false ceiling. Once the boundary is defined, teams often treat their side as something to audit at deployment rather than something to validate continuously.

AI workloads are propagating the gap before the original one closes

Microsoft and Google have both published “AI shared responsibility” addenda, extending the same dividing-line model into AI workloads: prompt injection prevention, model integrity, and training data governance. The customer-side obligations here are even less understood than the original cloud model, and most organizations don’t have the governance tooling to enforce them. IBM’s Cost of a Data Breach Report 2025 found that 61% of organizations lack AI governance technologies altogether, and only 34% of those with policies conduct regular audits for unsanctioned AI usage.

---

The Critical View: “Shared” Is Doing Too Much Work

The sharpest critique of the shared responsibility model isn’t that it’s wrong. It’s that the word “shared” is misleading about the nature of the arrangement.

“Shared responsibility models are absolutely part of the answer, but also part of the problem. Clearly defining who is responsible for what is complex. A shared responsibility model might suggest you can negotiate the terms and decide where each responsibility lies, but this is misleading. Hyperscalers generally just describe where their own responsibility lies.” Sander Nieuwenhuis, GRC Advisory Global Lead, Nordcloud

Nieuwenhuis’s framing is the most structurally honest critique available. What gets called a “shared” model is actually a unilateral declaration by the provider about what they will and won’t cover. Customers don’t negotiate the boundaries. They inherit them. And because the boundaries shift by service type, by deployment model, and by abstraction level, the practical effect is that organizations are responsible for a moving line they didn’t draw.

Google’s “shared fate” rebranding addresses the adversarial tone of the original. But Nordcloud’s critique applies there too: “shared fate” could set the wrong expectation in the opposite direction, implying that you should trust the other party to do the right thing, when what regulated industries actually need is documented governance that goes far beyond fate. In healthcare, finance, and critical infrastructure, “we’ll figure it out together” is not a compliance posture.

There’s also a commercial incentive layered into this debate that practitioners should keep in mind. The lion’s share of “shared responsibility gap” literature is produced by security vendors selling CSPM, CNAPP, and IaC scanning tools. The Wiz reports, the CrowdStrike state-of-the-cloud documents, the SentinelOne statistics roundups: these are directionally accurate, but they’re not neutral. Treat the direction as real and the precision with appropriate skepticism.

---

What CISOs Should Actually Do Now

The shared responsibility model isn’t going away. AWS and Azure’s documentation is unusually precise, and the underlying logic of splitting infrastructure from configuration ownership is sound. What has to change is operationalization.

Build per-service responsibility documentation

For every cloud service in your environment, document the boundary explicitly: what the provider owns, what your team owns, and who on your team owns it. This is tedious and non-automated. It’s also the only way to prevent “I thought they handled that” from becoming your breach postmortem’s opening line.

Treat IAM as a continuous control, not a deployment-time check

70% of cloud breaches start with compromised identities. If your IAM review cadence is quarterly or annual, you’re validating a configuration that may have drifted significantly since the last audit. Continuous CIEM tooling, with alerting on privilege escalation and dormant high-permission accounts, is the direct operational response to the data.

Price the dwell time into your tooling budget

Misconfiguration-driven breaches average 186 days to detect and cost $3.86 million. That’s the number to put in front of a CFO when requesting CSPM tooling budget. The math on continuous posture validation versus one breach contained 50 days earlier is not close.

Watch Google’s “shared fate” model carefully

Google’s explicit break from the “shared responsibility” framing is the first time a major hyperscaler has publicly acknowledged the model’s philosophical inadequacy. Whether AWS and Azure follow, whether through language or through actual shifts in default configurations and tooling, will define the next evolution of cloud security architecture. CISOs evaluating multi-cloud strategy should treat Google’s position as a genuine industry signal, not as a sales pitch.

---

Frequently Asked Questions

---

Where This Goes in the Next 12 to 18 Months

Three things to watch closely.

First, the AI shared responsibility extension. Microsoft and Google have already published AI-specific addenda to their shared responsibility models, covering prompt injection, model integrity, and training data governance. These are areas where customer-side obligations are even less understood than the original cloud model, and the governance tooling to enforce them barely exists at enterprise scale. The 61% of organizations lacking AI governance technologies will become a breach statistic inside the next 18 months.

Second, whether AWS and Azure adopt any of Google’s “shared fate” language, or more importantly, whether they back it with default-secure configurations that reduce the operational burden on customers. The philosophical debate is secondary to whether providers start shipping services that are misconfiguration-resistant by default rather than misconfiguration-prone by default.

Third, the regulatory response. As cloud breaches continue to accelerate, the 45% of all data breaches now occurring in cloud environments will draw regulatory attention to the shared responsibility model itself. Whether GDPR enforcement actions, SEC cybersecurity disclosure requirements, or sector-specific rules start holding customers accountable for model misunderstanding versus willful negligence will shape how enterprises document and audit their responsibility boundaries.

The shared responsibility model is not a broken concept. It’s an under-operationalized one. The gap isn’t in the contract. It’s in the space between what the contract says and what your team does on a Tuesday afternoon during a production incident. That gap is where 61% of 2024’s cloud breaches lived. Closing it doesn’t require a new model. It requires treating the existing one as a living operational document rather than a one-time compliance checkbox.