How should security teams divide responsibility in Azure between the provider and the customer?

Where Azure Responsibility Boundaries Actually Sit

Azure shared responsibility is easiest to understand when you separate platform operation from tenant control. Microsoft runs the datacentres, core fabric, host infrastructure, and many managed service capabilities, but the customer still decides who can sign in, what data is exposed, how applications authenticate, which network paths are open, and whether logging and alerting are enabled. That division matters because breaches often arise at the boundary where a secure provider baseline meets an unsafe customer configuration. The most important mistake is assuming the cloud provider automatically secures tenant-level identity, data, and access design. For a control-oriented reference, NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for framing which protections belong to the organisation rather than the platform.

In practice, many security teams discover this boundary only after a misconfiguration, over-permissioned identity, or exposed service has already created tenant-level exposure.

How Azure Shared Responsibility Works in Practice

The cleanest way to map responsibility is by layer. At the infrastructure layer, Microsoft handles physical security, hardware, host operating systems, and the resilience of the cloud platform itself. At the service layer, responsibility shifts depending on whether the customer is using infrastructure as a service, platform as a service, or software as a service. The more managed the offering, the more Microsoft absorbs for patching and service operation, but the customer still retains control over access, data handling, configuration, and business use of the service.

For security teams, the practical issue is not the label on the service but the control boundary. Customer-owned responsibilities usually include identity lifecycle, privileged access, conditional access, authentication policy, workload permissions, encryption key decisions, network segmentation, logging configuration, and incident response readiness. If the team assumes Microsoft covers these by default, the result is often invisible exposure rather than obvious failure. That is especially true in Azure because many high-impact risks come from tenant settings, not from the cloud fabric itself.

• Microsoft typically owns physical protection, core platform availability, and platform patching for managed services.
• The customer typically owns identity governance, data classification, application security, network exposure, and secure configuration.
• Shared services require the team to verify where responsibility shifts for patching, hardening, monitoring, and recovery.
• Continuous monitoring matters because misconfiguration can remain valid from the platform’s point of view while still being insecure for the tenant.

Where teams should be careful is assuming a single rule set applies to every Azure service. A database platform, container service, and virtual machine do not split responsibility in the same way, even when they run in the same cloud account. The guidance breaks down when organisations treat service convenience as equivalent to security ownership.

When the Boundary Gets Messy: SaaS, PaaS, and Identity Dependencies

Tighter cloud abstraction often reduces operational burden, but it also increases the chance that teams misunderstand which controls they still own. That tradeoff is most visible in managed services, identity integrations, and third-party tooling, where the provider may secure the service but not the way the tenant uses it.

There is no universal consensus that every Azure service should be governed with the same control depth; the correct answer depends on the service model and the sensitivity of the workload. For example, a SaaS product may leave far less patching to the customer than a VM-based workload, but the customer still owns user access, data retention choices, and administrative roles. In PaaS, the provider may manage more of the runtime, yet the customer still has to secure the application code, secrets, and permissions. In IaaS, the customer takes on the broadest security burden because operating system hardening, patching, and host configuration move much closer to the tenant.

Identity is the clearest bridge between provider and customer responsibility. Microsoft can provide the identity platform, but the customer governs accounts, privileged groups, access reviews, and any delegated administration. That means the highest-risk failures often come from trust assumptions, not service outages. Teams should also be cautious with inherited control claims from partners or integrators, because responsibility can be operationally outsourced without being contractually transferred. In practice, teams often discover that the service is functioning exactly as designed while the tenant’s security expectations were never actually implemented.

Practitioner Guidance

What to prioritise: Build your Azure responsibility model around the highest-risk tenant decisions first: identity, data, external exposure, privileged administration, and logging. Those are the areas where “shared” often means the customer still has the decisive control.

What to verify: Confirm the responsibility split for each Azure service you use, rather than assuming one cloud-wide rule applies. The verification point is whether the control is managed by Microsoft, configured by the customer, or shared in a way that creates an operational handoff.

Common mistake: Treating managed service adoption as a transfer of security ownership. The service may reduce patching and infrastructure work, but it rarely removes the need for explicit tenant governance, monitoring, and access discipline.

What practitioners underestimate: The most fragile part of the model is not the provider boundary itself, but the assumptions teams make about it. When those assumptions are wrong, the environment can appear healthy until an identity or configuration issue turns into real exposure.

Practitioner takeaway: The best Azure governance treats responsibility as a control mapping exercise, not a procurement slogan: if the customer can still configure it, the customer still owns the risk.

Related resources from NHI Mgmt Group

• How should security teams divide responsibility between IAM and IGA?
• How should security teams decide between service principals and managed identities in Azure?
• How should security teams split responsibility between workload IAM and API security?
• How should security teams decide between a lightweight gateway and a full identity provider for self-hosted apps?