What Azure Actually Covers for HIPAA and What It Leaves to You

"HIPAA compliant cloud" gets treated like a certification a vendor hands you, a badge that transfers automatically the moment you spin up a virtual machine on Azure. It doesn't work that way. The point is well established across compliance guidance: Azure can support regulated healthcare workloads, but whether any given deployment is actually compliant depends entirely on how it's configured, governed, and watched over time. Microsoft signing a Business Associate Agreement covers the infrastructure underneath your workload. It says nothing about the code running on top of it, the access controls guarding your databases, or the audit logs your team may or may not be retaining. Konfirmity's guide puts the average healthcare data breach cost at $10.1 million, the highest of any industry for well over a decade running, and that bill lands on the covered entity, not on Microsoft. Compliance guidance is consistent on this point: you can hand off the servers, but you can't hand off the liability. What follows maps exactly where Microsoft's job ends and where yours begins, one control at a time.

How the BAA is structured and what it commits Microsoft to

There's no separate contract to chase down here, no sales call required to unlock HIPAA coverage. Azure's BAA lives inside the Microsoft Product Terms (what used to be called the Online Services Terms) and the Data Protection Addendum, and it's already baked into the paperwork that every Azure customer accepts. Certain account types carry BAA coverage, including at minimum Enterprise Agreement customers, with BAA terms embedded in the governing agreement. Microsoft Customer Agreement billing accounts are also covered through the Data Protection Addendum.

What does Microsoft actually promise under that agreement? Core commitments include safeguarding data, notifying you if a breach happens, and handling data access in ways consistent with HIPAA and HITECH. That's the whole list. It says nothing about how your application handles PHI once it lands on Azure's infrastructure.

For proof of all this, the Service Trust Portal holds the independently audited compliance documentation, the paperwork auditors will actually want to see. But treat the BAA as step one, not the finish line. Signing it puts you in a position to build compliant systems. It doesn't mean you have one yet.

What Microsoft handles: the physical and infrastructure layer

Microsoft's documented scope covers physical data centers, networking hardware, the hypervisor layer, host infrastructure, the segmentation that keeps one tenant's traffic from bleeding into another's, and the disposal process when old hardware gets retired, none of which you'll ever touch directly. The BAA extends to named services: Azure Virtual Machines, Azure Storage, Azure SQL Database, Azure App Service, Azure Kubernetes Service, Azure Functions, Azure Logic Apps, and Azure Key Vault.

On top of that infrastructure, Azure ships compliance tooling: Azure Policy comes with a built-in HIPAA/HITRUST initiative for ongoing monitoring, Azure Monitor and Microsoft Defender for Cloud handle audit logging, and the whole platform lines up against NIST CSF, ISO/IEC 27001, SOC 1/2/3, and HITRUST CSF. Microsoft and a healthcare security assurance framework have even published a joint shared-responsibility matrix laying out who owns what for framework-aligned, Azure-hosted solutions.

Azure hands you the tools, but nobody flips the switches for you. Enabling Defender for Cloud, configuring Azure Policy, extending log retention past the default, that's on the customer. Infrastructure and configuration are two different jobs, and Microsoft only does the first one.

Where the handoff happens: the six control domains the customer owns

Six domains sit entirely on the customer's side of the line. Get familiar with each one, because auditors will ask about all six.

Identity and access management requires that Microsoft Entra ID (the product formerly called Azure AD) have MFA and Conditional Access turned on, not just available. Role-based access control has to follow least-privilege from day one, and Privileged Identity Management should handle elevation on a just-in-time basis, with approval and a documented reason attached. Access reviews need to happen on a schedule, and sensitive roles need session timeouts enforced, not suggested.

Encryption configuration: Azure encrypts data in transit and at rest by default, disks, storage accounts, databases, all of it. But default encryption isn't the same as compliant key management. Someone has to choose between Azure Key Vault and Managed HSM for customer-managed keys, turn on Transparent Data Encryption and Always Encrypted at the database level, and log every instance of key usage so there's a record to show an auditor. The reference standards here are AES-256 at rest and TLS 1.2 or higher in transit, and both need active configuration, not passive trust in the defaults.

Audit logging and retention require action, since Azure Monitor and Defender for Cloud don't turn themselves on. And HIPAA's documentation retention requirements extend well beyond whatever retention window a service ships with out of the box.

Application and workload security is only partly addressed by the BAA, which covers infrastructure. It does not cover the code your developers write. PHI-access logging inside the application, session tokens that actually expire, encryption verification at the API layer, all of that has to be built by hand into the application itself.

Administrative and policy obligations include a HIPAA Security Risk Analysis, which isn't optional, and neither is a risk management plan mapped against the Security Rule's actual requirements. Beyond that, organizations need written policy covering access, change control, incident response, vendor management, and data lifecycle, all filed away and ready when an auditor asks for it.

In the breach notification chain, if Microsoft spots an incident touching your PHI, Microsoft tells you. What happens after that, notifying the affected patients, notifying HHS, is entirely the covered entity's job. The reputational fallout lands on the healthcare organization, never on Azure.

The not-covered services trap: BAA eligibility is not universal across Azure

Not every Azure product falls under the BAA, and treating the whole platform as uniformly covered is how PHI ends up somewhere it shouldn't. Microsoft designates specific services as HIPAA-eligible, and eligibility sometimes gets decided at the feature level, not just the product level. That means checking before storing PHI anywhere, every time, not assuming coverage carries over from one service to the next.

Preview features fall outside the BAA by default. So do most third-party solutions sold through Azure Marketplace, unless there's a separate agreement in place confirming otherwise.

