Azure Shared Responsibility Model: What Microsoft Secures and What You Must Protect

Introduction

Microsoft Azure can protect the physical data center, maintain the cloud hardware, and secure the virtualization platform. Yet an organization can still expose sensitive information by granting excessive access, leaving a virtual machine unpatched, or deploying a public-facing resource without adequate monitoring.

This is why using Azure does not mean transferring every security responsibility to Microsoft.

The Azure shared responsibility model explains which parts of the environment Microsoft protects and which security duties remain with the customer. The division changes depending on whether the organization uses Infrastructure as a Service, Platform as a Service, or Software as a Service.

For beginners, the principle is straightforward:

Microsoft secures the underlying Azure platform, while customers remain responsible for the identities, data, configurations, applications, and devices they control.

This guide explains how the Microsoft shared responsibility model works, how duties change across service models, and which Azure security controls customers should use to close common responsibility gaps.

What Is the Azure Shared Responsibility Model?

The Azure shared responsibility model is a framework that divides cloud security duties between Microsoft and the customer.

Microsoft is responsible for protecting the physical data centers, physical hosts, core networks, and hypervisor that support Azure services.

Customers remain responsible for their data, user accounts, endpoints, and access management regardless of the cloud service model they choose.

Some responsibilities are shared.

For example, Microsoft may provide security capabilities for applications, networking, monitoring, and data protection, while the customer decides how those capabilities are configured and used.

Why Security Ownership Matters

Azure provides a secure cloud foundation, but it cannot determine how every customer should classify data, assign permissions, configure applications, or meet regulatory obligations.

Without clear security ownership, organizations may experience:

• Excessive user permissions
• Exposed cloud data
• Misconfigured Azure services
• Missing security logs
• Unpatched workloads
• Compliance gaps
• Unclear internal accountability
• Delayed incident response

The model helps technical teams understand their operational duties. It also helps business leaders assign ownership and evaluate cloud risk.

Who Is Responsible for Security in Azure?

Both Microsoft and the customer are responsible for Azure security, but they control different parts of the environment.

Microsoft protects the underlying Azure platform.

The customer protects what it creates, stores, configures, connects, and manages within that platform.

Microsoft may provide identity, encryption, monitoring, networking, and governance capabilities. The customer must decide which controls are required and configure them correctly.

What Microsoft Secures in Azure

Microsoft generally manages:

• Physical Azure data centers
• Environmental and physical access controls
• Physical servers
• Core network infrastructure
• The Azure hypervisor
• Provider-controlled platform components
• Platform operating systems and runtimes in managed services
• Availability and maintenance of Microsoft-controlled infrastructure

These responsibilities are commonly described as security of the cloud.

Customers do not need to secure data center buildings, replace physical servers, maintain cooling systems, or operate Azure’s global backbone.

However, Microsoft’s control of the infrastructure does not mean it makes every security decision for the customer.

What Customers Must Secure in Azure

Customers generally manage:

• Data classification and protection
• User and administrator accounts
• Role assignments and permissions
• Endpoint security
• Application code
• Customer-controlled configurations
• Network rules
• Workload monitoring
• Compliance decisions
• Backup and recovery requirements

These responsibilities are commonly described as security in the cloud.

The exact boundary depends on the Azure service being used.

A Practical Example

Imagine that a business uses Azure App Service to run an application and Azure Storage to hold customer files.

Microsoft operates the physical infrastructure, platform runtime, and managed service components.

The business still controls:

• Who can access the application
• Whether the storage account is publicly accessible
• How sensitive information is classified
• Which identities receive administrative permissions
• How the application authenticates users
• Whether logs and alerts are enabled
• How backups and recovery are configured

If the storage account is exposed through an unsafe customer configuration, that is a customer-side responsibility gap.

If the underlying Azure infrastructure fails because of a provider-controlled issue, that falls within Microsoft’s responsibility.

How Azure Responsibilities Change Across IaaS, PaaS, and SaaS

The customer carries the greatest technical responsibility in Infrastructure as a Service. Microsoft manages more of the technology stack in Platform as a Service and Software as a Service.

However, customers never transfer responsibility for their data, accounts, endpoints, or access management to Microsoft.

Azure IaaS Responsibilities

In Infrastructure as a Service, Microsoft operates the physical infrastructure and virtualization platform. The customer manages the virtual machines and much of the software running on them.

For Azure Virtual Machines, customer responsibilities typically include:

