The Cloud Security Shared Responsibility Model Is a Lie

Every cloud provider has a shared responsibility model diagram. The diagrams are clear. The diagrams are also misleading. In practice, the boundary between “provider responsibility” and “customer responsibility” is full of grey areas, and the grey areas are where the breaches live.

The shared responsibility model is one of the most successful pieces of marketing in the history of enterprise technology. Every major cloud provider has a version. The diagrams are crisp, the colour coding is clear, the messaging is consistent. The provider is responsible for the security of the cloud. The customer is responsible for the security in the cloud. The customer is responsible for the data, the applications, the access, the configuration. The provider is responsible for the hardware, the network, the hypervisor, the physical security. The split is presented as obvious, and the diagrams are presented as the answer to the question “who is responsible for this.”

The diagrams are not the answer. The diagrams are the start of the question.

What the shared responsibility model actually says

The classic AWS shared responsibility model puts the customer in charge of the customer data, the platform, the applications, the identity and access management, the operating system, the network and firewall configuration, and the client side data encryption. AWS, in turn, owns the compute, the storage, the database, the networking, the regions, the availability zones, and the edge locations. The split is presented as a clean line drawn through the stack, with the provider’s responsibilities below the line and the customer’s above.

Azure has a similar diagram. So does Google Cloud. So does Oracle Cloud, IBM Cloud, Alibaba Cloud, every major provider. The diagrams are not identical but the structure stands as the same. The customer owns the things they configure. The provider owns the things they configure. The split, in theory, is clear.

What it actually does on the ground

On the ground, the boundary is a mess. The customer is told they are responsible for IAM, but IAM is configured against the provider’s APIs, using the provider’s tooling, and the defaults are set by the provider. The customer is told they are responsible for data encryption, but the encryption is implemented by the provider’s services, with provider managed keys, and the customer has to opt in to bring their own key. The customer is told they are responsible for the operating system, but the operating system image is provided by the provider, in some cases by the customer, in some cases by a third party marketplace, and the patching responsibility is ambiguous.

Every one of those grey areas has been the subject of a real breach. Capital One, in 2019, was the result of a misconfigured web application firewall, which was a customer responsibility under the AWS shared responsibility model, but the configuration mistake was a default that AWS had set, and the audit trail was a feature that AWS had implemented. The 2019 breach was everyone’s responsibility and therefore, in practice, no one’s.

The identity problem (IAM is yours, but who configures it correctly)

Identity runs as the most common attack vector in cloud breaches. The 2024 and 2025 breach reports, across vendors, consistently show that stolen credentials, misconfigured identity, and over privileged roles account for the majority of cloud incidents. The shared responsibility model says IAM becomes the customer’s responsibility. The shared responsibility model does not say how to configure IAM correctly. The provider gives the customer a default. The default is permissive. The customer, who is not an IAM expert, leaves the default. The default sits as the breach.

The provider’s response is “the customer is responsible for IAM.” The customer’s response is “we followed the documentation and the default was permissive.” The auditor’s response is “the configuration was within the provider’s documented options.” The breach is everyone’s. The fix is no one’s.

The data classification problem (you don’t know what you have)

The shared responsibility model says the customer is responsible for data. The model assumes the customer knows what data they have, where it is, how it is classified, and what protections each classification requires. The assumption is, in 2026, false for the majority of enterprises.

The average enterprise has data in hundreds of buckets, across multiple accounts, in multiple regions, in multiple clouds, on premises, in SaaS applications, in shadow IT, in employee laptops, in chat archives, in email archives, in backups, in snapshots. The data is duplicated, stale, misclassified, and largely untracked. The customer, asked to take responsibility for the security of the data, cannot answer the basic question of where the data is.

The provider, in turn, has no visibility into the customer’s data, by design. The provider encrypts the storage. The provider does not know what is in the storage. The provider cannot tell the customer that the bucket labelled “test-backup-2019” contains the production customer database. The customer has to know. The customer does not know.

