Azure Shared Responsibility Model: What Microsoft Manages vs What You Manage

Why the Model Matters

Before cloud computing, running software meant owning or leasing physical servers. Your security team was responsible for everything: the building’s physical access, the hardware, the network, the operating system, the application, and the data. Nothing was shared because nothing was hosted by someone else.

When you move to Azure, Microsoft takes on some of those responsibilities — but not all of them. The specific split depends on the service model. The dangerous misconception is assuming that “moving to the cloud” means Microsoft takes care of security. It does not. Microsoft handles security for the layers it owns. The layers you still own require the same attention they always did.

A well-configured Azure deployment with strong access control, patched systems, encrypted data, and proper network segmentation is your team’s work. Azure provides the tools and the foundation; using them correctly is your responsibility.

The Responsibility Matrix: IaaS vs PaaS vs SaaS

The table below shows who is responsible for each security domain across the three service models. “Customer” means you own it. “Microsoft” means Microsoft handles it. “Shared” means both parties have responsibilities in that area.

“Shared” does not mean you can ignore that row. It means both parties have a role. For identity, for example, Microsoft provides Microsoft Entra ID as the identity platform (their part), but whether you enable multi-factor authentication, configure conditional access policies, and audit sign-in logs is your responsibility (your part). Skipping your part of a “shared” responsibility leaves a security gap regardless of what Microsoft does.

IaaS: Azure Virtual Machines

Infrastructure as a Service gives you the most control and the most responsibility. An Azure VM is a virtual computer running on Microsoft’s hardware in Microsoft’s datacenter. Microsoft handles everything from the concrete walls to the hypervisor. The moment your operating system boots inside the VM, you are responsible.

What this means in practice for a team running Azure VMs:

• OS patching: You must keep the Windows Server or Linux OS inside the VM patched. Azure provides Azure Update Manager to help automate this, but the decision to patch and the act of applying patches is yours. An unpatched VM with a known vulnerability is your risk.
• Firewall and NSG configuration: Azure provides Network Security Groups (NSGs) to filter traffic to and from VMs. Whether you configure those NSGs correctly — blocking unnecessary ports, allowing only required traffic — is your responsibility. A misconfigured NSG that allows SSH or RDP from the public internet is a customer mistake, not an Azure failure.
• Antivirus and endpoint protection: Running antivirus software on your VMs is your responsibility. Azure Defender for Servers can provide this, but it must be explicitly enabled and paid for.
• Disk encryption: Azure encrypts storage at rest by default (Azure Storage Service Encryption), but whether you also encrypt your VM disks with Azure Disk Encryption for customer-managed keys depends on your compliance requirements and is your decision.
• Backup: Snapshot-based backups of VM disks must be configured by you. Azure Backup is the recommended service for this, but you must set it up.

PaaS: Azure App Service and Azure SQL Database

Platform as a Service abstracts the operating system. When you run an application on Azure App Service, you deploy your code into a managed container that Microsoft operates. You do not SSH into the underlying host, and you do not patch the OS. That burden shifts to Microsoft.

What remains your responsibility on PaaS:

• Application code: If your application has a SQL injection vulnerability, that is not something Azure can prevent. Writing secure code is always the customer’s job.
• Access control: Who can deploy to the App Service? Who can read the database? Configuring RBAC, network access restrictions, and authentication providers is your work. An App Service with no authentication configured is accessible to anyone who knows the URL.
• Data protection: Azure SQL Database offers Transparent Data Encryption (TDE) enabled by default. But whether your data should also be encrypted at the application level before it reaches the database, and how you manage the encryption keys, is a decision you make based on your requirements.
• Configuration of PaaS features: Azure App Service has TLS settings, access restriction rules, and managed identity options. These are not configured by default to the most secure settings. You configure them according to your requirements.

A practical example: Azure SQL Database automatically applies security patches to the database engine. You never have to think about patching SQL Server. But if a developer writes a query that does not use parameterized inputs, SQL injection is possible — that vulnerability is in your code, and Azure patching the database engine does not fix it.

See Azure Security Best Practices for concrete steps to harden PaaS services.

SaaS: Microsoft 365 and Azure-Native SaaS

Software as a Service means you consume a fully managed application. Microsoft 365 (Teams, SharePoint, Exchange) is the most common SaaS example for Azure customers. Microsoft manages everything except your data, users, and configuration.

On SaaS you are still responsible for:

• User accounts and access: Who has access to Teams? Who is a SharePoint admin? Configuring Microsoft Entra ID properly, enforcing MFA, and managing user lifecycle (provisioning and deprovisioning) is your responsibility.
• Data classification: What data do your users store in SharePoint? Is sensitive data labeled correctly? Are retention policies configured?
• Client device security: The device your employee uses to access Microsoft 365 is yours to secure. A compromised endpoint can access SaaS services regardless of how well Microsoft has secured their servers.

What Is Always Your Responsibility

Regardless of whether you use IaaS, PaaS, or SaaS, three categories are always the customer’s responsibility:

1. Your data and content. Microsoft manages the infrastructure your data sits on, but the data itself — its classification, access controls, retention, and protection — is yours. Microsoft will not tell you that you are storing sensitive data incorrectly.

2. Your users and identities. Who has accounts? Who has elevated privileges? Are those privileges still needed? Is MFA enabled for all administrative accounts? Microsoft provides the tools; your team manages the configuration.

3. Client devices. Any device used to access Azure resources — laptops, phones, tablets — is outside the scope of what Microsoft secures. A stolen unencrypted laptop with a browser session open to the Azure portal is a significant security risk regardless of how secure Azure’s servers are.

These three areas are why zero-trust security principles — verify every request, assume breach, use least-privilege access — matter even when running entirely on Azure. See Azure Identity Basics for where identity security starts.