Cloud Shared Responsibility Model: What Your Cloud Provider Does Not Secure
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The shared responsibility model is the foundational concept of cloud security and the most commonly misunderstood one. When an AWS S3 bucket exposes customer data to the public internet, AWS did not fail: the customer configured the bucket incorrectly. AWS secured the storage infrastructure; the customer was responsible for the access control policy. This distinction matters because it determines where your security investments and controls must focus.
Gartner's longstanding prediction holds: through 2025, 99 percent of cloud security failures will be the customer's fault. Not because cloud providers are perfect, but because the provider responsibility layer (physical security, hypervisor, network fabric) is rarely the attack surface. The customer responsibility layer (identity configuration, storage access policies, network security groups, encryption settings, application code) is attacked constantly.
The responsibility boundary across IaaS, PaaS, and SaaS
The shared responsibility boundary is not fixed. It shifts based on the service model:
IaaS (EC2, Azure Virtual Machines, GCP Compute Engine): The cloud provider secures physical data centers, hardware, and the hypervisor. The customer is responsible for: the guest operating system and its patch management, network controls (security groups, firewall rules, VPC configuration), identity and access management (IAM roles, key management), application security, and data protection. An unpatched EC2 instance with overly permissive security groups is entirely the customer's responsibility.
PaaS (AWS RDS, Azure App Service, GCP Cloud SQL): The cloud provider adds the managed runtime, database engine, and platform components to its responsibility. The customer is responsible for: application code running on the platform, application-level access controls, data encryption choices (the provider offers it; the customer must enable and configure it correctly), and identity configuration. A publicly accessible RDS instance with a weak password is a customer misconfiguration in a provider-managed service.
SaaS (Microsoft 365, Google Workspace, Salesforce): The provider is responsible for the application, platform, infrastructure, and application-level security controls. The customer is responsible for: identity and access management (who has access to what), data classification and labeling, data residency compliance, third-party integration security, and the configuration of the SaaS platform's security settings. A Microsoft 365 tenant with global admin accounts without MFA is a customer identity configuration failure, not a Microsoft security failure.
Where cloud breaches actually happen: the customer responsibility gaps
The six most common cloud security failures all sit on the customer responsibility side of the boundary:
-
Publicly accessible storage: S3 buckets, Azure Blob containers, and GCP Cloud Storage buckets configured with public read access. All three providers default to private access; public access requires explicit customer configuration. This is entirely the customer's responsibility.
-
Overly permissive IAM: AWS IAM policies granting AdministratorAccess to service accounts that need only read access to one S3 bucket, Azure RBAC assignments granting Contributor at the subscription level for what should be resource-group-scoped access. Identity misconfiguration is the customer's responsibility.
-
Missing encryption for sensitive data at rest and in transit: All three providers offer encryption at rest for most services, but the default state varies by service and configuration option. Customer responsibility includes verifying encryption is enabled and customer-managed keys (CMKs) are used where data sensitivity requires them.
-
Unpatched virtual machine images: Any EC2, Azure VM, or GCP Compute instance has its OS patch management as an explicit customer responsibility. The cloud provider does not patch your OS; automated patch management is your responsibility.
-
No multi-factor authentication on privileged cloud console accounts: The root AWS account without MFA, the Azure Global Administrator account without Conditional Access MFA requirement, the GCP Organization Admin without 2-Step Verification are all customer identity failures.
-
Exposed management interfaces: RDP (port 3389) or SSH (port 22) security group rules allowing inbound access from 0.0.0.0/0 (all internet). Cloud providers do not configure security group rules for you; every inbound rule is a customer decision.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Provider-specific responsibility matrices for AWS, Azure, and GCP
Each major provider publishes a responsibility matrix that maps controls to provider vs. customer ownership. The practical summary:
AWS: The customer responsibility layer in AWS is the most explicit of the three providers. AWS clearly documents that customers own: operating systems, platform, applications, data, client-side encryption, network traffic protection, server-side encryption, firewall configuration, and network and identity access management. AWS secures the 'cloud' (hardware, AZs, regions, edge locations). The customer secures what is 'in the cloud.'
Microsoft Azure: Azure's model is more complex because many customers use Azure in conjunction with Microsoft 365 and Entra ID. Azure documents three service models (IaaS, PaaS, SaaS) each with a different responsibility boundary. For IaaS, the customer responsibility is identical to AWS's model. A common Azure-specific gap is Entra ID configuration: conditional access policies, privileged identity management (PIM) configuration, and guest user access controls are all customer responsibilities.
Google Cloud: GCP's shared responsibility matrix is documented in the Google Cloud Architecture Framework. GCP uniquely offers Assured Workloads and Google-managed encryption keys as features that can shift some configuration responsibility to Google-managed defaults. However, the core gaps (IAM configuration, storage access policies, compute network access) remain customer responsibilities across all service models.
Practical controls for the customer responsibility layer
Addressing the customer responsibility layer requires controls in three categories:
Configuration auditing: Cloud Security Posture Management (CSPM) tools (Wiz, Prisma Cloud, Microsoft Defender for Cloud, AWS Security Hub) continuously scan your cloud environment for customer-side misconfigurations. They identify public storage buckets, overly permissive IAM, missing encryption, open management ports, and dozens of other customer-layer control failures. This is the fastest ROI investment for most organizations moving workloads to cloud.
Identity security: Cloud identity is the primary attack surface on the customer responsibility side. Implement: MFA on all cloud console accounts, least-privilege IAM with regular access reviews, service account key rotation and avoid long-lived credentials where instance metadata service or workload identity can substitute, and monitoring for unusual API calls with CloudTrail (AWS), Activity Logs (Azure), or Cloud Audit Logs (GCP).
Data classification and access control: Every data store (S3, RDS, Blob Storage, BigQuery) should have an explicit access control decision documented and enforced. Start with a public-access audit: run AWS Config rules or Azure Policy to flag any storage resource with public access enabled, and require exceptions to be justified and time-limited.
The bottom line
The shared responsibility model means that your cloud provider's security certifications (ISO 27001, SOC 2, PCI DSS) apply to their responsibility layer, not yours. When an auditor asks about your cloud security posture, they are asking about the customer responsibility layer: IAM configuration, data encryption, network controls, and application security. Invest in CSPM tooling to maintain continuous visibility into your configuration state, and treat cloud identity with the same rigor you apply to on-premises privileged access.
Frequently asked questions
Who is responsible for cloud security?
Responsibility is divided between the cloud provider and the customer under the shared responsibility model. The cloud provider (AWS, Azure, GCP) secures the physical infrastructure, hardware, hypervisor, and network fabric. The customer is responsible for identity and access management, operating system patching (in IaaS), data encryption configuration, network security group rules, application security, and storage access policies. The specific boundary shifts with the service model: customers have more responsibility in IaaS than PaaS, and more in PaaS than SaaS.
What does AWS secure under the shared responsibility model?
AWS secures the infrastructure that runs all AWS services: the physical data centers, hardware (compute, storage, networking), and the global network infrastructure connecting AWS regions and availability zones. AWS also secures the hypervisor layer that isolates EC2 instances from each other. Everything running on that infrastructure is the customer's responsibility: the OS, applications, data, network access controls (security groups, NACLs), and IAM configuration.
Is a public S3 bucket a cloud provider security failure?
No. Public S3 buckets result from customer configuration choices. AWS S3 defaults to private access; making a bucket publicly accessible requires the customer to either remove the block public access setting and add a public bucket policy, or grant public ACLs. AWS provides multiple controls to prevent accidental public access (S3 Block Public Access at the account and bucket level). AWS even sends security findings via Trusted Advisor and Security Hub when public buckets are detected. The customer bears responsibility for the configuration decision.
Does my cloud provider's compliance certification cover my workloads?
No. Cloud provider compliance certifications (AWS ISO 27001, Azure SOC 2, GCP PCI DSS QSA) certify that the provider's infrastructure and operations meet the relevant framework requirements for their responsibility layer. Your workloads and data are not in scope for the provider's certification. You must independently demonstrate compliance for the customer responsibility layer: data classification, access controls, encryption configuration, audit logging, and application security controls. This is why AWS publishes 'inherited controls' and 'shared controls' separately from 'customer-owned controls' in its compliance documentation.
What is cloud security posture management (CSPM) and do I need it?
CSPM tools continuously scan cloud environments for misconfiguration on the customer responsibility side: public storage buckets, overly permissive IAM policies, unencrypted databases, open management ports, missing audit logging, and hundreds of other control gaps. They work by reading cloud provider APIs (CloudTrail, Azure Resource Graph, GCP Asset Inventory) to compare your configuration state against security benchmarks (CIS AWS Foundations, Azure Security Benchmark, GCP Security Command Center). Any organization running production workloads in cloud should have CSPM coverage. Leading tools include Wiz, Prisma Cloud, Microsoft Defender for Cloud (free tier included with Azure), and AWS Security Hub.
How does the shared responsibility model apply to SaaS applications like Microsoft 365?
For SaaS, the provider owns almost all infrastructure and application-layer security. Microsoft secures the Exchange Online infrastructure, SharePoint application code, Teams platform security, and the physical data centers. The customer is responsible for: who has access to the tenant (identity and access management), what Conditional Access policies are applied to require MFA and block risky sign-ins, data loss prevention policy configuration, third-party app integration security, guest access settings, and compliance configuration (data retention policies, eDiscovery setup). A Microsoft 365 tenant breach typically exploits the customer identity configuration side, not Microsoft's application security.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.