Cloud shared responsibility model

What is the cloud shared responsibility model?

The cloud shared responsibility model is a division of security duties between a cloud service provider and the organization using it. The provider answers for the facilities, the hardware, the host operating system and the virtualization layer. The customer answers for data, identities, access policies and the configuration of every service they switch on.

AWS states its half of the shared responsibility model in one sentence: "Security and Compliance is a shared responsibility between AWS and the customer." The company separates the two halves as security "of" the cloud versus security "in" the cloud. AWS runs the first. You run the second.

Microsoft draws the customer's floor at the same place: "For all cloud deployment types, you own your data and identities." Those two never move, whatever you buy.

The cloud shared responsibility model assigns work, not liability. Nothing in it makes a cloud service provider answerable for how you configure their product. CISA says this to federal agencies without softening it: "Agencies must clearly identify and understand the delineation of responsibilities between themselves and their CSP."

Three things the shared responsibility model is not:

• Not a contract clause you can negotiate down. The provider cannot see inside your data, and you cannot reach their hypervisor.

• Not identical across vendors. CISA warns that "CSPs may define this shared security relationship differently from one vendor to the next."

• Not static. Every new service you enable moves the line again.

Security of the cloud and security in the cloud

Security of the cloud is everything the provider runs and you cannot touch. Security in the cloud is everything you deploy, configure and grant access to. The cloud shared responsibility model is the line between them, and that line sits in a different place for each service model.

In IaaS you rent machines and networks, so nearly everything above the hypervisor is yours. In PaaS the provider also runs the operating system and the runtime, so your share narrows to the application and its data. In SaaS you configure and populate finished software, so the cloud shared responsibility model leaves you the data, the accounts and the sharing settings.

NIST described the cloud shared responsibility model in SP 800-210 before the marketing language settled. For IaaS: "data in the middleware, data, applications, and OS layers is owned and controlled by the consumer." For SaaS: "Note that data managed by the application layer is owned and controlled by the consumer." Different surface, same owner.

Responsibility by service model, following Microsoft's division and the IaaS, PaaS and SaaS split in NIST SP 800-210.

Read the table across the first three rows. Customer data, configurations and settings, and identities and users never change hands, in any version of the shared responsibility model. Every cloud breach traced to a public bucket, an overprivileged role or a leaked key lives in one of those three rows.

SaaS is where the shared responsibility model is misread most often, because the provider's share looks total. It is not. Sharing settings, external collaborators, API tokens and account lifecycle all stay with you, and a SaaS tenant with no multi-factor authentication is a customer-side failure.

The cloud shared responsibility model at Fluid Attacks

We work both sides of this. We test our clients' cloud configurations with Cloud Security Posture Management (CSPM) and manual techniques, and we run our own production infrastructure on AWS under the same shared responsibility model we ask them about. Here is what that looks like, and what it does not.

What we assess, and under what rules

Our CSPM reviews an AWS environment for configurations that break security requirements, which is the customer's half of the shared responsibility model, and it runs continuously rather than once a quarter. You register the environment in our platform as a Cloud (CSPM) asset, which our documentation defines as "You are adding your AWS environment to be tested with cloud security posture management."

Access is scoped, not open-ended, because the shared responsibility model runs in both directions. Our connection documentation states that "Fluid Attacks reaches only the resources that you authorize, and the remaining part of your network stays private." The least-privilege rule we test you against applies to the access you give us.

What it looks like in practice

Every cloud finding maps to an entry in our open catalog of weaknesses and to the requirements that close it. That mapping turns a scanner alert into something a developer can act on, and every row below sits on the customer's side of the cloud shared responsibility model.

Each cloud weakness we report carries the requirement that resolves it.

Our database entry for publicly accessible cloud storage, with its linked requirements.

How we hold up our own end

We are a customer of the cloud shared responsibility model too, and our infrastructure is rebuilt rather than patched. Our stack documentation says that "Terraform is used for writing our entire infrastructure stack as code" and that "the infrastructure is regenerated from scratch every time it is required." A configuration that drifts does not survive the next deploy.

Secrets never sit in a repository in readable form. We manage them with Sops, which "resolves secrets at deploy time inside GitLab CI/CD with no runtime dependency." That is the direct countermeasure to the weakness we find most often in client code, and it sits on our side of the shared responsibility model exactly as it would on yours.

Our pentesters work AWS environments with AWS CLI, Pacu and enumerate-iam, all listed in our public toolset. Tools surface the misconfiguration. A person finds the chain that turns three individually harmless settings into privilege escalation, which is the part of the shared responsibility model that automation alone does not close.