• Guest operating system configuration
• Operating system updates
• Azure patch management
• Installed applications
• Host security
• Network Security Groups
• Administrative access
• Workload data
• Logging and monitoring
• Backup configuration

An organization that deploys a virtual machine but fails to patch its guest operating system cannot assume Microsoft will correct that customer-managed vulnerability.

Azure PaaS Security

With Platform as a Service, Microsoft manages the operating system, runtime, middleware, and more of the underlying platform.

Examples include:

• Azure App Service
• Azure Functions
• Azure SQL Database
• Azure Storage

Customers continue to manage:

• Application code
• API authentication and authorization
• Data classification
• Secrets
• User access
• Service configuration
• Application monitoring
• Regulatory requirements

Azure PaaS security problems often occur when teams assume a managed service also protects insecure application logic, weak access policies, or exposed credentials.

Azure SaaS Responsibilities

In Software as a Service, Microsoft manages most of the infrastructure, operating system, platform, and application stack.

Customers continue to control:

• User accounts
• Authentication
• Permissions
• Tenant settings
• Data governance
• Sharing
• Endpoint security
• Connected applications
• Compliance decisions

Microsoft 365 may be fully managed as a service, but the customer must still control who can access information and how the tenant is configured.

Customer Responsibilities That Always Remain

Some duties remain with the customer regardless of whether the organization uses Azure IaaS, PaaS, or SaaS.

Azure Identity and Access Management

Customers are responsible for creating, managing, reviewing, and removing access.

Azure identity and access management should include:

• Microsoft Entra ID
• Multi-factor authentication
• Conditional Access
• Azure role-based access control
• Least-privilege permissions
• Privileged access reviews
• Rapid employee offboarding
• Workload identity governance

Azure RBAC provides fine-grained access management and helps organizations separate duties while granting only the permissions users require.

Azure service principals and managed identities also require governance.

Managed identities allow Azure resources to authenticate through Microsoft Entra ID without developers storing credentials directly. Where a managed identity is not suitable, organizations may use a properly secured service principal.

Data Security and Compliance

Customers remain responsible for:

• Data classification
• Access restrictions
• Encryption decisions
• Retention
• Data residency
• Backup requirements
• Legal obligations
• Contractual requirements
• Audit evidence

Azure may provide encryption and compliance capabilities, but those features do not automatically make every customer workload compliant.

An Azure security audit should assess customer configurations, permissions, data practices, logs, and operating procedures rather than relying only on Microsoft’s provider-level compliance reports.

Azure Network Security

Microsoft protects Azure’s core networking infrastructure. Customers configure networking controls inside their own Azure environments.

Azure Private Link can provide private access to supported Azure services through private endpoints.

Azure DDoS Protection can provide additional mitigation for supported public IP resources.

The customer still decides:

• Which services require private connectivity
• Which resources need DDoS protection
• Which ports should be exposed
• How networks should be segmented
• Which alerts should be investigated
• Who owns network incident response

Azure Security Services That Support Customer Responsibilities

Azure includes security and governance services that help customers manage their side of the responsibility model.

Microsoft Defender for Cloud

Microsoft Defender for Cloud can help organizations:

• Assess Azure security posture
• Identify security recommendations
• Monitor regulatory compliance
• Find workload vulnerabilities
• Review cloud security risks
• Protect supported workloads

The platform can identify risks, but customers must still assign owners, prioritize findings, complete remediation, and verify that weaknesses have been corrected.

Azure Policy and Cloud Governance

Azure Policy allows organizations to define and enforce rules across management groups, subscriptions, resource groups, and resources.

Policies may be used to:

• Restrict deployment regions
• Require resource tags
• Audit encryption settings
• Prevent unapproved services
• Identify noncompliant resources
• Apply security baselines

Azure cloud governance should combine policy enforcement with clear ownership, approved architecture, exception management, and regular reporting.

Microsoft Cloud Security Benchmark

The Microsoft cloud security benchmark provides recommendations for securing Azure and multicloud workloads, data, and services.

Its control areas include:

• Network security
• Identity management
• Privileged access
• Data protection
• Logging
• Incident response
• Vulnerability management
• Backup
• DevOps security

The benchmark can support an Azure security baseline, but it does not automatically prove compliance with every external standard.

Azure Well-Architected Framework

The Azure Well-Architected Framework helps teams consider security during workload design.

Its security guidance emphasizes principles such as:

• Explicit verification
• Least privilege
• Zero Trust
• Data classification
• Encryption
• Vulnerability reduction
• Threat modeling
• Continuous improvement

Special Responsibilities for Azure Containers and AKS

Azure Kubernetes Service reduces some of the work involved in managing Kubernetes, but AKS security remains shared between Microsoft and the customer.

Microsoft manages supported components of the AKS service. Customers continue to manage workload security, identities, container images, application configurations, network policies, and many cluster-level decisions.

Customer responsibilities commonly include:

• Scanning container images
• Removing vulnerable dependencies
• Restricting Kubernetes API access
• Applying network policies
• Protecting secrets
• Limiting container privileges
• Monitoring workloads
• Managing supported versions
• Completing required upgrades

Azure Policy can also help enforce selected security rules across AKS clusters.

Using a managed Kubernetes service reduces operational work, but it does not remove the customer’s responsibility for the workloads deployed inside the cluster.

Azure Security Best Practices for Customers

Organizations can turn the Microsoft Azure shared responsibility model into practical security controls through the following steps.

1. Document the Responsibility Boundary

For every Azure service, record:

• The service model
• Microsoft’s responsibilities
• Customer responsibilities
• Internal control owners
• Data involved
• Monitoring requirements
• Compliance obligations

Do not assume that an Azure Virtual Machine creates the same customer responsibilities as Azure SQL Database, Azure App Service, or Microsoft 365.

2. Protect Human and Workload Identities

Require strong authentication for administrators, apply least privilege, review role assignments, and remove unused access.

Prefer managed identities over stored application credentials where supported.

3. Enforce Governance Automatically

Use:

• Azure Policy
• Management groups
• Approved landing zones
• Standard resource templates
• Security baselines
• Automated compliance checks

The Azure Cloud Adoption Framework and Azure Well-Architected Framework can help connect governance, architecture, and security decisions.

4. Monitor and Assess Continuously

Azure monitoring should cover:

• Identity activity
• Administrative changes
• Network traffic
• Workload behavior
• Policy compliance
• Vulnerability findings
• DDoS events
• Security alerts

An Azure cloud security audit should verify that controls are operating effectively rather than simply confirming that security tools have been purchased.

5. Maintain Patch and Vulnerability Processes

Identify which operating systems, applications, container images, dependencies, and cluster components remain customer-managed.

Assign remediation deadlines according to risk and verify that critical vulnerabilities are resolved.

Frequently Asked Questions

What Is the Azure Shared Responsibility Model?

The Azure shared responsibility model divides cloud security duties between Microsoft and the customer.

Microsoft secures the underlying Azure infrastructure. Customers secure their identities, data, endpoints, configurations, applications, and customer-controlled access.

What Is Microsoft Always Responsible for in Azure?

Microsoft is responsible for Azure’s physical data centers, physical servers, physical networks, and hypervisor.

It also manages more operating system, runtime, middleware, and application responsibilities as customers move from IaaS to PaaS and SaaS.

What Is the Customer Always Responsible for?

Customers always remain responsible for their data, endpoints, user accounts, and access management.

This includes deciding who can access Azure resources and how that access is protected and reviewed.

Is Microsoft Responsible for Patching Azure Virtual Machines?

Microsoft patches the underlying Azure infrastructure.

Customers are generally responsible for patching the guest operating system and applications running inside customer-managed Azure virtual machines.

Microsoft handles more platform patching in managed PaaS and SaaS services.

Does Azure Automatically Make a Workload Compliant?

No.

Azure provides compliance capabilities, documentation, and security services, but customers must configure their workloads correctly and demonstrate that customer-controlled policies and processes meet applicable requirements.

Make Security Ownership Clear in Azure

The Azure shared responsibility model is not simply a contractual boundary between Microsoft and its customers. It is a practical guide to security ownership.

Microsoft protects the Azure platform. Customers remain responsible for how identities, data, applications, networks, and workloads are configured and used.

Strong Azure security programs:

• Document the responsibility boundary
• Assign customer-controlled tasks to named owners
• Automate governance
• Monitor important resources continuously
• Review controls when services or workloads change
• Test incident response and recovery processes

The Shared Responsibility Model Across AWS, Azure, and GCP course explains how provider and customer duties change across the major cloud platforms.

Explore the course to build a clearer understanding of Azure security ownership and reduce responsibility gaps across Azure and multicloud environments.