Encrypting PHI at Rest: What Employee Health Programs Need to Know

There is a myth worth clearing up before it costs someone a compliance argument: HIPAA does not, today, flatly require encrypting PHI at rest. When an IT vendor or a software salesperson says "encryption at rest is a HIPAA requirement," they are overstating the rule — and overstating the rule is its own kind of risk when a regulator is reading your documentation.

The accurate answer is more useful anyway. Encryption at rest is addressable, not required — but addressable is a long way from optional. For any system holding Social Security numbers, dates of birth, and immunization histories, encryption is almost always the reasonable choice, and a pending federal rule would make it mandatory outright. This guide walks through what that distinction means, what to encrypt, how keys factor in, and what is about to change.

"Addressable" vs. "Required" — and why it is not a loophole

Under the current HIPAA Security Rule, encrypting ePHI at rest is an addressable implementation specification. The regulation 45 CFR 164.312(a)(2)(iv) tells a covered entity to "implement a mechanism to encrypt and decrypt electronic protected health information" — but files it under addressable, not required.

That word trips people up. Addressable does not license you to skip the safeguard on a whim. Per 45 CFR 164.306(d)(3), you have to assess whether the safeguard is reasonable and appropriate for your environment, then do one of two things: implement it, or document in writing why it is not reasonable and appropriate and put an equivalent alternative measure in place instead.

So the real question is not "do I have to encrypt?" It is "can I write a defensible risk analysis explaining why I didn't?" For a multi-tenant platform storing SSNs and DOBs for thousands of employees, that is a very hard memo to write, and a decision not to encrypt is precisely the kind of choice that draws OCR scrutiny. In practice, encryption is the reasonable-and-appropriate answer nearly every time.

At rest vs. in transit — two different problems

These get lumped together, but they defend against different threats.

Encryption at rest protects stored data — the database, the disk, backups, object storage, a laptop, a USB stick left in a car. HHS points to NIST SP 800-111, the Guide to Storage Encryption Technologies for End User Devices, for this. It covers full-disk, volume, and file-level encryption of information that is sitting still.

Encryption in transit protects data moving across a network — TLS on a web form or an API call, for example. That is a separate addressable specification, 45 CFR 164.312(e)(2)(ii), which calls for "a mechanism to encrypt electronic protected health information whenever deemed appropriate."

Both matter. A system with a hardened TLS connection that still writes plaintext SSNs into an unencrypted database has solved the smaller problem and left the larger one wide open. Most modern breaches involve stolen databases and backups, not intercepted traffic.

What should you actually encrypt?

There is no HIPAA list of "fields that must be encrypted." The Security Rule protects all ePHI. But for a practical inventory of the high-risk identifiers to prioritize, borrow the Privacy Rule's Safe Harbor de-identification list at 45 CFR 164.514(b)(2). It names 18 identifier categories, and the list reads like a threat map for an occupational-health record:

• Names
• All elements of dates (except year) directly related to an individual — including birth date
• Social Security numbers
• Geographic and address data (home address)
• Telephone and fax numbers
• Email addresses
• Medical record and account numbers
• Biometric identifiers
• Full-face photographs

Map that onto what your program actually stores. SSN, DOB, name, home address, and personal phone or email are the identifiers that turn a leaked record into identity theft, so protect those first if you are triaging. Then there is the clinical content: immunizations, exam results, incident and exposure reports, diagnoses. The whole record is PHI — the identifiers are just where the damage concentrates.

Key management: where good encryption quietly falls apart

Encryption is only as strong as the key behind it. HHS points to NIST storage-encryption guidance (SP 800-111) for the at-rest mechanics, and a few key-handling principles matter more than the specific algorithm you choose:

• Keys live separately from the data they protect. If the decryption key sits in the same database dump an attacker walks off with, the encryption bought you nothing.
• A single application key for every tenant is a concentration risk. One compromised key exposes everyone. Segmenting keys limits the blast radius.
• You need a rotation and re-encryption path. Keys get compromised, staff leave, standards move. If rotating the key means old records can no longer be read, that is not key management — it is a liability waiting to surface during an audit or a breach.
• Never commit keys to source control or a config repo. A production encryption key checked into a git repository in plaintext is a failure mode teams hit more often than they admit, and it makes the encryption decorative: anyone with repo access can decrypt everything.

That last point ties directly to the breach rules below. The safe harbor only holds if the key was not compromised alongside the data.

The payoff: the breach-notification safe harbor

The strongest practical case for encrypting at rest comes not from the Security Rule but from the Breach Notification Rule.

Breach notification applies only to unsecured PHI. 45 CFR 164.402 defines unsecured PHI as data "not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary." Encryption is one of those methodologies.

In plain terms: if a laptop holding properly encrypted records is stolen and the key was not taken with it, that generally is not a reportable breach. No notification letters to every affected employee, no HHS filing, no coverage in the local paper. A lost device becomes an internal note rather than a public incident. For most programs, that is the benefit that justifies the engineering effort.

What is changing: the 2025 proposed rule

The regulatory ground is shifting. On January 6, 2025, HHS published a Notice of Proposed Rulemaking, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (Federal Register doc 2024-30983); the comment period closed March 7, 2025.

According to the HHS summary of the proposal, it would remove the required-vs-addressable distinction entirely — making nearly all specifications mandatory — and would explicitly require encryption of ePHI both at rest and in transit, along with multi-factor authentication, technology asset inventories, and network mapping (HHS NPRM fact sheet).

It remains a proposed rule, not a final one, so encryption at rest is still legally addressable as of this writing. But the direction is unambiguous. A program built around encryption today absorbs the rule change as a non-event; one leaning on a "we documented why we didn't" memo is watching that option narrow.

One caveat for employee-health programs

Not every employee health record is HIPAA PHI. HIPAA's definitions exclude employment records that a covered entity holds in its role as employer, which means some employer-held data can fall under EEOC confidentiality rules (ADA and GINA) or OSHA's medical-records standard rather than HIPAA. The governing statute can differ from file to file — but the encryption practices above apply regardless of which one covers a given record. Do not assume every record is HIPAA PHI; do protect all of them to the same standard.

FAQ

Does HIPAA require encryption at rest? Not literally, today. It is an addressable specification (45 CFR 164.312(a)(2)(iv)) — you either implement it or document a justified, equivalent alternative (164.306(d)(3)). A 2025 proposed rule would make it mandatory, but that rule is not yet final.

If our data is encrypted and a device is stolen, do we still have to notify? Generally no. Breach notification applies only to unsecured PHI (45 CFR 164.402). Properly encrypted data whose key was not compromised typically falls outside that obligation.

What fields matter most? There is no official field list, but the Safe Harbor identifiers (164.514(b)(2)) are the priority set: SSN, DOB, name, address, phone, and email, plus the clinical content.

If you want to know where your program stands, start with a simple inventory: list every place employee health data lives — databases, backups, exports, laptops — and note which are encrypted and where the keys are held. Modern health-records platforms, including carefoundryESC, encrypt identifiers like SSN and DOB at rest, but the inventory is worth doing whatever system you run. The aim is not to tick a box; it is to be able to state, in writing, exactly how each record is protected and why.