Infrastructure Controls Required for HIPAA on Azure

Azure is HIPAA-eligible. That's not the same thing as HIPAA-compliant, and the gap between those two words is where most breaches actually happen. Microsoft secures the data centers, the network hardware, the hypervisor layer underneath your workload. Everything else, identity, encryption settings, network segmentation, logging, the actual application handling patient data, sits on the customer's side of the line. HHS OCR has been clear that misconfiguration, not some flaw baked into the platform, drives most HIPAA breaches. In 2025 alone, 642 healthcare data breaches were reported to OCR, affecting at least 57 million people. This piece walks through exactly which controls belong to the customer, in roughly the order they need to get built.

The stakes aren't abstract. IBM and Ponemon's 2024 report put the average cost of a healthcare data breach at $9.77 million, the highest of any industry for 14 straight years running. Most of that cost traces back to application-layer failures: bad access controls, missing encryption, logging nobody configured. And the penalties are climbing too. HHS adjusted its Tier 4 annual cap for identical violations to $2,190,294 as of January 2026. None of this is theoretical for the engineer configuring the resource group.

What the BAA with Microsoft actually covers, and what it leaves entirely to you

Microsoft includes a HIPAA business associate agreement as part of its Online Services Terms and Data Protection Addendum. It costs nothing extra, and it's accepted automatically once a covered entity or business associate agrees to the OST on a qualifying commercial plan. No separate contract to negotiate. Coverage kicks in under three agreement types: an Enterprise Agreement, a Cloud Solution Provider arrangement through a Microsoft partner, or the pay-as-you-go Microsoft Online Subscription Program with the BAA addendum attached.

Here's what that agreement actually promises: Microsoft's legal commitment to safeguard the infrastructure underneath covered services. It says nothing about whether your application, your data handling, or your access controls meet HIPAA's bar. That part is still entirely on you.

And not every Azure service falls under the BAA. Coverage only extends to services Microsoft explicitly lists as HIPAA-eligible in its Product Terms, so eligibility needs checking at the workload level, sometimes down to the individual feature, before any ePHI touches it. Azure Virtual Machines, Azure Storage, Azure SQL Database, Azure App Service, Azure Kubernetes Service, Azure Functions, Azure Logic Apps, and Azure Key Vault all show up as HIPAA-eligible building blocks in Microsoft's documentation. AI services need extra care: Azure OpenAI covers certain production-level interactions under the BAA, while Azure Computer Vision and Face API aren't HIPAA-eligible by default. Preview features, across the board, are generally excluded.

For teams weighing cloud providers, Azure covers roughly 80 services under its BAA, compared to around 150 for AWS and about 100 for another cloud provider. That doesn't rank one provider above another on security, it just means the eligible surface area differs, and using an ineligible service to touch PHI is a violation no matter how well you've encrypted everything else. Eligibility can shift too, as services get renamed or updated, so it's worth checking again whenever a design changes, and tagging or data loss prevention rules help keep PHI from drifting into a service that was never cleared for it. Before anything ePHI-related touches a new service, confirm its BAA status through the Microsoft Service Trust Portal.

What the 2026 Security Rule update changed about which controls are mandatory

HHS OCR proposed the first major overhaul of the HIPAA Security Rule since its last significant update, issuing a Notice of Proposed Rulemaking on December 27, 2024. As of mid-2026, it's still a proposal, not final law, so the exact timeline could still shift. But the direction is unmistakable, and waiting for the ink to dry is a bad bet.

The biggest change: encryption of ePHI, both at rest and in transit, moves from "addressable" to mandatory. Under the old addressable standard, a covered entity could implement an alternative and document why encryption wasn't necessary. That escape hatch disappears under the proposed rule. Multi-factor authentication gets the same treatment, moving from an optional judgment call to a flat requirement under the proposal.

Azure already offers all three as baseline capabilities, encryption, MFA through Microsoft Entra ID, audit logging through Azure Monitor, without requiring separate procurement. But "available" and "on" are different words. None of these turn on by themselves. Teams that have been treating encryption or MFA as a nice-to-have under the old addressable language need to stop doing that now, regardless of when the rule officially lands. Those three controls, encryption, MFA, and audit logging, are exactly what the next three sections walk through.

Identity and access: configuring Entra ID, RBAC, and Conditional Access for least-privilege PHI access

Identity failures show up more often in OCR enforcement than almost anything else. Memorial Healthcare System paid $5.5 million for insufficient ePHI access controls. The violations behind that number were configuration choices, not infrastructure flaws — exactly the kind of access control gaps that HIPAA enforcement consistently targets.

Microsoft Entra ID (formerly Azure Active Directory) is the identity backbone every PHI system should route through. RBAC assignments should be scoped as narrowly as the workload requires, avoiding overly broad permissions. A nurse pulling up patient records has no business holding administrative rights over the underlying Azure infrastructure, and giving that access "just in case" is exactly the kind of overreach OCR flags.

Conditional Access policies add another layer: location checks, device-compliance checks, so that even a correctly authenticated user can't reach PHI from a personal laptop that's never been enrolled in management. MFA enforcement, proposed as mandatory under the pending rule update, gets configured through Entra ID security defaults or a Conditional Access policy. It shouldn't be something a user opts into.

Access reviews matter just as much as the initial setup. Role assignments drift as people change jobs, and a review cycle that only happens during an audit is a review cycle that's too late. Revoke access the moment someone changes roles or leaves, on a documented schedule, not a best-effort basis. And for encryption key access specifically, Azure Key Vault should enforce separation of duties: the person managing keys and the person accessing the data those keys protect shouldn't be the same set of people.

Encryption: what must be explicitly configured for data at rest, in transit, and in key management

None of what follows is on by default. Every one of these needs a deliberate configuration step.

For data at rest: Azure Disk Encryption covers virtual machine disks. Managed databases like Azure SQL need encryption enabled at the storage layer, it doesn't come bundled just because the service is "managed." Azure Storage encryption needs to be verified for each storage type in use, not assumed because one was set up correctly. Backups and archives need the same treatment: encrypting primary storage while leaving backups in the clear is still a violation, and it's a surprisingly common one.

For data in transit: TLS needs to be enforced everywhere, no HTTP fallback on any endpoint touching PHI, full stop. Azure Application Gateway and Azure Front Door can enforce HTTPS at the edge for web applications. But PHI doesn't only leak at the edge, internal service-to-service traffic needs TLS too, and that includes outbound API calls from tools like Azure Databricks notebooks.

Key management runs through Azure Key Vault, which centralizes storage, access logging, and rotation for encryption keys. Customer-managed keys matter when the organization needs to own the key lifecycle rather than defer to Microsoft-managed defaults, and dual control over key operations, along with a documented recovery process, is a governance expectation auditors will ask about. Access to the vault itself needs the same least-privilege treatment as everything else, and key rotation should run on an automated schedule. Manual rotation is the kind of gap that shows up in an audit finding.

