HIPAA Series: “We'll Get to It" Just Expired - Encryption is here
For 22 years, the HIPAA Security Rule gave covered entities a documented exit from encryption. Encryption was listed as an "addressable" safeguard, meaning an entity could assess its environment, determine that encryption wasn't "reasonable and appropriate" given its specific circumstances, implement an equivalent alternative, and document that decision. The documentation requirement was loose enough that many organizations never bothered with it at all.
But lets be real. The result was fairly predictable. Unencrypted laptops walked out of medical offices and got stolen. Unencrypted backup drives got lost. Emails with lab results and clinical notes traveled across the internet in plaintext. Patient data moved between systems without protection because nobody was required to protect it…as long as someone had documented why.
The proposed 2026 Security Rule update ends that. Encryption is now required. Not "required unless you document a reason not to," not "required with a reasonable alternative exception" = required. The final rule's timing is still uncertain as of June 2026, OCR's May 2026 target appears to have slipped, but the proposed standard is already shaping enforcement expectations, and the compliance window runs 180 days from whenever the final rule publishes.
If your entity hasn't started a formal encryption assessment, the time to start is now regardless of when the final text arrives.
What the encryption standard is
The proposed rule specifies NIST-approved encryption standards. For data at rest, the standard is AES-256 (Advanced Encryption Standard with a 256-bit key). For data in transit, the minimum standard is TLS 1.2 (Transport Layer Security), with TLS 1.3 preferred. These are the current industry baseline for any organization handling sensitive data and not novel requirements outside of the Security Rule.
The rule covers all ePHI, wherever it exists: structured data in EHR databases, unstructured data in documents and attachments, data on devices, data in cloud storage, data in transit between systems, and data in backup and disaster recovery environments. If it's ePHI, it needs to be encrypted.
There are narrow technical exceptions: situations where decryption is necessary for active use, or where the encryption mechanism itself would prevent authorized access to ePHI. But, these are genuine edge cases, not the broad category that "addressable" created.
The breach connection
Understanding why this rule change matters operationally requires understanding how HIPAA breach notification works.
Under the existing HIPAA Breach Notification Rule, established by the HITECH Act in 2009 and codified through the 2013 Omnibus Rule, a breach involving unencrypted ePHI is presumed to be reportable unless the covered entity can demonstrate the data was unusable, unreadable, or indecipherable to unauthorized persons. Encryption that meets NIST standards satisfies that standard. An encrypted device that is stolen or lost generally doesn't trigger the notification requirement because the data is unreadable without the decryption key.
That safe harbor has been available since 2009. Organizations that fully encrypt ePHI on devices and in transit can avoid the breach notification burden, the OCR investigation, and the reputational damage that follows a reportable breach when the underlying incident is a lost or stolen device.
In 2024, 725 large breaches were reported to OCR: a record year. The average cost of a healthcare data breach in 2024 was $9.77 million, according to IBM's 2024 Cost of a Data Breach Report, as I’ve stated earlier in this HIPAA Series, the highest of any industry for the 14th consecutive year. A significant portion of those breaches involved unencrypted data on devices or in transit. Under full compliance with the proposed rule's encryption standard, a meaningful number of them would not have been reportable.
The rule is more expensive to implement than I think HHS realizes, but the reality is that non-compliance is likely even more expensive. Why gamble on that risk?
Where unencrypted ePHI actually lives
Most entities assume encryption gaps are in obvious places, but they usually aren't. Here's where the unencrypted data is:
Workstations and laptops. Full-disk encryption on Windows devices (BitLocker) and Macs (FileVault) is built into the operating system and costs nothing beyond configuration. It's not always turned on. A workstation with a cached EHR session, downloaded patient reports, or saved diagnostic images that leaves the office for any reason, for repair, disposal, or loss, is an unencrypted breach waiting to happen. Auditing whether BitLocker or FileVault is enabled and properly configured across every enterprise device takes an afternoon. Not doing it costs $9.77 million on average.
Portable media. USB drives and external hard drives are not a relic. Providers copy files. Staff save records for patients. Someone downloads a report to review at home. If that media isn't encrypted, a lost USB drive is a reportable breach under the current rule and a compliance violation under the new one. Encrypted USB drives are widely available and inexpensive. Whether the company has a policy requiring them is a different question.
Email in transit and at rest. Standard email - SMTP without TLS - transmits in plaintext. A clinical note sent to a referring physician, a lab result forwarded to a patient, a billing record emailed to a clearinghouse: all are potential violations if the email system doesn't enforce TLS in transit. Most modern email platforms support TLS, but whether it's enforced is a configuration question, not a given. Beyond transit, email archives stored on servers or in cloud platforms also need to meet the at-rest encryption standard.
Fax-to-email and secure messaging gaps. Many entities use fax-to-email services that convert incoming faxes to email attachments for lab results, referrals, or clinical notes. If those converted files land in an unencrypted email inbox or are stored in an unencrypted folder, the content is unprotected regardless of how it arrived. The incoming channel may have been compliant; the destination isn't.
Backup systems. Backup environments often receive less scrutiny than production systems, and encryption is frequently an afterthought in backup configuration. A complete backup of your patient records database, stored unencrypted on an offsite server or a cloud backup service that doesn't encrypt at rest, is a first-order compliance gap. The risk isn't abstract since backup systems are specifically targeted in ransomware attacks precisely because they represent the last line of recovery. If the backup is also unencrypted, the attacker controls both the ransom leverage and the data.
Legacy and local systems. Enterprise management software running on local servers, systems that are end-of-life, out of vendor support, or running on operating systems that predate modern encryption standards, may not support AES-256 or TLS 1.2. If the software can't be updated to meet the standard, migration isn't optional. The proposed rule includes narrow exceptions for legacy medical devices under documented migration plans; it doesn't extend that exception to general-purpose business software.
The patch cadence problem
The proposed rule adds a requirement that doesn't show up in most encryption discussions but is directly related to how encryption and security controls stay effective. We need to address that here: patch management cadence.
The proposed rule requires critical vulnerabilities to be patched within 15 days of patch availability. High-severity vulnerabilities within 30 days. This applies to all systems that access ePHI.
For a company running current, vendor-supported software on modern operating systems, this is achievable with a defined patch management policy. For an organization running legacy systems on extended support or no support, which is common in smaller medical groups as well as the big healthcare systems, this requirement may be functionally impossible without system replacement. Software that can't be patched to current encryption standards and can't be patched within the required timeframe is a dual compliance gap.
The proposed rule's exception for legacy systems is narrow and time-limited. It requires a documented migration plan with specific milestones, not an indefinite waiver.
What to do
Start with an honest inventory. Where does ePHI exist in your environment? Which locations have encryption verified and documented? Work through the categories above: workstations, portable media, email, backups, fax-to-email services, and any legacy systems, and assess each one.
For most entities, the gaps are in configuration rather than capability. BitLocker and FileVault are available. Email TLS can be enforced. Cloud backup providers offer encryption at rest; whether it's enabled is a settings question. The gap is usually that nobody has verified it or documented the verification.
Where gaps exist, remediation is mostly technical: enable the feature, verify it's working, document the steps. The harder cases are legacy systems that don't support current standards and portable media policies that don't exist or aren't enforced. Those require decisions, not just configuration.
Document everything. A written record of your encryption assessment: what you found, what you did, and when, is all part of the risk analysis requirement and what OCR will want to see in any investigation.
The compliance clock starts when the final rule publishes - approximately 180 days to the deadline from that date. Encryption is one of the faster compliance projects when the gaps are in configuration. Start the inventory now so you know what you're actually dealing with.
Next discussion: risk analysis. OCR has cited inadequate risk analysis in more enforcement actions than any other Security Rule requirement and recently expanded enforcement from risk analysis to risk management.
Questions about encryption gaps in your environment? Schedule a consult @ https://jharrisadvisory.com/contact.
For the full picture — proposed changes, readiness plan, and toolkit — see our HIPAA Security Rule NPRM guide