Cloud Foundations

The Shared Responsibility Model: Who Secures What (2026)

Last verified: June 17, 2026  ·  Format: Breakdown

The shared responsibility model is the agreement that decides who secures what once your systems run in the cloud. In one line: the provider secures the cloud, and you secure what you put in it. The provider takes care of the physical datacenters, the network, the host servers, and the hypervisor that separates one tenant from another. You take care of your data, your user identities, your access rules, and how you configure the services you switch on. Misread that split and you can ship something that is technically running yet quietly wide open, which is exactly how most cloud incidents begin.

The catch is that the dividing line is not fixed. It slides depending on whether you rent raw infrastructure, a managed platform, or a finished application. This breakdown walks the shared responsibility model end to end: the AWS framing, a full responsibility matrix you can read at a glance, how the three big providers describe it, and the handful of things you own no matter what. Provider descriptions below were checked against official documentation on June 17, 2026.

What the shared responsibility model is

The shared responsibility model is a security division of labor between you and your cloud provider. It exists because the cloud is not one indivisible thing you either trust or do not; it is a stack of layers, and the shared responsibility model is what makes the trust boundary inside it explicit. Different layers sit under different people's control. Your provider runs the building, the power, the racks, the physical network, and the virtualization software. You run the workloads, the data, and the accounts that reach them. The shared responsibility model simply draws a clear line through that stack so neither side assumes the other has it covered.

Two principles hold true on every cloud and in every service model. First, the provider always secures the lowest layers: the physical facility, the underlying hardware and network, and the hypervisor. You can neither see nor touch those, so you cannot be responsible for them. Second, you always secure your own data and the identities that access it. No provider can decide which records are sensitive, who in your organization should reach them, or whether multi-factor authentication is switched on. Everything between those two fixed ends is what moves.

It helps to start with shared vocabulary. If the words IaaS, PaaS, and SaaS are not yet second nature, the companion explainer on what cloud computing is sets out the service models this article builds on, and the Cloud Tools Hub collects the wider set of foundations.

Security "of" vs "in" the cloud (AWS)

AWS gave the shared responsibility model its most quoted phrasing, and it is worth borrowing because it is genuinely clarifying. AWS is responsible for security "of" the cloud, the hardware, software, networking, and facilities that run AWS services. You are responsible for security "in" the cloud, meaning everything you build and place on top. Where exactly that "in" line falls depends on which service you choose, so the customer's share grows or shrinks with the service.

AWS also sorts controls into three useful buckets. Inherited controls are ones you get for free from AWS, such as physical and environmental protections in the datacenter. Shared controls apply to both sides at different layers, patch management is the classic example: AWS patches the underlying infrastructure, and you patch the guest operating system and applications you run. Customer-specific controls are entirely yours, such as classifying your data or configuring a service to meet your own compliance needs.

A concrete pair makes it click. With Amazon EC2, an infrastructure service, you manage the guest operating system, including its updates and security patches, the application software, and the firewall rules in your security groups; AWS handles the host, the hypervisor, and the physical layer. Move to an abstracted service like Amazon S3 or DynamoDB and AWS operates the infrastructure layer for you, so your job narrows to managing your data, classifying it, and setting access with encryption and identity permissions. Same provider, very different customer workload, because the shared responsibility model shifts with the service.

The responsibility matrix by service model (IaaS/PaaS/SaaS)

This is the centerpiece, and the single most useful way to hold the whole shared responsibility model in your head. Microsoft publishes a responsibility matrix. It maps each layer of the stack against the four ways you can run software: on-premises, IaaS, PaaS, and SaaS, and marks who owns each cell. Read any row left to right and you watch responsibility hand off from you to the provider as the service becomes more managed.

Customer = you own it  ·  Shared = both sides at different layers  ·  Microsoft = the provider owns it. Mapped from Microsoft's published Azure responsibility matrix; verified June 17, 2026.

Three things jump out of the grid. The top four rows, data, configuration, identities, and client devices, are Customer across every column, even SaaS: those never transfer. The bottom three rows, the physical layers, are the provider's the moment you leave on-premises. And the middle, applications, network, and the operating system, is the part that actually shifts, sliding from you toward the provider as you move from IaaS to PaaS to SaaS. Function as a service behaves like the SaaS column for these purposes. That moving middle is where most confusion about the shared responsibility model, and most risk, lives.

How AWS, Azure and Google Cloud describe it

All three major providers teach the same model, but each frames it in its own language, and the differences are worth knowing if you work across clouds. The shape is identical; the vocabulary and the extra programs are not.

AWS: "of" the cloud vs "in" the cloud

AWS keeps this split crisp with the "of versus in" phrasing covered above, backed by the inherited, shared, and customer-specific control classes. Its version of the model emphasizes how your duties expand or contract with each service, from a full guest OS on EC2 down to just data and access on an abstracted store.

Azure: a responsibility matrix

Microsoft leans on the matrix you just read. It states plainly that data, endpoints, accounts, and access management responsibilities always stay with the customer regardless of deployment type, and that physical hosts, network, and datacenter are always Microsoft's. The matrix is the clearest single artifact for seeing how the operating system, applications, and network controls migrate across IaaS, PaaS, and SaaS.

Google Cloud: shared responsibility evolving into shared fate

Google Cloud starts from the same IaaS, PaaS, SaaS split, then goes a step further with what it calls shared fate. The argument is that handing customers a responsibility chart and walking away is not enough, so Google takes a more active role in helping you stay secure. In practice that means secure-by-default landing zones and blueprints (infrastructure as code with safe defaults baked in), a Risk Protection Program that connects qualified customers with cyber-insurance offerings from insurers such as Munich Re and Allianz, and tooling including Assured Workloads, Security Command Center, and Confidential Computing. Shared fate does not rewrite the shared responsibility model; it tries to make the customer's side of the line easier to hold.

What you ALWAYS own (data + identities)

Strip away every difference between providers and service models, and the shared responsibility model leaves a short, non-negotiable list of duties with you. These cells stayed Customer across the entire matrix for a reason: no provider can make these decisions for you, because only you know your business, your data, and your people.

If you remember nothing else about the shared responsibility model, remember this list. Whether you run a fleet of virtual machines or a single SaaS subscription, your data, your identities and access, your configuration, and your endpoints are yours to secure. The provider can hand you better tools and safer defaults, but it cannot make these choices on your behalf. Choosing a provider in the first place is a related decision; the pillar pages on AWS, Microsoft Azure, and Google Cloud break down how each one approaches security and services.

Where the model goes wrong

Almost every cloud security failure traces back to one side misreading the line. The shared responsibility model is simple to state and easy to get wrong in practice. These are the recurring traps.

Frequently Asked Questions