What the Shared Responsibility Model Defines
The Shared Responsibility Model is a framework that draws a clear line between what Microsoft secures and manages versus what the customer must secure and manage in any given Azure service. Microsoft is always responsible for the physical data center, physical network, and physical hosts — customers never manage server room access badges or replace failed hard drives. Everything above that line shifts depending on the service model: in IaaS, the customer manages the OS, network configuration, and applications; in PaaS, Microsoft additionally manages the OS and runtime, leaving the customer responsible mainly for data, identities, and access; in SaaS, the customer's responsibility narrows mostly to data classification and user access management.
Cricket analogy: It's like a stadium owner (Microsoft) always being responsible for the pitch, floodlights, and structure, while the touring team (customer) is responsible for their own strategy and player fitness — the split of who manages what depends on whether it's a full facility rental or just a private net session.
Responsibility Across IaaS, PaaS, and SaaS
In an IaaS deployment like an Azure Virtual Machine, the customer is responsible for patching the guest OS, configuring network security groups, managing endpoint protection, and securing the application code — Microsoft only guarantees the physical infrastructure and hypervisor. In a PaaS service like Azure App Service, Microsoft additionally patches the underlying OS and web server runtime automatically, so the customer's responsibility narrows to application code, configuration, and data. In a SaaS product like Microsoft 365, Microsoft manages nearly everything except data classification, user identities, and endpoint devices, which always remain the customer's job regardless of service model — identity and data are the two responsibilities that never transfer to Microsoft.
Cricket analogy: In IaaS, it's like renting a bare net facility where you bring and maintain your own bowling machine (OS patches); in PaaS, the facility provides a maintained bowling machine and you just focus on batting technique (your app); identity and data are like your own team roster — always yours to manage regardless of the facility type.
Checking Compliance and Responsibility Boundaries
# Example: enforce guest-OS patching responsibility awareness by checking
# VM patch orchestration mode (customer-managed vs Azure-managed)
az vm show \
--resource-group myFirstRG \
--name myFirstVM \
--query "osProfile.linuxConfiguration.patchSettings" \
--output jsonEven in fully managed PaaS or SaaS services, the customer always retains responsibility for data classification, endpoint devices, and account/identity security — Microsoft's Shared Responsibility Model never shifts these to Microsoft, regardless of service tier.
Why This Model Matters for Security Posture
Misunderstanding the Shared Responsibility Model is one of the most common causes of real-world cloud security incidents — for example, assuming Microsoft encrypts data at rest by default for every storage type, or assuming a firewall is automatically configured on a new VM's network security group. Because the split of duties changes per service, security teams must review the model separately for every Azure service they adopt, and frameworks like the Microsoft Cloud Security Benchmark exist specifically to help customers understand exactly which controls remain theirs to implement.
Cricket analogy: Assuming Microsoft handles a security control it doesn't is like a batter assuming the umpire will call every no-ball automatically and not checking their own front foot — the responsibility for staying within the crease line is always the player's, not the official's.
Do not assume default configurations equal secure configurations. Many Azure services ship with permissive defaults (such as open network access) for ease of initial setup, and it is the customer's responsibility to harden them according to their own security requirements.
- Microsoft always owns physical data center, network, and host security regardless of service model.
- In IaaS, the customer manages the guest OS, network config, and applications.
- In PaaS, Microsoft additionally manages the OS and runtime, narrowing customer responsibility to app, config, and data.
- In SaaS, the customer's responsibility narrows mostly to data classification and user access.
- Identity and data classification never transfer to Microsoft, regardless of service model.
- Default configurations are not automatically secure — hardening is frequently the customer's job.
- Misunderstanding this model is a leading real-world cause of cloud security incidents.
Practice what you learned
1. Which responsibility never transfers to Microsoft, regardless of service model?
2. In an IaaS Virtual Machine, who is responsible for patching the guest operating system?
3. What changes about customer responsibility when moving from PaaS to SaaS?
4. What is a common real-world cause of cloud security incidents related to this model?
5. Are default Azure service configurations guaranteed to be secure?
Was this page helpful?
You May Also Like
What Is Microsoft Azure?
An introduction to Microsoft Azure as a public cloud platform, covering its core service models and why organizations adopt it.
Azure Global Infrastructure
How Azure organizes its worldwide data centers into regions, availability zones, and region pairs to deliver performance and resilience.
Azure Subscriptions and Billing
How Azure subscriptions organize billing and access, and the tools available to monitor, budget, and control cloud spend.