Azure Shared Responsibility Model: Understanding Responsibilities for Cloud Security
Learn the key elements of Azure's shared responsibility model, including the specific areas of responsibility for both cloud service providers and their customers, to effectively protect workloads and data in the cloud.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content
Today’s cloud security is built on the concept of shared responsibility, where both cloud service providers (CSPs) and their customers play distinct roles in protecting workloads and data. The shift has reshaped how organizations approach security. “Born-in-the-cloud” enterprises build their security around their cloud providers’ models from day one. Others, still based on a conventional mindset, take time to complete the transition, focusing first on fundamental areas like identity management and data protection. Both approaches can work—the key is understanding exactly where the CSP’s responsibilities end and yours begin.
In this article, we discuss Azure’s shared responsibility model and break down exactly what Microsoft handles and what falls under your purview. We also explore the key security domains, provide practical examples, and outline specific actions you need to take to protect your cloud environment effectively.
Summary of key security domains for Azure shared responsibility
The following table summarizes some key security domains and respective areas of responsibility for client users.
| Security domain | Your key responsibility |
|---|---|
| Identity orchestration | Configure PIM, RBAC, and conditional access rules to match your organization’s exact access requirements. |
| Infrastructure security | Implement and version-control Azure Policies as code to automatically enforce security standards. |
| Detection engineering | Customize Azure Sentinel rules to match your organization’s specific threat model and normal behaviour patterns. |
| Network architecture | Design and implement network security controls (NSGs, microsegmentation) while leveraging Azure’s native capabilities. |
| Data protection | Implement double encryption using both platform encryption and application-layer encryption with customer-managed keys. |
| Automated compliance framework | Set up automated compliance monitoring through Resource Graph queries and evidence collection. |
| Disaster recovery orchestration | Conduct regular chaos engineering experiments to validate application resilience beyond basic platform replication. |
Understanding the Azure shared responsibility model
Continued investments in cloud security can only deliver real protection if both parties fulfil their responsibilities, which is impossible without understanding where Azure’s duties end and yours begin. Unfortunately, it’s all too common to see security and operations teams misaligned: The security team assumes Azure handles certain controls, while the operations team believes those same controls are someone else’s responsibility, creating dangerous gaps in coverage.
There are several pertinent questions:
- What are the boundaries of a shared responsibility model?
- Why isn’t Azure’s security just automatic and functional out of the box?
The table below shows a quick division of security responsibilities. There’s more to it than this, of course—in the sections below, we explore specific domains to show exactly how shared responsibility works in practice.
| Security area | Responsibility | Owner |
|---|---|---|
| Infrastructure security | ||
| Physical security | Datacenter security, hardware integrity | Azure |
| Network security | Network isolation, DDoS protection | Shared |
| Data security | ||
| Data classification | Identifying sensitive data, applying labels | Customer |
| Data encryption | Key management, encryption configuration | Shared |
| Access control | ||
| Identity management | User accounts, role assignments | Customer |
| Platform access | Azure portal security, API protection | Azure |
The Azure shared responsibility model is the fundamental framework that defines who’s responsible for what in your cloud environment—from the physical datacenter all the way up to your application code. At its core, the model follows a simple principle: Microsoft Azure manages everything physical, while you handle everything virtual.
The responsibility matrix also shifts based on your service type:
- IaaS: You own most responsibilities above the hardware.
- PaaS: Microsoft handles more, but you own application security.
- SaaS: Microsoft manages most, while you handle access and data.
It is important to note that this model isn’t static: As Azure introduces new services and features, the responsibility lines can shift. For the same reason, many organizations review their responsibility boundaries quarterly and adjust their security controls accordingly.
Manage, Monitor & Recover AD, Azure AD, Office 365
Unified Console
Use a single tool to administer and secure AD, Azure AD, and Office 365
Track Threats
Monitor AD for unwanted changes – detect for security or critical functions
Instant Recovery
Recover global enterprise-wide Active Directory forests in minutes, not days
The Azure shared responsibility model: What's yours and what's Microsoft's?
A cloud provider that clearly defines security boundaries shouldn’t leave any room for ambiguity about who handles what. That said, every organization using Azure should maintain a clear inventory of its security responsibilities, often called a security responsibility matrix or control ownership map. Each security domain is assigned clear ownership in an enterprise cloud environment. Let’s examine each domain and understand exactly what is your responsibility.
Identity orchestration
Identity services in Azure follow a clear line of responsibility that often surprises organizations new to cloud security. Although Azure provides the identity infrastructure—the PIM service, conditional access features, and RBAC frameworks—everything about how these tools actually control access falls squarely on the organization’s shoulders.
Setting up these controls isn’t particularly complex, but it requires careful thought about who needs access to what and when. Organizations must configure PIM themselves, define their own conditional access rules, and further establish their own governance processes. While these tools are powerful, their effectiveness depends entirely on your configuration choices.
Here’s specifically what falls under your domain:
- Configuring PIM activation windows and approval workflows
- Implementing conditional access policies based on risk signals
- Designing RBAC roles that follow the principle of least privilege
- Setting up regular access reviews and governance processes
- Monitoring identity usage patterns and responding to anomalies
A clear separation of duties makes perfect sense when you think about it: Microsoft can’t possibly know your organization’s specific security requirements or risk tolerance. The company provides the tools, but you’re responsible for using them effectively to protect your resources.
Infrastructure security governance
There are dozens of security controls available in Azure Policy, from basic resource tagging to complex network configurations. While scanning environments against these policies takes minutes, implementing them effectively is another matter entirely.
The real challenge lies in translating security requirements into automated policies that actually work in practice. This often requires collaboration between security and infrastructure teams to define controls that aren’t purely technical, like determining appropriate network segmentation rules or deciding which resource types should require specific tags. These policies become part of your infrastructure code, where they silently enforce standards without being visible to most users.
The recommended practice here is treating these security policies as code—in essence, version-controlling your Azure Policy definitions alongside your infrastructure templates, testing them thoroughly before deployment, and maintaining them with the same rigor as application code. Organizations that follow this approach consistently show faster security validations—often many times quicker than traditional methods—and maintain better security posture through automated enforcement.
Detection engineering
There are several detection rules and analytics queries built into Azure Sentinel that are designed to catch common security threats and suspicious behaviors. In this case, Microsoft handles the heavy lifting of data ingestion and basic correlation rules.
Tuning these detections, in most cases, is a complicated cross-functional topic because it requires security teams to deeply understand their environment and create rules that match their specific threat model. A collaboration between security operations and business units should agree in principle on detections that aren’t purely technical, such as determining what constitutes suspicious behaviour for different user roles and departments. For example, a custom detection rule might flag when a user accesses sensitive data outside their typical working hours, but what’s “typical” varies greatly between organizations and internal teams.
Detection engineering responsibility model
Consider developing your detection strategy in phases. You can start with Azure Sentinel’s built-in detections as your baseline, then systematically build custom rules that reflect your organization’s specific threat model.
A typical flow would involve the following:
- Begin with a thorough assessment of your environment’s normal behaviours and potential risks.
- Create initial detection rules on Sentinel that target your most critical security concerns.
- Document the reasoning behind each detection to help with future updates.
- Establish a regular review cycle to tune and refine these rules.
Manage, Monitor & Recover AD, Azure AD, M365, Teams
| Platform | Admin Features | Single Console for Hybrid (On-prem AD, Azure AD, M365, Teams) | Change Monitoring & Auditing | User Governance (Roles, Rules, Automation) | Forest Recovery in Minutes |
| Microsoft AD Native Tools | ✓ | ||||
| Microsoft AD + Cayosoft | ✓ | ✓ | ✓ | ✓ | ✓ |
Network security architecture
When organizations move to Azure, their network architects often follow a familiar path of recreating their on-premises security controls in the cloud. The approach seems logical at first glance; after all, organizations remain responsible for securing their workloads in the cloud, and Azure only provides the underlying network infrastructure.
However, this common practice often leads to inefficient security architectures, and in most cases, the native capabilities of Azure aren’t fully leveraged. As a result, organizations end up maintaining duplicate security layers, managing complex routing rules, and deploying traditional firewalls when simpler, cloud-native solutions would have sufficed.
Network security shared responsibility model
Microsegmentation in Azure presents a perfect example of this shift in approach. While traditional networks rely on complex firewall rules and VLANs for segmentation, Azure enables granular control through Network Security Groups (NSGs). These NSGs act as built-in distributed firewalls that allow security teams to create precise traffic controls down to the individual workload level. For instance, a database server in a backend subnet can be configured to accept traffic only from specific application servers regardless of their network locations.
Just as with other security domains, the key is knowing which security elements Azure manages natively and which require customer configuration. When implementing NSG rules, Azure handles the underlying enforcement and scale, but your team must design the right level of segmentation. A common pattern is to start with broad subnet-level NSGs and then apply more specific rules at the network interface level. For example, you might set baseline rules that block internet access at the subnet level, then add focused rules that permit only necessary protocols between application tiers.
Data protection strategy
Double encryption with automated classification creates defense in depth. Double encryption means combining application-layer encryption using customer-managed keys with platform encryption; automated classification, on the other hand, means systematically identifying and categorizing data to determine appropriate protection levels.
Double encryption with automated classification
After implementing platform-level encryption provided by Azure, it’s relatively straightforward to add application-layer encryption using customer-managed keys through Azure Key Vault. The additional layer protects against both external threats and privileged access scenarios. Organizations can then implement automated classification using Azure Purview to ensure that the right level of protection is applied to different data types. Security teams can create clear policies and procedures for key rotation and access management to make the implementation even more manageable.
A key advantage of implementing this layered approach is that you gain higher confidence in your data protection posture. You can also demonstrate strong security controls during compliance audits—a practical way to address both regulatory requirements and internal security policies while maintaining operational efficiency.
Automated compliance framework
The journey to automated compliance should follow a logical progression. Azure brings platform-level certifications, built-in assessment capabilities, and Resource Graph foundations to the table. Organizations should then build upon these by implementing continuous monitoring through custom Resource Graph queries, configuring automated evidence collection, and establishing resource tagging strategies. This combination can reduce audit preparation effort considerably while maintaining stronger compliance visibility.
Of course, larger enterprises often have dedicated compliance teams and sophisticated requirements. However, organizations of all sizes can benefit from this automated approach, and smaller companies may find it particularly valuable because it reduces the manual overhead of compliance management. Starting with even basic automation—implementing a few key Resource Graph queries and setting up automated evidence collection—delivers significant benefits. Getting these fundamentals right, even if it means investing additional time in initial setup, proves worthwhile through reduced audit preparation time and improved compliance visibility across your Azure environment.
Watch demo video of Cayosoft’s hybrid user provisioning
Disaster recovery orchestration
Most organizations configure Azure Site Recovery and cross-region replication, expecting these platform features to handle their resilience needs. But that’s too optimistic. While Azure manages platform-level chaos (like datacenter failures), you’re responsible for understanding how your applications behave when these failures occur.
The trick is to get creative with chaos engineering within Azure’s constraints. One practical approach is running controlled chaos experiments during maintenance windows. Have your engineering team deliberately trigger failures—perhaps terminating instances or simulating network partitions—while respecting Azure’s platform boundaries. Organizations conducting monthly chaos experiments usually identify more potential recovery gaps than those relying on traditional DR testing.
Disaster recovery orchestration phases
Note that the recommendation is not just testing Azure’s capabilities but validating your applications’ resilience to platform-level chaos. This approach transforms disaster recovery from a checkbox exercise into an engineering practice that clearly differentiates Azure’s responsibilities and yours.
How can Cayosoft protect your Azure environment?
Cayosoft offers a unified platform for managing and securing Microsoft environments, including Active Directory, across on-premises, hybrid, and cloud infrastructures. Cayosoft Guardian offers specialized capabilities and automated rollback capabilities that typically resolve security incidents faster than those relying on manual recovery procedures.
Cayosoft Guardian enhances Azure environment protection through:
- Continuous monitoring of Entra ID configurations and critical changes
- Automated detection and response to unauthorized modifications
- Rapid recovery options, including granular rollback and full directory restoration
- Integration with hybrid identity environments for comprehensive protection
Identity infrastructure protection
Most organizations rely on native backup tools for AD and Entra ID (formerly Azure AD) protection, but that’s insufficient for modern identity environments. While Azure offers basic recovery options, Cayosoft Guardian transforms recovery from a slow, manual process into automated, granular operations.
Restoring AD with Cayosoft Guardian
The key is Guardian’s real-time capture of identity changes. For example, when unwanted modifications occur to GPOs or user accounts, administrators can instantly roll back specific changes without full system restoration. Organizations using Guardian’s granular recovery typically resolve identity incidents in minutes rather than the hours required with traditional tools.
Operational visibility and control
The traditional approach to monitoring identity infrastructure relies on scattered logs and multiple monitoring tools. Guardian replaces this with a unified monitoring approach across on-premises AD, Entra ID, and hybrid environments.
Cayosoft Guardian dashboard
Guardian’s monitoring capabilities include:
- Real-time detection of changes across the identity infrastructure
- Detailed attribution of who made changes, when, and where
- Built-in analysis to identify suspicious patterns
- Automated responses to unauthorized modifications
Threat detection and response
Most identity protection tools focus on after-the-fact recovery, but Guardian takes a proactive stance. It continuously analyzes identity infrastructure for potential vulnerabilities and attack patterns. Organizations using Guardian’s automated threat detection typically identify and remediate security risks before they lead to breaches.
Key capabilities include:
- Continuous monitoring of identity configurations
- Detection of known attack patterns
- Automated response to suspicious changes
- Instant rollback of unauthorized modifications
Learn why U.S. State’s Department of Information Technology (DOIT) chose Cayosoft
Conclusion
The cloud security landscape has evolved dramatically, moving away from traditional perimeter-based approaches toward shared responsibility models where success depends on clear ownership and automated controls. Some organizations have fully embraced this shift, treating security as code and implementing continuous validation through chaos engineering and automated compliance checks. Those that can’t immediately automate everything can instead focus on systematic implementation of controls, starting with identity orchestration and gradually expanding across other security domains.
Whether you’re just starting with Azure or running complex workloads, the key is clearly understanding and systematically implementing your part of the shared responsibility model.
To learn more about how Cayosoft can protect your AD environment, request a free demo here.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content