Azure OpenAI is a good example of how granular this gets. It's eligible for HIPAA workloads, but only for production-grade, text-based interactions. Preview features don't qualify, and neither do non-text models like an image-generation model or anything running voice input, not unless Microsoft explicitly says so. Microsoft doesn't use customer data to retrain its OpenAI models, which helps, but there's a 30-day abuse-monitoring window that applies by default and needs to factor into any breach-notification planning for PHI workloads. Organizations handling PHI workloads should evaluate whether the default monitoring window fits their breach-notification obligations and pursue any available exception through Microsoft directly.

Computer Vision and the Face API are not HIPAA-eligible out of the box, full stop, and shouldn't touch PHI without explicit approval first. Marketplace apps split the same way: some carry HIPAA eligibility, some don't, and each one needs its own evaluation and its own BAA if PHI is going to pass through it. Vague contract language covering "security" in the abstract doesn't cut it; encryption standards, MFA requirements, testing cadence, and breach notification timelines all need to be spelled out in writing.

Migration to Azure Health Data Services FHIR must be completed before Azure API for FHIR retires on September 30, 2026. New deployments have already been blocked since April 1, 2025. Anyone still running on that service needs to migrate to Azure Health Data Services FHIR before the retirement date hits.

Where breaches happen on Azure: misconfiguration, not platform failure

IBM's 2023 Cost of a Data Breach Report found that 82% of healthcare breaches now involve data sitting in the cloud, which means the environment most teams assume is the safe one is where the failures are concentrated. Citing Gartner's analysis, Konfirmity's 2026 guide states that 99% of cloud security failures trace back to the customer, and misconfiguration, not some flaw in the underlying platform, drives almost all of it.

The most common mistake: Azure Blob Storage left publicly exposed. Default settings have historically been more permissive than most administrators realize, and locking that down takes a deliberate configuration step, not a checkbox someone assumed was already checked. Overpermissioned IAM roles run a close second. Least privilege doesn't happen on its own in a cloud environment; someone has to engineer it in, on purpose, and keep checking that it hasn't drifted.

Audit findings illustrate how fast these gaps appear in practice: within the first week of a single audit, three problems turned up. Audit log retention was set to 90 days, nowhere close to HIPAA's six-year requirement. The SIEM pipeline had never been extended to archive blob storage with immutable retention. A pattern that keeps repeating across organizations: the infrastructure passes its compliance check while the application layer has no PHI-access logging at all, shares admin credentials across the whole engineering team, lets session tokens run indefinitely, and moves patient data through API endpoints with no encryption verification in place.

Migrations open up their own risk window. Teams move data first and plan to lock down encryption and access controls right after, and that gap, even a short one, counts as exposure if PHI sits there unprotected. Defender for Cloud will flag most of the misconfigurations commonly tied to ransomware campaigns, but only if someone turned it on before the PHI showed up, not after.

The Azure tooling customers must configure and actively operate

A handful of tools carry most of the operational weight, and none of them work unless someone actively runs them.

Defender for Cloud comes with a regulatory compliance dashboard that lines up Azure's security recommendations against whatever controls are enabled, HIPAA included, once added, and it flags violations automatically wherever automated assessment is possible. It has to be switched on ahead of time, not after something goes wrong. Azure Policy's built-in HIPAA/HITRUST initiative runs continuous checks against the environment, which cuts down significantly on the manual labor of chasing compliance by hand.

Azure Monitor and Log Analytics need configuration to capture PHI-access audit trails, and the default retention window has to be stretched out to meet HIPAA's six-year rule. Microsoft Entra ID brings enterprise-grade identity to the table, Conditional Access, MFA, Privileged Identity Management, but licensing the product isn't the same as configuring it. Azure Key Vault handles customer-managed key storage for encryption at rest, and key usage logging is what proves to an auditor that the whole setup actually works as intended.

Azure SQL Managed Instance and Azure Database for PostgreSQL Flexible Server both encrypt at rest by default using Azure-managed keys, and customer-managed keys through Key Vault are available as an option, not a requirement, meaning someone still has to pick an approach and maintain it. One 2026 industry guide finds that many organizations run their security risk assessments against on-premises systems only and skip the cloud footprint entirely, missing exactly the environment where most of today's exposure actually sits.

The proposed 2026 HIPAA Security Rule changes and their impact on Azure architecture decisions

The proposed update to the HIPAA Security Rule hasn't been finalized. A federal budget office now has its sights on July 2027 for final action, after the original May 2026 target came and went unmet, and the specific requirements could still shift, slip further, or get pulled.

Even so, plenty of organizations are already building toward the proposed standard as though it were settled, and given how enforcement has been trending, that's a reasonable bet. The direction is clear enough even if the paperwork isn't finished. Several proposed changes carry direct weight for how Azure workloads get architected: encryption of ePHI at rest and in transit would stop being "addressable" (meaning optional, effectively) and become mandatory, with AES-256 at rest and TLS 1.2 or higher in transit as the reference points. MFA would be required across every system touching ePHI. Vulnerability scans would need to run at least every six months, penetration tests at least once a year, and organizations would need the ability to restore critical systems within 72 hours of an incident.

Enforcement isn't waiting for the rule to finalize before it gets more expensive. On January 28, 2026, HHS applied its latest inflation adjustment to HIPAA penalties, pushing the Tier 4 annual cap to $2,190,294 per identical provision. In 2025 alone, 642 healthcare data breaches were reported to OCR, affecting at least 57 million people, and the average breach now runs $7.42 million, making healthcare the most expensive industry to get breached in for fourteen years running.

For anyone architecting on Azure today, leaning on "addressable" encryption flexibility is building toward a standard that's already on its way out. Architecting to the proposed rule now, rather than after it's finalized, is the difference between one build and two.