HIPAA does not flatly command you to encrypt. It makes encryption an Addressable implementation specification — at rest under 45 CFR 164.312(a)(2)(iv), in transit under 45 CFR 164.312(e)(2)(ii). But Addressable has never meant optional, and treating it that way is the single most expensive misreading in health IT. The accurate version: if encryption is reasonable and appropriate for your environment you must implement it; if it is not, you must document why and implement an equivalent alternative safeguard. For a modern EMR stack, "encryption isn't reasonable for us" is a position almost nobody can defend — and a lost unencrypted laptop is the fastest way to find that out.
Is encryption required by HIPAA?
The direct answer, with citations, because this gets answered badly everywhere:
| Where | Citation | Status under the Security Rule |
|---|---|---|
| Encryption and decryption of stored ePHI | 45 CFR 164.312(a)(2)(iv) | Addressable |
| Encryption of ePHI in transmission | 45 CFR 164.312(e)(2)(ii) | Addressable |
| Transmission security (the standard itself) | 45 CFR 164.312(e)(1) | Standard — must be met |
| Risk analysis | 45 CFR 164.308(a)(1)(ii)(A) | Required |
Read the third row again. The standard — "implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network" — is mandatory. Only the mechanism is Addressable. You do not skip the standard; you get a narrow, documented choice about how you meet it. Over an open network, the honest set of ways to meet it is: encryption.
What Addressable actually means
45 CFR 164.306(d)(3) spells out a three-step test, not a shrug:
- Assess whether the specification is a reasonable and appropriate safeguard in your environment, analyzed against its likely contribution to protecting ePHI.
- Implement it if it is reasonable and appropriate.
- If it is not: document why, and implement an equivalent alternative measure if that is reasonable and appropriate.
The reason encryption pays for itself
Set the Security Rule aside for a moment: the strongest practical argument for encrypting is the Breach Notification Rule. HHS publishes Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals. PHI encrypted in the manner that guidance describes is not "unsecured" PHI — and breach notification obligations attach to unsecured PHI. An encrypted laptop that walks out of the clinic is an incident to investigate. An unencrypted one is potentially a reportable breach, with patient letters and an HHS filing.
The guidance points at NIST publications rather than products:
- Data at rest: processes consistent with NIST SP 800-111 (storage encryption for end user devices).
- Data in motion: processes complying, as appropriate, with NIST SP 800-52 (TLS), SP 800-77 (IPsec VPNs) or SP 800-113 (SSL VPNs), or that are FIPS 140-2 validated.
- Destruction: media cleared, purged or destroyed consistent with NIST SP 800-88. Redaction is explicitly excluded as a means of destruction.
Two consequences most admins miss. First, the guidance says the decryption key must not have been breached, and that keys "should be stored on a device or at a location separate from the data they are used to encrypt or decrypt." A backup drive with the passphrase taped to it is not encrypted in any sense that matters. Second, that guidance dates from 2009 and was last reviewed in 2013; the NIST documents it points to have been revised since. Track the current revision.
Find every place ePHI actually lives
You cannot encrypt what you have not inventoried, and the EMR database — the part everyone remembers — is rarely where the breach starts. Walk the stack:
- The EMR database and application servers, on-prem or cloud.
- Backups and snapshots, including the off-site copy and the tapes in the closet.
- Interface staging — HL7 drop folders, SFTP landing zones, interface-engine queues where messages sit in the clear between hops.
- Reporting extracts — the CSV someone pulled for a quality measure and left on a share.
- Endpoints and removable media — laptops, tablets, the front-desk PC, the provider's home machine, USB drives, imaging discs.
- Email, scanners, MFPs and fax servers, including local drives that quietly retain images.
- Vendor-hosted systems — business associates hold ePHI too, and their posture is your exposure.
Encryption at rest, layer by layer
These layers are complementary, not alternatives. Each defeats a different attack.
| Layer | What it defends against | What it does not |
|---|---|---|
| Full-disk / volume encryption (endpoints and servers) | Physical theft, lost devices, decommissioned drives | Anything at all once the machine is booted and the user is logged in |
| Database-level encryption (transparent data encryption) | Someone walking off with the data files or a raw backup | A compromised application account querying the database legitimately |
| Backup encryption | Tapes, snapshots, and off-site copies in transit or storage | Restores into an unencrypted target |
Priority order for a practice with limited hours: every endpoint that leaves the building, then backups, then servers, then the database. Endpoint and backup encryption close the two failure modes that actually generate breach notifications.
Encryption in transit
- Browser to EMR: TLS at a current version with a valid certificate, HTTP redirected to HTTPS, and weak ciphers and old protocol versions actually disabled — not merely deprecated in a config comment.
- Remote access: VPN or a zero-trust equivalent, with multi-factor authentication. An encrypted tunnel guarded by a reused password is a solved problem for an attacker.
- Interfaces: the quiet one. Plain MLLP over TCP for HL7v2 is unencrypted by default. Wrap it in TLS or a VPN tunnel. FHIR endpoints TLS-only. SFTP, not FTP, for file drops.
- Email: opportunistic TLS between mail servers guarantees nothing. Use secure messaging, Direct messaging, or the portal for PHI — "it's just to the referring office" is not an exception.
Key management is the part people skip
Encryption without key discipline is theater — and a fast route to losing your own data permanently. Get three things right:
- Separate keys from data. HHS's breach guidance says the key must not have been breached, and should live on a different device or location from the data it protects.
- Escrow, rotate, revoke. Store recovery keys in a managed system so a dead motherboard is an inconvenience rather than a data-loss event. Document how keys and certificates are rotated and revoked.
- Cover the cloud. Know whether your hosted EMR uses vendor-managed or customer-managed keys. Get the answer in writing, in the business associate agreement — not on a sales slide.
A note on the proposed Security Rule update
In December 2024, the HHS Office for Civil Rights issued a Notice of Proposed Rulemaking that would modify the HIPAA Security Rule, and encryption is among the areas it addresses. It is a proposal. It has not been finalized. Until a final rule publishes, the Security Rule as it stands today — the one cited throughout this article — is the one that applies to you, and any compliance dates would run from the final rule, not the proposal.
Common questions
Does HIPAA require encryption of ePHI?
Encryption is Addressable — 45 CFR 164.312(a)(2)(iv) at rest and 164.312(e)(2)(ii) in transit — not Required. Addressable does not mean optional: 45 CFR 164.306(d)(3) requires you to assess it, implement it if reasonable and appropriate, and otherwise document why not and implement an equivalent alternative. The Transmission Security standard itself is mandatory.
If an encrypted laptop is stolen, is it a reportable breach?
Breach notification obligations attach to unsecured PHI. If the ePHI was encrypted consistent with HHS's guidance on rendering PHI unusable, unreadable, or indecipherable — and the key was not also compromised — it is not unsecured PHI. You still investigate and document, but the notification trigger differs.
Our EMR is cloud-hosted. Doesn't the vendor handle encryption?
Partly, never entirely. ePHI still lands on your endpoints, browser sessions, local exports and backups. Get the vendor's encryption and key-management posture in writing, confirm it in the business associate agreement, and encrypt everything on your side of the line.
Are the 2026 HIPAA encryption requirements in effect?
No. HHS OCR issued a Notice of Proposed Rulemaking in December 2024 that would modify the Security Rule and addresses encryption among other areas. It has not been finalized. Until a final rule publishes, the existing Security Rule applies, and any compliance dates would run from the final rule rather than the proposal.
Common questions
Does HIPAA require encryption of ePHI?
Encryption is Addressable — 45 CFR 164.312(a)(2)(iv) at rest and 164.312(e)(2)(ii) in transit — not Required. Addressable does not mean optional: 45 CFR 164.306(d)(3) requires you to assess it, implement it if reasonable and appropriate, and otherwise document why not and implement an equivalent alternative safeguard. The Transmission Security standard itself is mandatory.
If an encrypted laptop is stolen, is it a reportable breach?
Breach notification obligations attach to unsecured PHI. If the ePHI was encrypted consistent with HHS guidance on rendering PHI unusable, unreadable, or indecipherable, and the decryption key was not also compromised, the information is not unsecured PHI. You still investigate and document, but the notification trigger differs. This is the strongest practical case for encrypting endpoints.
Our EMR is cloud-hosted. Does the vendor handle encryption for us?
Partly, never entirely. The vendor is a business associate with its own obligations, but ePHI still lands on your endpoints, browser sessions, local exports and backups. Get the vendor's encryption and key-management posture in writing, confirm it in the business associate agreement, and encrypt everything on your side.
Are the 2026 HIPAA encryption requirements in effect?
No. HHS OCR issued a Notice of Proposed Rulemaking in December 2024 that would modify the Security Rule and addresses encryption among other areas. It has not been finalized. Until a final rule publishes, the existing Security Rule applies and any compliance dates would run from the final rule, not the proposal.