One specific note for Databricks users: any workspace processing PHI needs the compliance security profile turned on, and customer-managed keys for managed services (or the setting to store interactive notebook results in the customer's own account) need explicit configuration. Neither is optional.

Network segmentation: using VNets, NSGs, private endpoints, and WAF to isolate PHI systems

The underlying goal is simple to state: a system holding PHI shouldn't be reachable from general-purpose or internet-facing infrastructure unless that access is explicit and logged. Getting there takes several layers working together.

Azure Virtual Networks create isolated address spaces with their own subnets and routing rules. PHI workloads belong in dedicated subnets, separated from general application traffic, not mixed in because it was easier to stand up that way. A hub-spoke architecture is the pattern worth defaulting to: a hub VNet handles shared services like firewalls and network monitoring, while spoke VNets hold the PHI workloads themselves. That way, if a non-PHI workload gets compromised, the blast radius stays contained.

Network Security Groups act like distributed firewalls at the subnet and network interface level, and they need to run deny-by-default with explicit allowlist rules, not the reverse. Common mistakes in this area include NSG rules that are too permissive and critical resources with no logging turned on at all.

Private endpoints route traffic to Azure PaaS services like Storage, SQL, and Key Vault over the private VNet instead of the public internet, which removes public exposure for anything PHI-adjacent. Any PHI-touching application with a public interface needs a Web Application Firewall in front of it, deployed through Azure Application Gateway or Azure Front Door. And egress controls plus DNS filtering keep outbound traffic locked to known destinations, closing off one of the more common paths for data exfiltration through a compromised or misconfigured service. None of this, VNets, NSGs, private endpoints, Azure Firewall, comes preconfigured the moment a VNet gets created. It all has to be built.

Audit logging and monitoring: what Azure Monitor, Log Analytics, and Defender for Cloud must be configured to capture

HIPAA's Security Rule has always required audit controls that record and examine ePHI activity, and the proposed 2026 update makes that requirement explicit rather than implied. Logs need to capture authentication events, both successful and failed, plus who accessed what PHI, when, and from where. Administrative actions count too: role assignments, policy changes, anyone touching Key Vault. System-level events, service starts and stops, configuration changes, round out the picture.

Retention must meet HIPAA's minimum documentation retention requirements. Log Analytics workspace retention needs to be set explicitly, because the default retention window is shorter than that. Logs also need protection from tampering, which means configuring immutable storage for archived logs rather than trusting that nobody will touch them.

Azure Log Analytics workspaces pull logs from multiple sources into one place, and Kusto Query Language lets a security team dig through that data during an investigation or a compliance review. Alert rules should flag suspicious patterns as they happen: repeated failed logins, access at 3 a.m. that doesn't match a normal shift, a bulk export of records. Reviewing logs after the fact isn't enough on its own.

Microsoft Defender for Cloud runs a continuous assessment of compliance posture, surfacing which controls are met and which still need work. Treat it as an ongoing signal, not a checkbox exercised once during setup. Microsoft Compliance Manager complements that with a HIPAA template tracking control implementation across the environment. And whatever logging pipeline gets built needs to support export to a SIEM or external audit review, not just internal queries run by the team that built it.

Healthcare-specific Azure services and the additional certifications that matter in enterprise healthcare contexts

Azure Health Data Services is Microsoft's purpose-built platform for healthcare data, bundling a FHIR service for clinical interoperability, a DICOM service for medical imaging, and a MedTech service for ingesting data from IoT devices. It's HIPAA-eligible, and it supports private networking, audit logging, and fine-grained authorization, but those capabilities still need to be configured, exactly like everything else in this article. Building on purpose-made healthcare services does cut down the amount of custom configuration compared to assembling the same functionality from general-purpose building blocks, though it doesn't eliminate the work.

On the certification side, Azure carries SOC 1, 2, and 3, ISO 27001, 27017, and 27018, and FedRAMP High in Azure Government regions. For healthcare specifically, HITRUST matters more than most of those. It's a certifiable assurance framework built for healthcare, and HITRUST R2 certification requires an external assessment, which makes it more rigorous, and more recognized, in enterprise healthcare procurement than a SOC 2 report on its own. Plenty of health system procurement teams simply won't accept SOC 2 Type II as a substitute for HITRUST R2.

One distinction worth sitting with: Azure's HITRUST certification covers the platform itself. It says nothing about whether a customer's specific workload running on that platform is HITRUST-certified. That requires its own separate assessment, and skipping that step is a common misunderstanding among teams new to healthcare compliance.

Governance tooling: using Azure Policy and the HIPAA/HITRUST blueprint to enforce controls continuously, not just at setup

Every control described above can be configured correctly on day one and drift out of compliance by month six. Someone loosens an NSG rule to debug a connectivity issue and forgets to tighten it back. A new resource group gets spun up without the encryption settings from the original template. A developer adds a storage account and nobody notices it's missing a private endpoint. Point-in-time audits catch none of this reliably, because the environment they're checking has already moved on by the time the report gets written.

Azure Policy addresses this by enforcing rules continuously rather than checking them once. Policies can require encryption on new storage accounts, block public network access on resources that shouldn't have it, and flag or automatically remediate configurations that drift from the approved baseline. Microsoft's HIPAA HITRUST blueprint bundles a set of these policies together, mapped to specific HIPAA and HITRUST controls, so a new subscription or resource group can inherit a known-good starting configuration instead of being built from scratch each time.

The distinction that matters here: governance tooling doesn't replace the work covered in the sections above, identity, encryption, network segmentation, logging. It's what keeps that work from quietly falling apart six months after the initial build, which is exactly the window where most of these controls actually fail in practice.