Key Takeaways
- Azure’s shared responsibility model divides security between Microsoft’s infrastructure controls and customer‑owned data, identity, and workload controls.
- The division shifts with IaaS, PaaS, and SaaS, but customer responsibility for data and identities never goes away.
- Most cloud incidents are linked to customer‑side issues like misconfigurations, excessive privileges, and weak monitoring.
- Strong identity, configuration baselines, DevSecOps, and continuous compliance are essential for Azure security.
- Fidelis Halo® helps automate customer responsibilities across Azure, improving visibility, posture, and enforcement at scale.
Azure’s shared responsibility model explains which security tasks Microsoft takes on within Azure, and which ones stay firmly on the customer’s side. For security and cloud teams in 2026, the harder part is less about understanding that diagram and more about making it work in real environments across IaaS, PaaS, SaaS, and hybrid setups, with enough monitoring and auditability that it will stand up to scrutiny from security, risk, and compliance.
Why the Azure Shared Responsibility Model Matters in 2026
Azure is widely used by enterprises, including organizations that operate in regulated and high‑value sectors. Microsoft’s documentation states that Azure secures the underlying cloud infrastructure—physical hosts, networks, and data centers—while customers are responsible for the security of the data, identities, and workloads they deploy on that infrastructure. Analyst research and breach investigations consistently show that most cloud incidents stem from customer-side misconfigurations, over‑privileged access, and unmonitored assets rather than failures of the provider’s infrastructure.
Fidelis’ work with large enterprises reflects the same reality: even when teams understand the shared responsibility model conceptually, gaps appear when they try to manage identities, configurations, and compliance across fast‑changing Azure estates at scale.
Understanding the Azure Shared Responsibility Model
According to Microsoft documentation, the Microsoft Azure shared responsibility model defines a clear split between what Azure secures and what customers must secure in the cloud. This split varies with service model—on‑premises, IaaS, PaaS, or SaaS—but a few principles are consistent.
Azure’s Security Scope
At a high level, Azure is responsible for:
- Physical data centers
Azure owns and secures the physical data centers, including physical access controls, power, cooling, and environmental controls. - Physical network and hosts
Microsoft secures the physical servers, storage, and networking hardware, as well as core network security for the Azure backbone. - Virtualization layer and underlying infrastructure
Azure manages the virtualization layer that logically isolates tenants and enforces separation between customer workloads, along with the base hypervisor and management services.
In short, the cloud provider handles the “security of the cloud”—the foundational infrastructure on which all Azure services run.
Customer-Owned Security Scope
Customers are responsible for the “security in the cloud”—everything they deploy, configure, and manage:
- Customer data and data protection
You are responsible for data classification, encryption, key management, backup strategies, and controlling access to sensitive data. - Applications and guest operating systems
You own application security, guest OS hardening, security updates, and vulnerability management for your workloads. - Identity and access management
Customers must design and manage identity and access controls, including user accounts, role based access control, multi factor authentication, and conditional access policies. - Network security above the hypervisor
You design and operate virtual networks, network security groups, routing, and firewall rules that govern how workloads communicate.
These responsibilities apply across IaaS, PaaS, and SaaS, even though Azure takes on more or fewer layers depending on the service type.
Responsibility by Service Model: IaaS, PaaS, SaaS
The cloud responsibility matrix shifts depending on whether you’re using infrastructure as a service, platform as a service, or software as a service. Microsoft describes this as a gradient where more abstraction means Azure handles more of the stack, and you handle less—but never nothing.
High-Level Azure Responsibility Matrix
| Layer / Asset | On-Premises (Customer) | IaaS on Azure | PaaS on Azure | SaaS on Azure/M365 |
|---|---|---|---|---|
| Customer data | Customer | Customer | Customer | Customer |
| Application logic & app security | Customer | Customer | Shared (customer config) | Shared (customer usage) |
| Guest operating systems | Customer | Customer | Microsoft | Microsoft |
| Identity & directory infrastructure | Customer | Customer | Shared | Customer (usage) |
| Network security controls | Customer | Customer | Shared | Microsoft |
| Virtualization layer | Customer | Microsoft | Microsoft | Microsoft |
| Physical hosts, network, data center | Customer | Microsoft | Microsoft | Microsoft |
IaaS (e.g., Azure Virtual Machines)
For IaaS, Azure takes care of the physical data centers, hosts, storage, and virtualization layer. Customers own the full stack above that:
- You select, harden, and maintain the guest operating systems running on your Azure Virtual Machines.
- You design and configure virtual networks, network security groups, firewall rules, and routing.
- You handle patching, monitoring, access control, and incident response for the workloads running on those VMs.
PaaS (e.g., Azure App Service, Azure SQL Database)
With PaaS services, Azure moves further up the stack:
- Microsoft runs and patches the operating system, runtime, and most of the platform components that keep the service available and secure.
- You are responsible for application configuration, connection security, authentication and authorization settings, and how data is accessed and stored.
SaaS (e.g., Microsoft 365)
In SaaS scenarios, Azure/Microsoft owns almost the entire technical stack:
- The provider secures the underlying infrastructure, operating systems, and application code for the service.
- Customers still manage user identities, access policies, endpoint posture, and how data is shared, retained, and protected within the service.
Across IaaS, PaaS, and SaaS, this pattern aligns closely with the shared responsibility approach used by AWS and other major cloud providers; the main differences come from each platform’s specific controls, terminology, and tooling, which can add complexity in multi‑cloud setups if responsibilities are not clearly mapped and automated.
Where Azure Ends and You Begin
In its shared responsibility guidance, Microsoft emphasizes that the line of demarcation is fixed on the infrastructure side: Azure owns physical security, infrastructure security, and platform operations; customers own their workloads, identities, and data. Fidelis’ vendor‑agnostic model reinforces this by showing the stack from physical data centers up to application logic, with lower‑level infrastructure clearly marked as provider‑owned and application‑level elements always customer‑owned.
That boundary doesn’t change by contract or SLA—it only shifts as you choose different service types (IaaS vs. PaaS vs. SaaS). For example, moving from VMs to a serverless PaaS may push OS patching to Azure, but it never moves application logic, code, or data classification out of your responsibility.
Once that boundary between Azure’s responsibilities and yours is clear conceptually, the next step is to operationalize your side of the model in day‑to‑day security tasks.
- What You’ll Learn:
- Provider vs customer security scope
- Common responsibility gaps
- Need for continuous automation
Your Share of Azure Cloud Security Responsibilities
Once the line between what Azure secures and what you own is clear, the real work is putting your side into practice. In practical terms, this work usually falls into the same areas: data, applications, identities, platform configuration, and monitoring—regardless of whether you run virtual machines, PaaS services, or a hybrid mix.
1. Information and data
- Define a small set of data classification levels that match your regulatory obligations and business risk (for example, public, internal, confidential, regulated).
- Treat encryption at rest and in transit as the default, and keep keys and secrets under strict control, whether they sit in Azure Key Vault or another key store.
- Keep an accurate view of where sensitive data lives across regions and services, and spell out which users, services, and applications are allowed to reach it.
2. Application logic and code
- Assume that application code, build systems, and deployment pipelines are part of your cloud attack surface, not just delivery plumbing.
- Lock down source repositories, CI/CD pipelines, container registries, and build servers so they can’t be misused, altered quietly, or mined for credentials.
- Build security testing into the delivery flow so problems are caught before deployment, and run production applications with hardened configuration, least‑privilege identities, and logs that actually support investigation.
3. Identity and access management
- Design your identity and directory setup (for example, Microsoft Entra ID with any on‑prem directories) around clearly defined roles and least privilege.
- Make single sign‑on, strong multi factor authentication, and conditional access standard for administrative and other sensitive accounts, not “nice‑to‑have” controls.
- Regularly review accounts, groups, service principals, and secrets so access stays appropriate over time and de‑provisioning is handled cleanly when people or systems no longer need it.
4. Platform and resource configuration
- Harden guest operating systems on Azure Virtual Machines and keep them on a regular patch and update schedule rather than relying on occasional clean‑up.
- Use network security groups, route tables, and firewall rules so workloads are reachable only from the networks and services that genuinely need to talk to them.
- Rely on policy‑based controls and templates to roll out secure defaults across resource groups, subscriptions, and management groups instead of tuning every environment by hand.
5. Connected infrastructure and monitoring
- Treat on‑premises infrastructure, end‑user devices, and networks that connect into Azure as part of the same risk surface you’re trying to manage.
- Put monitoring, alerting, and incident response in place that covers the assets you control across cloud, on‑premises, and edge, not just a single subscription.
- Aim for continuous, end‑to‑end visibility so activity in one environment can be correlated with events in another, rather than investigating each platform in isolation.
Misconfiguration: The Most Common Failure Point
Fidelis’ shared responsibility whitepaper notes that misconfigurations are a dominant source of cloud risk and cites external research indicating that most cloud security failures are attributable to customer‑side issues rather than provider platforms. Analyst research and published incident post‑mortems report that misconfigured storage, overly permissive identities, unpatched workloads, and exposed management interfaces are frequent root causes of cloud breaches.
Industry surveys report that a large majority of cybersecurity professionals remain extremely to moderately concerned about public cloud security, especially around configuration drift, access management, and lack of unified visibility. In Azure, these concerns materialize when:
- Network security groups are left wide open or not applied consistently.
- High‑privilege roles are assigned broadly instead of using granular role based access control.
- Dev/Test subscriptions are less governed but still connected to production data or identities.
- No centralized system continuously detects and remediates configuration drift across regions and accounts.
This is precisely the gap that shared responsibility automation and CNAPP platforms like Fidelis Halo® aim to close.
Best Practices for Implementing Azure Services in Enterprise Real-Life Scenarios
These practices map directly to the customer‑owned layers of the Azure responsibility model and are meant to be used as a practical checklist.
1. Treat identity as the primary control plane
- Microsoft Entra ID is used as the central identity provider for Azure.
- Multi factor authentication is enforced for all administrative and other high‑risk accounts.
- Role based access control is designed with least privilege as the default.
- Broad Owner or Contributor rights at subscription or management group level are avoided or tightly justified and reviewed.
- Conditional access policies are in place that consider device health, location, and risk level for sensitive operations.
2. Standardize secure baselines for IaaS and PaaS
For IaaS (e.g., Azure Virtual Machines):
- Hardened OS images are created to match corporate security standards.
- Azure Policy is used to enforce use of approved images across subscriptions.
- Network security groups are applied consistently to segment Prod, Dev, and Test.
- Firewall rules are defined to restrict lateral movement and unnecessary exposure.
- Patch management and configuration checks are automated to detect baseline drift.
For PaaS (e.g., Azure App Service, Azure SQL):
- Private endpoints or service endpoints are used instead of public exposure wherever possible.
- Connection strings, identities, and keys are stored and handled securely.
- Administrative access to PaaS control planes is tightly limited and audited.
- PaaS configurations are reviewed against compliance obligations and internal security policies.
3. Integrate security into DevOps and CI/CD
- Code repositories, build servers, registries, and orchestration tools are treated as high‑value assets and hardened accordingly.
- Automated checks for configuration, compliance, and vulnerabilities run as part of CI/CD pipelines.
- Build pipelines fail or flag deployments when critical security checks do not pass.
- Infrastructure as code is used to encode secure patterns for networks, identities, and workloads.
- Standard templates are used for common architectures so secure deployment becomes the default path.
4. Implement policy-driven governance and continuous compliance
- Azure Policy is used to enforce global standards for encryption, logging, tagging, locations, and allowed resource types.
- Management groups are used to apply governance consistently across subscriptions.
- Configurations are continuously assessed against CIS benchmarks and relevant regulatory requirements (PCI, HIPAA, SOC, etc.).
- CNAPP and security analytics tools are in place to detect deviations from policy.
- Identified issues are prioritized by risk and routed to the right teams for remediation with clear ownership.
5. Maintain end-to-end visibility across hybrid and multi-cloud
- Telemetry from Azure, other cloud providers, and on‑premises environments is centralized into a unified analytics platform.
- Asset inventory is continuously discovered and updated across all environments.
- Configuration drift, privileged access, and key network flows are monitored end to end.
- Automated discovery is used to find shadow IT and unmanaged workloads.
- Newly discovered assets are brought under the same shared responsibility controls and monitoring as existing, known systems.
How Fidelis Halo® Operationalizes Your Side of the Azure Shared Responsibility Model
Fidelis describes Halo® as a shared responsibility model automation platform for cloud environments, designed to help customers implement and maintain their responsibilities across Azure and other providers. It works alongside Azure’s native controls and focuses on automating the customer‑owned layers of the responsibility model.
Automating Shared Responsibility Across Azure
Fidelis Halo® provides a broad range of security controls that directly address customer obligations in the Azure model:
- Unified asset discovery and inventory
Automatically identifies and tracks assets across IaaS, PaaS, containers, and hybrid environments so that nothing falls outside monitoring. - Configuration and posture management
Continuously evaluates Azure configurations against policies and best practices, helping detect misconfigurations and configuration drift before they lead to incidents. - Threat detection and indication of compromise
Monitors workload and network behavior for suspicious activity and indicators of compromise across Azure and connected environments. - Network visibility and microsegmentation
Provides visibility into network traffic patterns and supports segmentation strategies that align with least‑privilege network design. - Continuous compliance
Delivers policy packs and rules aligned with major regulatory frameworks and enables ongoing compliance assessment instead of point‑in‑time checks.
These capabilities align with the responsibilities required—asset discovery, vulnerability and exposure management, integrity and drift monitoring, threat detection, and compliance—and apply them consistently across Azure, AWS, and other public cloud services.
Attributes That Matter for Azure Programs
Fidelis highlights eight key attributes of an effective security automation platform—unified, portable, comprehensive, fast, integrated, frictionless, scalable, and cost‑effective. For Azure customers, these attributes translate into:
- A unified view of security posture across multiple Azure subscriptions, regions, and on‑prem extensions.
- Portability of policies and controls when workloads move between Azure, other clouds, and data centers.
- Comprehensive coverage that spans asset discovery, assessment, remediation guidance, threat detection, traffic analysis, and compliance.
- Speed and scalability to keep up with dynamic, ephemeral resources in modern Azure environments.
- Frictionless Operation at Any Scale
- Rapid Issue Remediation
- Seamless DevSecOps Automation
DevOps Integration and Secure Self-Service
Fidelis Halo® also integrates with DevOps processes and workflows, enabling secure self‑service and faster delivery without sacrificing control:
- Developer toolkits and integrations with popular CI/CD tools help embed security checks into build and deployment pipelines. Fidelis Halo integrates with Azure Container Registry (ACR) to scan container images for vulnerabilities before they reach runtime, catching risks early in the delivery flow.
- Automatic ingestion of cloud metadata supports context‑rich assessments and remediation suggestions for DevOps teams.
- Policy-driven automation ensures that as new Azure services or environments are created, required security controls and monitoring are applied by default.
This approach lets security teams empower DevOps and business units to use Azure at full speed while maintaining the organization’s side of the shared responsibility model.
Turning the Azure Responsibility Model into an Operating Model with Fidelis
On a slide, the Azure shared responsibility model looks straightforward: Microsoft takes care of the underlying cloud infrastructure, and you’re accountable for your data, identities, configurations, and applications. In environments with multiple subscriptions, several cloud providers, and a mix of on‑prem and Azure resources, applying that model consistently often requires more than manual processes.
Fidelis Halo® is designed to turn that model from a static diagram into something you can actually run every day by:
- Continuously discovering assets and risks across your Azure and hybrid infrastructure, so you always know what’s out there and how it’s configured.
- Enforcing secure baselines and policies on the customer‑owned layers of the stack, instead of relying on one‑off hardening or manual checks.
- Providing joined‑up visibility, detection, and compliance monitoring across the domains you control, from workloads and identities to networks and DevOps pipelines.
For organizations that depend on Azure for critical workloads, this combination of clear responsibility boundaries and automated enforcement is what cuts risk down to size, strengthens cloud security posture, and lets teams make full use of the cloud without losing sight of the obligations that stay on their side of the model.
Reference:
