It is the agreement that divides security and operations duties between the cloud provider and the customer.

When a company runs its own data centre, it is responsible for everything: the building, the power, the cables, the servers, the software, the people and the data. When it moves to the cloud, some of these duties are handed over to the provider, because the provider owns and runs the data centres. But not every duty moves. Some always stay with the customer, because only the customer knows who should have access to its data and how its applications should behave.

The shared responsibility model describes exactly this split. In simple words, Microsoft is responsible for the security of the cloud, which means the physical buildings, the hardware and the core platform. The customer is responsible for security in the cloud, which means the data, the identities, the settings and the applications that the customer puts there.

The model is not a legal contract on its own, but it is the foundation of how Microsoft documents its services, and it is the starting point for understanding any security audit, compliance review or incident investigation in Azure.

Words you will meet again and again

Most cloud security failures come from misunderstanding who was supposed to do what.

New cloud users often make one of two opposite mistakes. The first mistake is to believe that the cloud provider handles everything, so nothing is left to do. A company puts customer records in a storage account, leaves it open to the internet and assumes Microsoft will protect it. The second mistake is to believe that the cloud is unsafe and that the company must do everything itself, which wastes money and effort on duties that the provider already performs better than most companies can.

Both mistakes come from not knowing where the line is. The shared responsibility model draws that line clearly. It helps teams decide where to spend their security effort, helps auditors know what to ask, and helps managers understand why a cloud migration does not remove the need for security staff.

Some duties belong to the same side whatever kind of service you use.

Always the customer’s responsibility

Always Microsoft’s responsibility

The more of the stack the provider runs for you, the less you must secure yourself.

Cloud services come in three main styles. Each hands a different amount of work to the provider.

flowchart LR
  A["On-premises: you manage all layers"] --> B["IaaS: Microsoft manages hardware, you manage OS and above"]
  B --> C["PaaS: Microsoft also manages OS and runtime"]
  C --> D["SaaS: Microsoft manages almost everything, you manage data, users and devices"]
        

Examples make the model concrete, so let us look at who does what for some popular services.

Walking up the stack from the ground floor to the data shows how each layer is protected.

flowchart TD
  C["Customer always: Data, Devices, Identities"] --> S["Shared: Identity infrastructure, Network controls, Applications"]
  S --> V["Varies by service: Operating system and runtime"]
  V --> M["Microsoft always: Hosts, Network, Data centre"]
        

Identity is the new perimeter, and it is entirely in your hands.

In the old days, security meant a strong wall around the office network. In the cloud, people connect from homes, cafes and phones, so the key question is no longer “where are you?” but “who are you, and are you allowed?”. Microsoft Entra ID provides the platform for identities, but how you use it is your job.

Data is the reason attackers come, so protecting it is the heart of your duties.

Microsoft encrypts data at rest by default for most Azure storage and database services, using strong algorithms, and protects data in transit with secure connections. These are important protections, but they do not decide who may read the data once it is decrypted for an authorised user. That decision is yours.

Microsoft protects the physical network, and you design the virtual one.

Microsoft defends the global network that connects its data centres, including protection against large floods of fake traffic. But inside your own virtual network, you decide the layout. Which servers may talk to each other? Which can reach the internet? Which can be reached from the internet? Azure gives you the tools, and you must use them carefully.

This is the layer where IaaS and PaaS differ most.

With virtual machines, the guest operating system is yours. Microsoft patches the physical host and the virtualisation layer underneath, but inside the machine you must apply operating system updates, install protection software, configure the local firewall and remove software you do not need. A server that runs unpatched for a year is an open invitation.

Whatever you build on Azure is yours to secure, however well the platform is protected.

A platform cannot know whether your code handles user input safely, whether your login page is protected against guessing or whether your application writes secrets into log files. Application security is therefore the customer’s work in IaaS and PaaS, and Microsoft’s in SaaS.

Availability is also a shared job, and promises have fine print.

Microsoft builds resilience into the platform: redundant power, many servers, copies of data and service-level agreements that describe expected availability. But an agreement covers the service, not your architecture. If you run an important application on a single virtual machine in a single zone, a hardware failure may take it offline, and the agreement does not make your design resilient.

Microsoft can prove its half, and you must prove yours.

