HIPAA Technical Safeguards for Cloud-Hosted Applications

The January 2025 HHS Notice of Proposed Rulemaking marks the most consequential overhaul of healthcare data security requirements in over two decades, and its effect on cloud-hosted ePHI is already visible in 2026 audits. The change that matters most for engineers: the old split between "addressable" and "required" specifications, the one that let an organization skip a control as long as it documented why, has been eliminated. Under the proposed rule, every technical safeguard listed in §164.312 becomes mandatory. MFA shows this shift clearly: a control that used to be effectively optional is now proposed as an explicit requirement for any healthcare entity touching ePHI, though the rule itself hasn't been finalized yet. Encryption follows the same path. AES-256 at rest and TLS 1.2 or higher in transit move from best practice to mandate under the 2026 Security Rule update, with a compliance deadline of January 1, 2027, specifically attached to the encryption requirement. Teams not already building toward that date are behind schedule.

Anyone still mapping their controls to the 2008 version of NIST's implementation guidance is working from an outdated baseline. NIST SP 800-66r2 finalized in February 2024 and now serves as the technical reference regulators expect organizations to use.

HIPAA-eligible" cloud infrastructure and a signed BAA versus a compliant deployment

Most cloud HIPAA failures trace back to a misunderstanding of the shared responsibility model. A cloud provider secures the physical infrastructure underneath a deployment, but configuration, access controls, encryption settings, and the choice of which specific services touch ePHI belong entirely to the engineering team running the workload.

A BAA signed once and never revisited now creates its own compliance gap. The updated rule adds an annual BAA verification requirement, confirming the cloud provider still maintains the controls it promised the year before. Verification has to happen on a regular schedule after signing.

Signing a BAA with a major cloud provider doesn't cover every service that provider offers. AWS's own HIPAA compliance documentation states that PHI should only move through services explicitly named as eligible under the BAA. A storage bucket or messaging queue that falls outside that eligible list breaks compliance even while the BAA sits signed and active. Healthcare cloud audits repeatedly find the same failure patterns: misconfigured storage and open security groups, where a single misconfigured S3 bucket turns a HIPAA-eligible environment into a violation; IAM permissions scoped far wider than the minimum-necessary standard allows; and Security Risk Analyses that cover on-premises systems in detail but miss the cloud footprint entirely. A Security Risk Analysis has to encompass every system where ePHI resides, cloud included, weighing risks specific to that environment such as data residency, multi-tenancy, API security, third-party integrations, and disaster recovery capability. An assessment that stops at the data center door doesn't satisfy the requirement, no matter how thorough it is within that boundary.

Encryption requirements: what AES-256 at rest and TLS 1.2-in-transit mean for cloud architecture

Encryption is the non-negotiable baseline for a HIPAA-compliant cloud architecture, and the 2026 rule specifies both the requirement and the architectural layers where it has to apply. For data in transit, TLS 1.2 is the floor and TLS 1.3 is the standard worth building toward now. That requirement doesn't stop at the application layer. It extends to database connections, access to the cloud management console itself, and internal service-to-service traffic moving within the VPC wherever ePHI passes through it. A team that encrypts its public-facing API traffic but leaves internal microservice calls in plaintext has satisfied the letter of encryption in transit for exactly one layer out of several the rule covers.

Platform choice affects how much of this architecture an engineering team has to build versus configure. Neither AWS nor Azure offers a direct equivalent to that specific control, a gap worth weighing when deciding where an encryption-sensitive workload should run.

Access controls under the 2026 rule: IAM scoping, RBAC, MFA requirements, and access revocation timelines

Access control moves from configuration recommendation to mandatory enforcement point under the 2026 rule, and it applies at every layer: application, database, infrastructure, and the cloud management console itself. This is the largest set of changes in the update, and it's where audits find the most failures.

MFA requirements have gotten more specific than the rule's original language suggests. The 2025 NPRM proposes eliminating the addressable loophole entirely, making MFA mandatory and explicit for nearly every healthcare entity accessing ePHI, with narrow exceptions carved out for legacy systems and certain FDA-approved devices. That proposal hasn't been finalized as of mid-2026. FIDO2-compliant security keys or biometric authentication are the expected standard going forward. For high-risk actions, exporting a large dataset or accessing records from an unfamiliar location, "step-up" MFA adds a second verification layer without slowing down routine access. Legacy healthcare applications that never built in MFA support don't need a rewrite to comply: access proxies or gateways can add FIDO2-compliant authentication in front of the application without touching its code.

