Azure Shared Responsibility: What CSP Customers Own Above the Hypervisor

The Azure Shared Responsibility Model reads almost identically to AWS's: Microsoft is responsible for the security of the cloud, the customer is responsible for security in the cloud. The line sits at the hypervisor. Microsoft handles the physical data centers, networking hardware, and the Hyper-V layer that runs your virtual machines. Everything above that boundary is the customer's, including for organizations that bought Azure through a Microsoft Cloud Solution Provider.

For government agencies, higher education institutions, and healthcare organizations running Azure through a CSP, this is where most operational gaps form. The CSP relationship adds a layer of perceived management that often does not match the actual scope of what the CSP is doing. The result is environments where everyone assumes someone else is patching the OS, reviewing identity, and watching the security findings.

What Microsoft Actually Manages

Microsoft is responsible for the physical security of Azure data centers, the hypervisor, the underlying network fabric, and the managed services Microsoft operates directly. If a host machine fails in an Azure region, Microsoft handles the recovery. If Hyper-V has a vulnerability, Microsoft patches it. If a regional outage occurs from infrastructure failure, Microsoft drives the response.

For Azure-managed services (Azure SQL Database, Azure Functions, Azure Storage, Azure Kubernetes Service in its managed control plane), Microsoft manages more of the stack. The customer still configures the service, secures access, and protects the data, but the underlying compute and storage are Microsoft's responsibility.

That responsibility ends at the operating system on Infrastructure-as-a-Service workloads. Anything you run on a Virtual Machine, anything you put into a Storage Account, any Entra ID configuration, any NSG rule, any application code is yours.

The CSP Adds Another Layer of Confusion

The Cloud Solution Provider model is how Microsoft distributes Azure through partners. A CSP can sell Azure subscriptions on a customer's behalf, often with a margin built into the pricing. Some CSPs also offer managed services on top of the subscription. Most do not.

The confusion in practice: an agency or institution buys Azure from a CSP and assumes the CSP is "managing" the environment because there is a billing relationship and quarterly reviews. The CSP is in fact reselling the subscription. The operational responsibility for everything above the hypervisor remains with the customer. We have inherited Azure environments where the customer was paying a CSP for two years and the operating systems had not been patched, the NSGs had drifted, and the Defender for Cloud findings stretched back eighteen months unacknowledged.

For agencies running on Azure Government, the same pattern applies. The CSP relationship grants the customer access to the Azure Government compliance posture. It does not grant operational management of the workloads running in that environment.

The Gap Above the Hypervisor

When a customer runs workloads on Azure Virtual Machines, Azure App Service, Azure SQL Database, or any IaaS or PaaS service, the Shared Responsibility Model makes them responsible for guest operating system patches, identity and access management, network configuration, application security, data encryption, logging and monitoring, and disaster recovery validation. Microsoft documents this clearly. The challenge is operationalizing it.

The Six Things Azure CSP Customers Consistently Get Wrong

1. OS Patching Is Not Automatic

Azure does not patch your VMs. Update Management in Azure Automation can orchestrate patching, but only if it is configured, scheduled, and monitored. The number of Azure Government environments we have onboarded with months-old unpatched Linux or Windows VMs is not small. The CSP relationship typically does not include patch management; the customer assumed it did.

2. Entra ID Conditional Access Lives or Dies on Configuration

Conditional Access is the structural layer that prevents most identity-based compromises in Azure environments. Properly configured, it requires MFA for privileged operations, blocks legacy authentication, restricts access to known IP ranges, and applies device compliance checks. Misconfigured (or never configured), it is invisible. Most Azure environments we assess have Conditional Access available but not actually enforcing the policies the institution thinks it has.

3. NSG Drift Is Faster Than You Think

Network Security Groups accumulate exceptions. A port opened for a troubleshooting session, an inbound rule added for a vendor integration, a default-deny weakened for a one-time data load. Without someone reviewing NSG configuration as a standing operational practice, the network attack surface grows quietly. Azure Firewall and Azure Front Door add their own configuration surfaces with the same drift pattern.

4. Defender for Cloud Findings Are Inputs, Not Monitoring

Microsoft Defender for Cloud (formerly Azure Security Center) generates security findings continuously. Enabling it is the first step of a monitoring posture, not the whole thing. Findings have to route to a team that triages them, applies remediations, and tracks closure. We routinely review environments with hundreds of unacknowledged Defender findings, including high-severity items, technically enabled but operationally inert.