The pattern has held for years. Jonathan Armas, security analyst at Fluid Attacks, wrote in Secure Cloud as Code that "The most common faults that we find when we test IaC deployments are clear text secrets and hard-coded credentials." He added an observation from his own engagements: "Most of the times I have compromised AWS keys, they were configured with excessive permissions."

Where our benchmark stops

In Fluid Attacks' benchmark of 36 third-party AppSec tools against a 1,201-vulnerability dataset, a pentester found 1,076 of them, which is 89.6% recall at 100% precision, while our own scanner found 273, or 22.7% recall at 99% precision. It has two limits we would rather state than let you infer.

That benchmark ran against a web application, not a cloud environment. It does not measure how well any tool detects a misconfigured bucket or an overprivileged role.

The distance between 22.7% and 89.6% is the second limit, and why we do not present automated scanning as the whole answer to your half of the shared responsibility model. A scanner tells you a storage service is public. It cannot tell you whether that was a decision or an accident, and under the shared responsibility model only you can answer that.

The practice that decides the rest

Continuous checking beats a strong initial configuration. Your half of the shared responsibility model changes every time someone deploys, and a review from March says nothing about July.

Our analysis of on-premises versus cloud security makes the point that continuous monitoring stays with the customer wherever the workload runs. Go deeper in our write-ups on AWS and Azure DevSecOps.

Where the cloud shared responsibility model breaks

The shared responsibility model breaks on the customer side, in three recurring places: storage left open, identities carrying more privilege than the job needs, and credentials committed to source code. The Cloud Security Alliance ranked misconfiguration and inadequate change control, identity and access management, and insecure interfaces and APIs as the top three threats in its Top Threats to Cloud Computing 2024 report. All three sit on the customer's half of the shared responsibility model.

The same report notes that issues traditionally associated with cloud service providers are "continuing to decrease in importance." Providers improved at their half. The gap moved to ours.

Storage that answers to anyone

A storage service reachable without credentials is the oldest cloud mistake and still the most productive one for attackers. Our database describes it as "Some cloud storage service used by the application can be publicly accessed, without requiring any authentication," and the fix is equally plain: "Restrict the access of the public storage services of the system."

This is not a rare finding, and the cloud shared responsibility model puts it squarely on the customer. In our State of Attacks 2026 report, unauthorized access to files in cloud storage services accounted for 13,499 reported instances and 500,832.48 CVSSF units of risk exposure across the applications we tested in 2025.

Identities with more privilege than the job needs

Excessive privilege converts a small compromise into a large one. Our database defines the weakness as "The application, a user or a role have more privileges than they require," and notes that this "can be leveraged by an attacker to execute normally restricted actions on a system."

The remediation is a requirement, not a tool: "Users and applications should always have a role with the minimum level of privilege required to execute their functions." Nothing a cloud service provider ships will apply that for you, which is the cloud shared responsibility model working as designed.

Identity and access management sits entirely inside the customer's share of the shared responsibility model, and the overprivileged identity is rarely a person: it is a service role nobody revisited after launch. Our catalog also flags the network equivalent, where "The infrastructure definition for network segments in the AWS context is too permissive."

Credentials that ship with the code

An access key in a repository is a key with no expiry and no owner, and no reading of the shared responsibility model puts hard-coded credentials on the provider. Our analysis of cloud DevSecOps reports that Fluid Attacks' pentesters repeatedly find credentials for cloud services inside client source code, and that we assess infrastructure as code files for the misconfigurations that follow.

The State of Attacks 2026 figure quantifies it: sensitive information in source code involving credentials reached 37.4% of the systems we tested, with a mean risk exposure of 112.62 CVSSF units per affected system.

Credentials in source code affected 37.4% of the systems we tested in 2025.

Cloud-side weaknesses in Fluid Attacks' State of Attacks 2026, covering systems tested between January 1 and December 31, 2025.

What the cloud shared responsibility model does not solve

It does not tell you how to configure anything, and it does not make the provider's half infallible. Both gaps are acknowledged by the providers themselves.

Google is the blunt one. Its architecture documentation states that "Google believes that the shared responsibility model stops short of helping cloud customers achieve better security outcomes," because "Every service has a different configuration profile, and it can be difficult to determine the best security configuration." Google's answer is what it calls shared fate: the provider taking an active role in the customer's outcome rather than drawing a line and stepping back.

The second gap is simpler. The shared responsibility model assumes the provider's half holds, and sometimes it does not. In 2023, a threat actor reached the Exchange Online mailboxes of US government officials through the provider's own authentication infrastructure. The Cyber Safety Review Board ran an independent review, and CISA's summary of the findings points at the provider's decisions rather than at any customer: the report "detailed operational and strategic decisions that led to the intrusion."

