- Citation
45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii)- Standard
- Access control, 164.312(a)(1), and transmission security, 164.312(e)(1)
- Safeguard
- Technical safeguards
- Type
- Addressable (both specifications)
What the rule says
Implement a mechanism to encrypt and decrypt electronic protected health information. [164.312(a)(2)(iv)] Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. [164.312(e)(2)(ii)]45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii), as currently in force
In plain English: Encrypt patient information where it's stored and when it's sent, unless you can document a good reason not to in a specific case. If you do, a lost or stolen device or an intercepted message isn't a reportable breach.
What it means in practice
- At rest: full-disk encryption on every laptop, workstation, phone and portable drive; encrypted databases and storage in the cloud; encrypted backups.
- In transit: TLS for web and email where the other side supports it, VPN or equivalent for remote access, encrypted channels for file transfer.
- Keys managed so that losing the device doesn't mean losing the key with it.
- The breach safe harbor: PHI encrypted consistent with HHS's guidance (which points to NIST standards) isn't unsecured PHI, so its loss doesn't trigger notification.
- Addressable means you may document an alternative in a specific situation, not that you may skip it generally. HHS said in the 2025 proposal that addressable has never meant optional.
The lost laptop that wasn't a breach. That's the short version of this requirement.Your engineer
What OCR looks for
If an investigation touches this requirement, the data request will ask for some or all of the following.
- Device inventory with encryption status per device, from an agent or management tool.
- Cloud storage and database encryption settings.
- Email and transport security configuration.
- Key management documentation.
- Any documented decision not to encrypt something, with the alternative control.
Where entities get caught
The large cases of the 2010s were unencrypted laptops and drives: a cancer center was assessed a $4.3 million penalty in 2018 over an unencrypted laptop and two USB drives (the penalty was vacated on appeal in 2021, but the breach reports stood), and a health plan's $1.2 million settlement followed copiers returned with their hard drives intact. Since then, encryption has become the control that keeps most device losses off the breach portal entirely.
In 2026, OCR's settlement with a health system cited the risk analysis after ransomware; encryption at rest doesn't stop ransomware, but encryption in transit and of backups shapes what the attacker can take and what you can restore.
How to meet it at a small organization
Turn on BitLocker and FileVault everywhere, now; both are free. Require a passcode and encryption on any phone that gets work email. Use the business email platform's transport encryption and a portal or encryption add-on for PHI going to other organizations. Encrypt backups. Record all of it in the device inventory.
Under the proposed Security Rule update
The proposal would require encryption of ePHI at rest and in transit, with limited exceptions, removing the addressable designation from both specifications. The update was proposed in January 2025 and remains a proposal as of October 2026; see what's changing.
This page explains a federal regulation in plain language. It isn't legal advice, and AccuSights doesn't certify compliance; no one can. For every standard and specification, see the Security Rule, clause by clause.
With AccuSights: The endpoint agent verifies disk encryption on every device and flags the one that isn't, cloud connectors confirm storage and transport settings, and the evidence sits against the two citations in your documentation pack.