The Shared Responsibility Model: Who Manages What in IaaS, PaaS, and SaaS

The shared responsibility model defines exactly which security and operational tasks Microsoft handles and which ones the customer handles, and that split changes depending on whether you’re using Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS). Some responsibilities never move no matter which model you choose — physical datacenter security always belongs to Microsoft, and data classification and access control always belong to the customer. Everything in between — patching the operating system, maintaining the runtime, managing the application code — shifts toward Microsoft as you move from IaaS to PaaS to SaaS.

What the model actually defines

Cloud providers and customers both touch a running workload, and without a clear line, it’s easy to assume the other side is covering something nobody actually is. The shared responsibility model exists to remove that ambiguity: it lays out, layer by layer, who owns physical hardware, who owns the hypervisor, who owns the guest operating system, who owns the application, and who owns the data flowing through all of it. It has nothing to do with pricing, intellectual property, or which programming languages you’re allowed to use — it’s purely an operational and security division of labor. That division also holds regardless of deployment model: whether workloads run in a public, private, or hybrid cloud environment, the layer-by-layer responsibility split described here doesn’t change — only the service model layered on top does.

Responsibilities that never move

Two ends of the stack stay fixed regardless of which service model you pick.

Microsoft always owns the physical layer: the datacenter’s physical security, the racks and network hardware inside it, and the power and cooling that keep it running. A customer using Azure never gets physical access to that facility and never has to think about who’s guarding the door — that’s true whether the customer is running raw virtual machines or a fully managed SaaS app.

The customer always owns its own data and identities. Classifying data, deciding who’s allowed to see it, and managing user accounts and access permissions through a service like Microsoft Entra ID stay with the customer in every single model, because Microsoft has no way of knowing what a given piece of data means or who should be authorized to touch it. That customer-side control extends down to fine-grained resource permissions too, through Azure RBAC. This is the detail that trips people up most on scenario questions: even a company using a fully managed SaaS email platform, where Microsoft runs the servers, the operating system, and the application itself, still has to manage its own user accounts and control who has access to its mailboxes.

If an organization runs everything entirely on its own hardware, with no cloud provider involved at all, none of this splitting applies — the organization is responsible for every layer itself, from the physical building up through the application, because there’s no provider on the other side of the line to share anything with.

How the split shifts across IaaS, PaaS, and SaaS

What changes between the three service models is everything in the middle of the stack — the guest operating system, the runtime, and the application platform.

Layer	IaaS	PaaS	SaaS
Physical infrastructure	Microsoft	Microsoft	Microsoft
Hypervisor / virtualization	Microsoft	Microsoft	Microsoft
Guest OS patching	Customer	Microsoft	Microsoft
Runtime / middleware	Customer	Microsoft	Microsoft
Application code	Customer	Customer	Microsoft
Data & identity	Customer	Customer	Customer

In IaaS, Microsoft manages only the physical infrastructure and virtualization layer beneath the virtual machine — everything above that, including applying operating system updates, sits with the customer. Move to PaaS, and Microsoft takes over patching the host operating system and the platform runtime, leaving the customer to configure network access rules, deploy application code, and manage the app’s own business logic. Move again to SaaS, and Microsoft runs the entire stack, including the finished application; the customer’s remaining job narrows down to data, accounts, and access.

The trend only ever runs one direction: toward Microsoft taking on more as you move up the stack, never the reverse. A customer never picks up new physical-layer or hypervisor duties by adopting SaaS instead of IaaS — that would contradict the entire premise of moving to a more managed service. And a scenario that asks who configures network access rules in PaaS is really testing whether you understand that the customer still controls application-facing settings even though Microsoft now owns the host OS beneath it.

Understanding this shift also clarifies why IaaS, PaaS, and SaaS are usually taught together — the service model you choose is what determines where the responsibility line actually sits.

How the AZ-900 exam tests this

• The “always the provider’s job” identification. A question asks which task remains with Microsoft no matter the service model. The answer is always something physical — datacenter security, hardware, power, cooling, physical network connectivity. Anything involving data, accounts, or endpoint devices is a trap.
• The “always the customer’s job” identification. A mirrored question asks what always stays with the customer. The answer is data classification and identity/access management; distractors dress up physical-layer or OS-patching tasks that actually shift toward the provider at higher service tiers.
• The IaaS-specific patching question. A scenario places virtual machines in Azure and asks who patches the guest operating system. In IaaS specifically, that’s the customer — Microsoft only takes over OS patching once you move to PaaS or SaaS.
• The cross-model comparison. A question asks how responsibility changes as an organization moves from IaaS toward SaaS. The correct framing is that the provider’s share increases while the customer’s core responsibility for data and identity never disappears — not that the customer takes on more, and not that data ownership ever transfers to Microsoft.

Drilling these four framings against real AZ-900 practice questions is the fastest way to stop second-guessing which side of the line a given task falls on.

Quick reference

• The shared responsibility model exists purely to divide security and operational tasks between Microsoft and the customer.
• Physical datacenter security, hardware, and network infrastructure are always Microsoft’s job, in every service model.
• Data classification and identity/access management are always the customer’s job, in every service model.
• IaaS: Microsoft manages physical infrastructure and virtualization; the customer manages the guest OS, runtime, and application.
• PaaS: Microsoft also takes over OS and runtime patching; the customer manages application code and network access rules.
• SaaS: Microsoft manages the entire stack, including the application; the customer’s job narrows to data and access.
• Responsibility only ever shifts toward Microsoft as you move from IaaS to PaaS to SaaS, never backward.
• With no cloud provider involved at all, an organization bears every layer of responsibility itself.