IAM and role-based access control enforce the principle of minimum necessary access at the role level, not through one-off permissions granted to individuals. Every account that touches an ePHI system needs two-factor authentication, and that includes infrastructure service accounts and CI/CD pipeline credentials, not just human logins. Shared credentials disqualify an architecture outright: HIPAA requires unique user identification so every access event traces back to one specific person. Emergency "break-glass" access needs its own documentation, its own logging, and management approval before activation.

The single most disruptive change for smaller engineering teams is the revocation timeline. Under the proposed rule, access must be revoked within one hour of an employee's termination. A one-hour window rules out manual IT ticket workflows as a compliance strategy. The stakes are concrete: 133 million healthcare records were breached in 2023.

Audit logging: what must be captured, how long it must be kept, and how to make logs tamper-resistant

Comprehensive, tamper-resistant audit logging is required for every instance of ePHI access under the 2026 rule, and the rule specifies the minimum data each log entry has to capture. A compliant log entry records who accessed the data, when, from where, and what action they took, whether that's a read, a write, an export, a modification, or an attempted access that failed.

Retention timelines split across two sources. The existing HIPAA Security Rule, at 45 CFR § 164.316(b)(2)(i), sets a six-year minimum retention period that already applies today. The proposed 2026 update adds a separate 12-month minimum specifically for ePHI access audit logs. Logs also have to be exportable in a structured form. A logging system that stores everything correctly but can't hand an auditor a usable export hasn't met the requirement.

Most architectures underbuild tamper resistance. The pattern that satisfies it: write logs to immutable storage, using AWS S3 with WORM (Write Once Read Many) policies or Google Cloud Storage with retention policies and bucket lock, so that no one, including an administrator with full permissions, can modify or delete a log entry once it's written. MFA authentication events are worth logging as their own stream alongside access logs. MFA logs capture timestamps, device information, and second-factor details, and cross-referencing them against access logs satisfies both the Person or Entity Authentication standard and the Audit Controls requirement at once.

Capturing logs correctly isn't the end of the obligation. The updated rule proposes that logs also be actively monitored, not simply stored and left for after-the-fact review, though this procedural requirement hasn't been finalized any more than the others. Each hyperscaler provides native tooling for this layer. AWS pairs CloudTrail for API-level audit logging with AWS Config for continuous monitoring against known-good baselines. Azure offers Azure Monitor and Log Analytics for audit trails, with Azure Active Directory's conditional access policies logging authentication events. GCP provides Cloud Audit Logs for tracking PHI access and VPC Service Controls for logging at the network level.

The shared responsibility boundary between cloud hyperscalers and your team

AWS runs the broadest eligible service catalog of the three, with over 200 HIPAA-eligible services and BAAs issued through the AWS Artifact portal. What AWS doesn't do for you: enabling CloudTrail, configuring S3 bucket encryption and access policies, scoping IAM down to least privilege, and turning on AWS Config rules for ongoing compliance monitoring all remain the customer's job. That combination of breadth and manual configuration makes it best suited for complex, enterprise-scale HIPAA architectures that need the widest service catalog.

Google Cloud's advantage is clearest for healthcare organizations doing heavy analytics or machine learning work. Cloud Healthcare API gives teams a managed service for ingesting, transforming, storing, and exchanging healthcare data in FHIR, HL7v2, and DICOM formats, and BigQuery and Vertex AI are ahead of what AWS and Azure offer for large-scale healthcare analytics and ML workloads. VPC Service Controls create a perimeter around PHI-containing resources that blocks exfiltration even when credentials are compromised, a control neither AWS nor Azure replicates directly, and Identity-Aware Proxy delivers zero-trust access as a managed service rather than something built from scratch. That combination makes it best suited for healthcare organizations with significant AI, ML, or data analytics workloads. Google Cloud:

Whichever platform a team chooses, the boundary stays in the same place: the provider secures the infrastructure underneath, and everything about how ePHI is configured, encrypted, accessed, and logged within that infrastructure belongs to the team running the workload.