Why the 2026 Update Is Structurally Different
The original HIPAA Security Rule, finalized in 2003, organized technical safeguard requirements into required and addressable categories. Required safeguards were mandatory; addressable safeguards could be implemented differently if the covered entity documented why the standard implementation was not reasonable and appropriate for their environment. Encryption of data at rest and in transit was addressable, meaning organizations could satisfy the requirement through alternative measures.
The proposed 2026 update, published by HHS in the Federal Register, fundamentally changes this framework by eliminating the addressable category for a significant set of technical controls. Under the proposed rule, encryption of electronic protected health information at rest and in transit becomes a required implementation specification, not addressable. This means covered entities and business associates can no longer document an alternative approach — they must encrypt, or be out of compliance.
The scope of this change is substantial. Many healthcare organizations have operated for years under an addressable encryption framework that allowed them to prioritize network security controls, physical access controls, and monitoring as compensating measures. Those compensating measure frameworks are no longer sufficient under the proposed rule for the designated required specifications.
Mandatory Encryption: What the Rule Requires
The proposed rule specifies encryption requirements that apply to ePHI both at rest and in transit. For data at rest, this includes ePHI stored on servers, workstations, laptops, portable media, backup systems, and cloud storage. The rule references NIST standards for acceptable encryption algorithms, currently AES-256 for symmetric encryption of data at rest and TLS 1.2 or 1.3 for data in transit. Organizations using deprecated encryption standards such as TLS 1.0 or 1.1 for any system handling ePHI must remediate regardless of compensating controls.
The proposed rule also addresses encryption key management as a distinct requirement. Organizations must maintain documented key management procedures that include key rotation schedules, separation of duties for key access, and procedures for key recovery and revocation. Key management failures have been responsible for several high-profile healthcare data breaches in which encrypted data became accessible due to inadequate key controls rather than encryption algorithm weaknesses.
Healthcare organizations operating in cloud environments should note that the rule's encryption requirements apply to the organization's implementation choices, not merely the cloud provider's capabilities. Storing ePHI in a cloud environment that supports encryption does not satisfy the rule if the organization has not configured encryption for the relevant storage resources. Cloud configuration management and security posture assessment must be part of the compliance program.
Network Segmentation and Additional Technical Controls
Beyond encryption, the proposed rule introduces network segmentation as a required safeguard for covered entities above a defined threshold of ePHI handling. Network segmentation requirements mandate that systems handling ePHI be isolated from general-purpose network segments using technical controls such as firewalls, VLANs, or software-defined networking policies that limit lateral movement within the organization's network.
Multi-factor authentication is also elevated to a required specification for all access to systems containing ePHI. Organizations that have deployed MFA selectively — for remote access or administrative accounts only — must extend MFA coverage to all workforce members accessing ePHI systems. This includes clinical applications accessed from within the facility network, not just remote access scenarios.
The proposed rule also requires organizations to conduct and document technical vulnerability scans on a defined frequency and to remediate identified critical and high vulnerabilities within specified timeframes. This moves vulnerability management from a general security best practice to a specific compliance obligation with documentation requirements that will be audited in the context of a breach investigation or compliance review.
Implementation Timeline and Organizational Response
The proposed rule entered a comment period and the final rule timeline should be verified against current HHS guidance, as effective dates are subject to revision. However, the direction of travel is clear: the HIPAA technical safeguard framework is being updated to reflect the threat landscape and security standards of 2026, not 2003. Organizations that begin compliance preparation during the proposed rule period will be substantially better positioned than those that wait for the final rule before acting.
A practical organizational response begins with a current-state assessment against the proposed required specifications. Which systems handling ePHI are not yet encrypted at rest? Which data flows transmit ePHI without TLS 1.2 or higher? Which workforce populations access ePHI systems without MFA? The answers to these questions define the remediation roadmap.
Organizations that have already invested in FedRAMP Authorized cloud infrastructure for systems handling ePHI are well-positioned for the encryption and key management requirements, as FedRAMP Authorized authorization packages require encryption controls that align closely with the proposed HIPAA specifications. The remaining gap for most such organizations is in end-to-end encryption verification across all data flows and MFA coverage breadth.