5. Azure Policy Without Enforcement Is a Document

Azure Policy can require encryption, restrict regions, enforce tagging, and prevent the deployment of non-compliant resources. Customers commonly define policies and then run them in audit-only mode, treating them as reports rather than guardrails. The policy exists, but the deployment that violates it succeeds anyway. Real policy enforcement requires the policy to be in deny mode for the controls that matter, and that requires confidence that the policy will not break legitimate operations. That confidence comes from operational maturity, not from declaring the policy.

6. Backups Are Validated at Restore, Not at Snapshot

Azure Backup, Azure Site Recovery, and database point-in-time restore give you backup artifacts. They do not tell you whether those artifacts actually restore to a functional state inside your stated RTO. We consistently find Azure environments where backups exist and have never been restored end-to-end. RTO and RPO targets in a business continuity document are not operational reality until they have been validated under simulated failure.

The CSP Distinction: Reseller vs Operator

There is a meaningful difference between an Azure CSP that resells subscriptions and an Azure CSP that operates environments. A reseller handles billing, license procurement, and possibly basic support escalation to Microsoft. An operator takes ongoing responsibility for keeping the environment patched, monitored, and secure under defined SLAs, with named engineers and a contractual escalation path.

Most government agencies running Azure through a CSP have a reseller relationship. The CSP earned the relationship at procurement and has been collecting subscription revenue since. Patching, identity hygiene, NSG review, Defender triage, Policy enforcement, backup validation are all the customer's responsibility, and the customer's IT staff often does not have the cycles or specialized knowledge to operate Azure at the depth required.

We hold Microsoft CSP status specifically to operate Azure environments for government and higher education customers under the operator model. The distinction matters for how the relationship is structured and what the customer can expect when something fails.

What to Ask Any Azure CSP Partner Before Signing

• Who patches the operating systems on Azure VMs, and what is the SLA for critical CVEs?
• Who reviews Entra ID role assignments and Conditional Access policies on what cadence?
• Who triages Microsoft Defender for Cloud findings, and what is the escalation path for high-severity items?
• Are Azure Policies in deny mode for the controls that matter, and who validates that?
• How often is backup restoration tested end-to-end, and who signs off on the test results?
• What does monthly governance reporting include, and who at the institution receives it?
• If a workload fails at 2am, who gets paged, and is that response time in the contract?
• Does the CSP hold appropriate compliance authorizations for the customer's regulatory environment (FedRAMP, HIPAA, FERPA)?

If these questions do not have clear contractual answers with named accountability, the relationship is a reseller relationship, not an operator relationship. The Shared Responsibility Model does not close itself, and the CSP boundary does not close it either. Someone has to own the operational half, every day, under SLA.

Frequently Asked Questions

What does the Microsoft Cloud Solution Provider program actually cover?

The CSP program is Microsoft's distribution model for Azure subscriptions through partners. CSPs handle the subscription procurement, billing, and (typically) Tier 1 support routing. The program itself does not include operational management of Azure environments. Some CSPs offer managed services as a separate engagement on top of the CSP relationship; most do not.

How is Azure Government different from commercial Azure for shared responsibility purposes?

The shared responsibility line is identical: Microsoft manages the cloud, the customer manages what runs in the cloud. The differences are in compliance authorization (Azure Government holds FedRAMP High and DoD IL2 through IL5 authorizations), regional isolation (Azure Government regions are separate from commercial), and operational access (Azure Government operations staff are screened US persons). The customer's operational responsibilities for security in the cloud do not change.

What is the most common Azure misconfiguration in government environments?

Identity and access management. Specifically: privileged Entra ID roles assigned to users without MFA, Conditional Access policies in audit-only mode rather than enforcement, and service principals with long-lived secrets instead of managed identities. These are not configuration errors that surface during normal operations. They surface during compromise.

How does managed Azure for government differ from a CSP reseller relationship?

A managed Azure for government engagement includes operational ownership: defined patching cadence, identity governance under SLA, Defender triage with documented response times, Azure Policy enforcement, backup validation, audit-ready compliance documentation, and named engineers with 24/7 incident response. A CSP reseller relationship covers subscription billing and procurement. The cost difference reflects the operational difference.