Customers could not have prevented that one. It sat entirely on the provider's side of the line, and it is the reason to read a provider's security record rather than assume their half is handled.

Who was at fault

Three incidents, three different answers from the same shared responsibility model. What separates them is not the size of the company or the provider it chose. It is which side of the cloud shared responsibility model the failure sat on.

Two of the three failures sat on the customer's side of the cloud shared responsibility model.

On Toyota, the Cloud Security Alliance's review concluded that "The root cause was a mistake in configuring the company's cloud settings." A decade of exposure is not a sophisticated attack. It is an absent review cycle on the customer's half of the shared responsibility model.

Twitch described its own incident in the same terms, saying it "was a result of a server configuration change" "that allowed improper access by an unauthorized third party."

If every cloud incident were the customer's fault, the shared responsibility model would be a disclaimer rather than a division of labor.

How to hold up your end

Start by writing down the line. Ask your provider for their documented version of the cloud shared responsibility model, service by service, and check it against what you actually run. CISA's instruction to agencies works as well for a bank: identify and understand the delineation before you need it.

Enforce least privilege on roles, not just on people. Our requirement states that users and applications should hold the minimum privilege their function needs. Identity and access management stays on your side of the shared responsibility model in every service model, and the overprivileged identity is usually a service role nobody reviewed after launch.

Get credentials out of code and into a resolver. Encrypted secrets that resolve at deploy time remove the entire class of finding that affects more than a third of the systems we test. That is the single change with the best ratio of effort to risk removed.

Restrict storage and network by default. These are the two settings the shared responsibility model leaves entirely to you. Public access on a storage service and a 0.0.0.0 network rule are both one-line changes that attackers find faster than auditors do.

Require multi-factor authentication on every cloud administrative account. The shared responsibility model makes it a customer-side control in every service model, including SaaS, where it is often the only control you have left.

Then check all of it continuously. This is where a DevSecOps approach earns its keep: a configuration review is accurate for as long as nobody deploys. In a pipeline that ships daily, that is hours.

Conclusions

The cloud shared responsibility model is not complicated, but it is consistently read as more generous than it is. Providers secure what they operate. You secure your data, your identities and every configuration you touch, and that last category is where almost all customer-side incidents originate.

The evidence that the shared responsibility model fails on the customer's side is consistent across sources. The Cloud Security Alliance's top three threats for 2024 are all customer-side. Toyota went a decade without noticing, and Twitch published its own source code, both from settings nobody re-read.

The providers' half is not perfect either, as the 2023 Exchange Online intrusion showed. That is an argument for verifying both halves of the shared responsibility model, not for assuming either one is covered.

Frequently asked questions

What is the cloud shared responsibility model?

The shared responsibility model is the division of security duties between a cloud service provider and its customer. The provider secures the physical facilities, hardware, host operating system and virtualization layer. The customer secures data, identities, access policies and the configuration of the services they enable.

Who is responsible when a cloud misconfiguration causes a breach?

The customer, in nearly every case. Configuration sits on the customer's side of the cloud shared responsibility model in IaaS, PaaS and SaaS alike, so a public storage bucket or an overprivileged role is the customer's finding to fix and their incident to report. Providers supply the controls; applying them correctly is not part of what they sell.

Does the cloud shared responsibility model change between IaaS, PaaS and SaaS?

Yes, but not for everything. The operating system, runtime and network controls shift toward the provider as you move from IaaS to SaaS. Data, identities and configuration settings stay with the customer in all three. NIST SP 800-210 puts it plainly for SaaS: data managed by the application layer is owned and controlled by the consumer.

Is the cloud provider ever at fault?

Yes, and it has happened at the largest ones. In 2023 the Cyber Safety Review Board independently reviewed an intrusion into Exchange Online mailboxes and documented the provider-side decisions behind it. Google has also stated that the shared responsibility model "stops short of helping cloud customers achieve better security outcomes," and proposes shared fate in its place. Assuming the provider's half is always handled is its own risk.

Does Fluid Attacks test cloud configurations?

Yes, with CSPM on AWS environments and manual testing. We test the customer's half of the shared responsibility model with CSPM, supported by manual techniques and by scanning for credentials and insecure infrastructure as code. In our State of Attacks 2026 report, credentials in source code appeared in 37.4% of the systems we tested during 2025, which is the customer-side problem we encounter most.

Know what is yours to secure

Our scanners and pentesters check your cloud configuration, your code and your identities continuously, so the half of the shared responsibility model that belongs to you is verified rather than assumed. Start free trial · Contact us