Shared responsibility model
What it is
The shared responsibility model explains which security and operational tasks belong to the cloud provider and which still belong to the customer. Moving a workload to Azure transfers some infrastructure work to Microsoft; it does not transfer ownership of the customer’s data, identities, access decisions, or configuration.
Think of renting a managed building: the owner maintains the structure and utilities, while the tenant still decides who gets keys, how rooms are used, and what valuables are protected.
The boundary changes by service model
| Service model | Microsoft mainly operates | Customer still operates |
|---|---|---|
| IaaS—for example, [[azure-vm | Azure VMs]] | Physical datacenter, physical network, hosts, and hypervisor |
| PaaS—for example, [[app-service | App Service]] | The platform, operating system, runtime, and underlying infrastructure |
| SaaS—for example, Microsoft 365 | The ready-made application and most of its platform and network operation | Data, users, tenant configuration, device protection, and access decisions |
The exact division varies by service and contract, so use the service documentation for a real design. The model is a guide to operational accountability, not legal advice.
Responsibilities you always keep
- Data: classify it, protect it, decide retention and encryption requirements, and meet governance obligations.
- Identities and access: manage users, remove departed users, apply least privilege through RBAC, and use controls such as MFA and Conditional Access.
- Configuration: securely configure the Azure resources and cloud services you control.
- Endpoints: protect the laptops, phones, and other client devices used to access services.
Northwind example
Northwind moves its customer ordering application from a self-managed VM to App Service. Microsoft now operates the App Service platform and operating system, reducing Northwind’s server-patching work. Northwind still owns the application code, database data, Entra user access, app secrets, and network-access configuration. If Luis accidentally grants a broad role or exposes a secret, “Azure manages the platform” does not make that safe.
Avoid this mistake
“Microsoft secures Azure” does not mean “Microsoft secures every customer workload configuration.” A secure outcome needs both sides: Microsoft protects the underlying cloud, while the customer protects the workload choices it controls.
Related
cloud-computing · cloud-deployment-models · azure-vm · app-service · entraid · rbac
📘 Source: Microsoft Learn — Shared responsibility in the cloud