HIPAA Encryption Requirements for Electronic Protected Health Information (ePHI)

Current encryption requirements under the Security Rule

The HIPAA Security Rule addresses encryption in two places:

• 45 CFR § 164.312(a)(2)(iv) — Encryption and decryption (access controls). This addressable specification requires covered entities to implement a mechanism to encrypt and decrypt ePHI as part of access control measures. It applies to ePHI at rest — data stored on hard drives, servers, databases, backup media, and portable devices.
• 45 CFR § 164.312(e)(2)(ii) — Encryption (transmission security). This addressable specification requires a mechanism to encrypt ePHI whenever it is transmitted over electronic networks. It applies to ePHI in transit — email, file transfers, data sent between systems, and communications with business associates.

Both specifications are classified as "addressable." Under the Security Rule's framework, this means you must assess the specification, and then either implement it, implement an equivalent alternative, or document why neither is reasonable and appropriate.

What "addressable" actually means

The addressable designation is the most misunderstood concept in the HIPAA Security Rule. It does not mean optional. It does not mean you can skip it if it is inconvenient or expensive. The Security Rule at 45 CFR § 164.306(d)(3) defines the process:

1. Assess whether the implementation specification is a reasonable and appropriate safeguard for your environment, considering your risk analysis, your risk mitigation strategy, your current security measures, and cost.
2. If it is reasonable and appropriate, implement it.
3. If it is not reasonable and appropriate, document why and implement an equivalent alternative measure that achieves the same security objective.
4. If neither the specification nor an alternative is reasonable and appropriate, document why.

The documentation requirement is critical. If you cannot produce a written determination explaining your decision — with reference to your specific risk analysis and environment — you have not met the addressable standard. You have simply skipped it.

How OCR actually treats unencrypted ePHI

In enforcement practice, the addressable designation has provided little protection for organizations that chose not to encrypt. OCR has consistently taken the position that encryption is reasonable and appropriate for virtually all covered entities, given the wide availability of encryption technology and its relatively low cost.

The pattern is especially clear with portable devices. When a laptop, USB drive, or smartphone containing unencrypted ePHI is lost or stolen, OCR's investigation almost invariably finds:

• The device contained ePHI that should have been encrypted.
• The covered entity either never assessed encryption as an addressable specification or assessed it and chose not to implement without adequate documentation.
• The failure to encrypt constitutes willful neglect — because encryption is widely available, inexpensive, and the risks of unencrypted portable ePHI have been well-publicized through years of OCR guidance and enforcement.

Willful neglect carries mandatory penalties under HITECH, with a minimum of $10,000 per violation if corrected within 30 days and $50,000 per violation if not corrected. Multiple OCR settlements involving unencrypted devices have resulted in penalties exceeding $1 million.

The encryption safe harbor

The Breach Notification Rule at 45 CFR § 164.402 defines "unsecured PHI" as PHI that is not rendered unusable, unreadable, or indecipherable to unauthorized persons. HHS guidance specifies that encryption using NIST-approved algorithms (AES-128, AES-256, or equivalent) satisfies this standard.

If ePHI is encrypted to this standard and the encryption key is not compromised along with the data, a loss or theft of the device is not a reportable breach. This safe harbor is enormously valuable:

• No individual notification required.
• No HHS breach report required.
• No media notification (for breaches over 500 individuals).
• No OCR investigation triggered by the breach report — because there is no breach report.

The cost of implementing full-disk encryption on every laptop and workstation is trivial compared to the cost of a single breach investigation. This is why OCR has little patience for organizations that claim encryption is not "reasonable and appropriate."

The proposed 2025 update: encryption becomes mandatory

The proposed HIPAA Security Rule update published January 6, 2025 would eliminate the addressable/required distinction for all implementation specifications — including encryption. Under the proposed rule:

• Encryption of ePHI at rest would be required. No assessment of alternatives. No documentation of why you chose not to. Required.
• Encryption of ePHI in transit would be required. Same standard.
• The proposed rule specifies NIST-approved encryption standards as the baseline.

As of April 2026, the proposed rule is on OCR's finalization agenda. Whether it is finalized as proposed or modified, the direction is unambiguous: HHS wants encryption to be mandatory, not addressable.

Practical implementation: what to encrypt and how

If you are not already encrypting ePHI comprehensively, here is what needs to be covered:

Data at rest

• Workstations and laptops. Enable full-disk encryption. BitLocker (Windows) and FileVault (macOS) are built into the operating system at no additional cost. Both use AES-256.
• Servers and databases. Enable encryption at the storage layer or database level. Most modern database systems and cloud platforms (AWS, Azure, GCP) offer encryption at rest as a configuration option.
• Portable media. USB drives, external hard drives, backup tapes. Use hardware-encrypted devices or software encryption for any portable media that may contain ePHI. Better yet, eliminate portable media from your ePHI workflows entirely.
• Mobile devices. Modern iOS and Android devices encrypt data at rest by default when a passcode is set. Verify this is enabled on any device that accesses ePHI.
• Backups. Encrypted backups are essential. An unencrypted backup tape in a storage facility is an unencrypted copy of your ePHI.

Data in transit

• Email. If you send or receive ePHI via email, use TLS encryption at minimum. For sensitive communications, use an encrypted email solution or a secure patient portal.
• Web applications. All web-based systems that handle ePHI — EHR portals, patient-facing applications, telehealth platforms — must use HTTPS/TLS. There is no legitimate reason for any healthcare web application to operate over unencrypted HTTP.
• File transfers. Use SFTP, SCP, or encrypted API connections for data transfers between systems. Unencrypted FTP should not exist in a healthcare environment.
• VPN for remote access. If staff access ePHI remotely, use an encrypted VPN connection. This applies to work-from- home arrangements, remote office locations, and any access from outside your network perimeter.

What to do now

Whether the proposed rule is finalized tomorrow or in a year, the practical recommendation is the same:

1. Audit your encryption status. Identify every location where ePHI exists — devices, servers, cloud services, email, backups, portable media — and verify whether it is encrypted.
2. Close the gaps. Enable full-disk encryption on every device. Enable TLS on every transmission path. Encrypt backups. Eliminate unencrypted portable media.
3. Document your decisions. Under current rules, document your assessment of encryption as an addressable specification. Under proposed rules, document your implementation. Either way, document.
4. Verify your encryption meets NIST standards. The safe harbor requires NIST-approved algorithms. AES-128 or AES-256 for data at rest, TLS 1.2 or higher for data in transit.

How BlackSheep helps

BlackSheep's HIPAA compliance platform includes encryption verification as part of the technical safeguard assessment. It identifies where ePHI lives in your environment, verifies encryption status, flags gaps, and tracks remediation — so you know exactly where you stand, both under current rules and the proposed update.