Microsoft’s cloud services are audited against a wide range of international standards and regional rules, and the reports are available through the Microsoft Trust Center and the Service Trust Portal. These reports are valuable evidence for your own auditors. But they cover Microsoft’s responsibilities only. Your auditor will still ask how you configured the service, who has access, how you protect data and how you monitor activity.

When something goes wrong, each side has its own part of the response.

Microsoft monitors its platform around the clock and tells customers about platform incidents through Azure Service Health. If a data centre problem affects a service, Microsoft investigates and fixes it. But Microsoft cannot see inside your applications or tell whether an authorised account is being used by a thief. Watching your own workloads, accounts and data is your duty.

sequenceDiagram
  participant A as Attacker
  participant C as Customer Environment
  participant M as Azure Monitor and Defender
  participant T as Customer Security Team
  participant P as Microsoft Support
  A->>C: Uses stolen credentials
  C->>M: Unusual sign-in and activity logged
  M->>T: Alert raised
  T->>C: Disable account, isolate resources
  T->>P: Open case if platform help needed
  P-->>T: Guidance and platform investigation
        

Microsoft cannot do your part for you, but it gives you strong tools to do it well.

Secure Score and benchmarks

Defender for Cloud checks your resources against the Microsoft Cloud Security Benchmark, a set of recommended controls. It gives a score that shows how well you follow them and ranks recommendations by impact, so you fix the most valuable issues first. Treat the score as a guide to progress, not as a guarantee of safety.

The same idea applies to artificial intelligence, with a few new questions.

When you use an AI service, such as a language model hosted in Azure, Microsoft is responsible for the security of the platform, the infrastructure and the model hosting. You are responsible for how you use it: the data you send, who may call it, the instructions you give it, the way you use its answers and the checks you place around it.

These approaches help teams carry their share without being overwhelmed.

flowchart TD
  U["User on a Device"] --> I["Identity: MFA and Conditional Access"]
  I --> N["Network: Firewall and Private Access"]
  N --> A["Application: Secure Code and Secrets in Key Vault"]
  A --> D["Data: Classification, Encryption, Backup"]
  D --> L["Logging, Alerts and Response"]
        

Stories from everyday practice show where responsibilities are met and where they slip.

These beliefs and habits regularly lead to breaches and failed audits.

Walk through these steps whenever you start using a new Azure service.

It depends on how the theft happened. If it came from a failure of the physical or platform layer, that falls on Microsoft. If it came from stolen credentials, an open setting, an unpatched virtual machine or flawed application code, that is on the customer’s side. In practice, most incidents come from customer-side configuration or identity problems.

Information and data, devices and endpoints, and accounts and identities. These three never move to the provider, even in software-as-a-service.

It removes many infrastructure duties, such as operating system patching, but you still secure your application, your data, your identities and your network exposure. PaaS lowers your workload without taking it to zero.

No. Microsoft’s certification covers its own responsibilities. You must still configure services correctly, control access, protect data and keep evidence for your own part of the standard.

Microsoft patches the physical hosts and the virtualisation layer. You patch the guest operating system and the software you install inside the virtual machine.

Microsoft makes redundant storage and backup features available, but you decide what to back up, how often, how long to keep it and whether restores work. Many services also have built-in backups that you should understand and extend where needed.

No. The agreement describes the availability of the service, assuming you follow its conditions. If you run an important workload on a single instance with no redundancy, a failure can still take you down, and your design decides the impact.

Microsoft secures the platform and model hosting, and offers safety features. You are responsible for the data you send, who may use the service, how you use outputs and how you protect people from harm. The same layered thinking applies.

Read the security and compliance documentation of that service and the Microsoft Cloud Security Benchmark guidance. Then write your own responsibility matrix with an owner for every customer-side duty.

Secure identities. Require multi-factor authentication, remove unnecessary administrator rights and apply conditional access. After that, remove public exposure of data, enable logging and use policy to prevent risky settings.

The shared responsibility model is the simple but vital idea that security in Azure is a partnership. Microsoft secures the physical data centres, network and hosts, and the platform services it runs for you. You always secure your data, devices and identities, and the more of the stack you manage yourself, the more you must secure. The line shifts between infrastructure, platform and software services, so reading the guidance for each service and keeping a clear responsibility matrix prevents dangerous gaps. With strong identity controls, thoughtful data and network design, good monitoring, policy guardrails and honest compliance evidence, you can use the cloud with confidence and keep your share of the promise.