The misconfiguration problem (the provider gives you a default that is not secure)

Cloud services ship with defaults. The defaults are, often, the configuration that requires the least customer effort, not the configuration that is most secure. Storage buckets default to private in 2023, but only after years of public defaults caused the 2017 to 2021 wave of bucket exposure incidents. S3 buckets had a public by default setting for years, and the customer, in many cases, did not know the bucket was public because the AWS console did not surface the setting prominently.

The provider is responsible for the security of the cloud. The cloud includes the default settings. The defaults were permissive. The defaults caused the breach. The customer is responsible for configuring the defaults. The customer did not know the defaults were permissive. The breach is, again, in the gap.

The audit problem (the auditor checks the provider’s controls, not yours)

The compliance audits, the SOC 2s, the ISO 27001s, the PCI DSS assessments, the HIPAA audits, all rely on the shared responsibility model. The auditor checks the provider’s controls. The auditor issues a report that says the provider’s controls are good. The customer takes the report and uses it to satisfy their own audit obligations. The customer is then responsible for their own configuration, which the auditor did not check, because the customer’s configuration sits as the customer’s responsibility.

The result is a compliance regime that certifies the cloud and trusts the customer. The certification does not cover the breach vector, which serves as the customer’s configuration of the cloud. The compliance report is real. The protection is not.

Real incidents that fell into the gap

Capital One (2019). Misconfigured WAF, customer responsibility per the AWS shared responsibility model. Default WAF rule, set by AWS, that the customer did not change. Customer data exposed. Both parties were technically correct about their responsibilities. The breach happened anyway.

Twilio (2022). Employee credentials phished. Two factor bypassed through session theft. Twilio was on AWS. AWS was not the vector. The vector was the customer’s identity configuration, which the customer owned. Twilio is sophisticated. The attack succeeded.

Dropbox Sign (2024). Customer signing service breached through a compromised service account. The service account was a customer identity, in the customer’s identity provider, configured by the customer. The provider (Dropbox) was not the vector. The customer’s identity was.

Every major cloud breach of the last 5 years has the same shape. The provider was not breached. The customer’s configuration of the provider was breached. The customer was responsible. The customer did not have the expertise or the time to configure the provider correctly. The breach happened.

What an honest shared responsibility model would look like

An honest shared responsibility model would acknowledge that the boundary is a gradient, not a line. The provider would be responsible for the secure defaults of every service. The customer would be responsible for choosing secure configurations, but the provider would make the secure configuration the default. The provider would warn the customer, prominently, when a configuration change weakened security. The provider would offer a hardened baseline that the customer could apply with one click, audited, maintained, and recommended.

The provider would also be responsible for the configuration tools. The IAM console should not let the customer create an over privileged role without a warning. The storage console should not let the customer make a bucket public without a confirmation dialog. The networking console should not let the customer open a security group to the world without a clear warning about the consequences. The tools should make the secure choice the easy choice, and the insecure choice the deliberate, friction filled choice.

Some providers are moving in this direction. AWS, Azure, and Google Cloud have all added security defaults, configuration warnings, and one click hardening in the last three years. The movement is real. The movement is slow. The breaches are still happening because the legacy configurations, the ones deployed before the defaults changed, are still running in thousands of accounts.

The bottom line

The shared responsibility model is a useful framework and a misleading diagram. The framework says the customer is responsible for the configuration. The diagram says the boundary is clean. Neither is true. The boundary is full of grey areas, and the grey areas are where the breaches live, and the breaches are in the grey area because both parties were technically correct about their responsibilities, and both parties were practically wrong about the protection.

The fix is for the provider to ship secure defaults and to make insecure configurations hard. The fix is for the customer to invest in cloud security expertise, which most customers have not done. The fix is for the auditor to look at the customer’s configuration, not just the provider’s controls. None of these are quick. All of them are necessary. Until they happen, the shared responsibility model will keep being a useful framework for the provider’s lawyers and a misleading diagram for the customer’s CISO.