HIPAA Encryption Requirements for ePHI

The two encryption specifications

The Security Rule does not have one encryption rule. It has two implementation specifications that both sit under "addressable," and they cover different surface area.

• Encryption and decryption for data at rest: 45 CFR 164.312(a)(2)(iv)(2)(iv)) — implement a mechanism to encrypt and decrypt ePHI.
• Transmission encryption for data in motion: 45 CFR 164.312(e)(2)(ii)(2)(ii)) — implement a mechanism to encrypt ePHI whenever deemed appropriate.

Both sit under standards that are required (access control and transmission security). The encryption specifications themselves are addressable.

What "addressable" actually means

Addressable does not mean optional. The Security Rule at 164.306(d)(3)(3)) sets the rule: for each addressable specification, the covered entity must:

1. Implement the specification if reasonable and appropriate, or
2. If not reasonable and appropriate, implement an equivalent alternative measure, or
3. If not reasonable and appropriate and no alternative is needed, document that decision.

Decision (1), (2), or (3) must be in writing in the risk analysis. OCR's Guidance on Risk Analysis and the Audit Protocol both demand the documentation. The audit protocol literally lists "documentation of decision" as an audit element.

In practice, for most ePHI at most providers, the reasonable and appropriate decision is to encrypt. The cost is low (built into modern operating systems and cloud platforms) and the upside is large (see safe harbor below).

The Breach Notification Rule safe harbor

This is where encryption pays for itself. 45 CFR 164.402 defines breach as the acquisition, access, use, or disclosure of PHI in a manner not permitted under the Privacy Rule which compromises the security or privacy of the PHI. ePHI that is rendered "unusable, unreadable, or indecipherable to unauthorized persons" through encryption that meets HHS guidance is not "unsecured PHI" under 164.402, and therefore disclosure of that encrypted ePHI does not trigger Breach Notification Rule obligations.

The technical specification HHS points to is in the Guidance to Render Unsecured PHI Unusable, Unreadable, or Indecipherable. The guidance references NIST publications:

• Data at rest: encryption consistent with NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices.
• Data in motion: encryption consistent with NIST SP 800-52 (TLS), SP 800-77 (IPsec), or SP 800-113 (SSL VPN), as applicable.

If a laptop is lost, encrypted under FIPS-validated AES-256 with the key stored separately, and the practice can demonstrate it was encrypted at the time of loss, the device is generally not subject to the Breach Notification Rule. The same loss with an unencrypted disk almost certainly is.

Where small practices typically need to apply encryption

• Laptops holding ePHI: BitLocker on Windows, FileVault on macOS. Confirm the device-encryption status is documented.
• Mobile phones and tablets used to access the EHR or email containing PHI: enforce device-level encryption and a PIN.
• Removable media (USB drives, external SSDs) used for backups or transferred files.
• Backups: encrypted at the source before they leave the device, with key management separate from the backup storage.
• EHR and practice management cloud platforms: should be encrypted at rest by the vendor; confirm in the BAA and in vendor documentation.
• Email that contains ePHI: encrypted in transit via TLS, with portal-based delivery for sensitive content. OCR's HIPAA FAQ on email is the touchstone.
• VPN connections from staff devices to the practice network.
• TLS on all web-facing patient portals and APIs.
• Database and file-server volumes that hold archived ePHI.

What about "we use the EHR vendor's encryption"

Almost every cloud EHR encrypts data at rest. That covers the data stored on the vendor's servers. It does not cover ePHI that lands on the practice's own devices via screenshots, downloaded PDFs, exports, scanned documents, and email. The practice still needs encryption on its own endpoints and on data leaving the EHR.

Documenting the decision

For each location where ePHI lives, the risk analysis should record:

• Asset and location
• Whether encryption is implemented
• Algorithm and key management approach (e.g., AES-256, BitLocker recovery keys escrowed in tenant)
• For addressable specifications, the decision and reasoning
• Date of last verification

A risk analysis that says "encryption: yes" with no specifics is exactly the kind of finding that has appeared in OCR Resolution Agreements. The specifics matter.

NIST 800-66 r2 on encryption

NIST SP 800-66 r2 (the 2024 revision of the HIPAA Security Rule cybersecurity resource guide) walks through encryption choices at small-provider scale and recommends FIPS 140-3 validated cryptographic modules where feasible. The practice does not need to verify FIPS validation for off-the-shelf operating-system encryption, but the underlying algorithms should be ones HHS has accepted in the guidance.

What encryption does not solve

• Phishing and credential theft (a logged-in attacker has the same access an authorized user has).
• Insider misuse.
• Endpoint malware that exfiltrates decrypted data.
• Misconfiguration of cloud storage.
• BAA gaps.

Encryption is a single control inside a larger program. It is the highest-leverage single control because of the Breach Notification Rule safe harbor, but it is not a substitute for the rest of the program.

Restraint about claims

Encryption that meets HHS guidance gives a practice the breach-notification safe harbor. It does not certify the practice or guarantee an audit outcome. The Security Rule remains a process governing the totality of safeguards.

How D3rx fits

D3rx SRA Binder Studio walks each encryption decision in plain English, asks for the specifics (algorithm, location, verification date), records the addressable-specification decision, and assembles the documentation linked back to the HHS guidance and the NIST sources. It is a point-in-time administrative documentation aid; the practice remains responsible for actually deploying the encryption.

Next steps

See where your practice currently stands with the free 5-question readiness check, or review the full workflow and pricing on the main SRA page.