Encryption at rest and in transit, explained

The two halves, in plain words

The HIPAA Security Rule defines encryption, in 45 CFR 164.304, as the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key. In short: scrambled data that only someone with the key can read.

In transit means while data travels: from your computer to a vendor's website, from the vendor's servers to a messaging provider, between data centers. The usual protection is TLS, the technology behind the padlock in your browser. Without it, someone positioned on the network could read data as it passes.

At rest means while data sits somewhere: in a database, a backup, a laptop's hard drive, a USB stick, a phone. The usual protection is storage encryption, commonly using AES. Without it, anyone who gets the disk, the backup file or the stolen laptop can read everything on it.

You need both. Data that is encrypted on the wire but stored in plain form is exposed the moment a server, backup or laptop is compromised. Data that is encrypted on disk but sent unprotected is exposed every time it moves.

What HIPAA requires today

The Security Rule lists encryption in two places: encryption and decryption of stored electronic PHI, in 45 CFR 164.312(a)(2)(iv), and encryption of electronic PHI in transmission, in 45 CFR 164.312(e)(2)(ii). Both are addressable implementation specifications.

Addressable is often misunderstood. It means a practice must assess whether the measure is reasonable and appropriate for its environment. If it is, the practice implements it. If not, the practice must document why and implement an equivalent alternative where reasonable. For most modern systems handling patient data, it is hard to argue that encryption is unreasonable.

That may become a firm requirement. In January 2025, HHS proposed amendments to the Security Rule that would, among other changes, make encryption of electronic PHI at rest and in transit required, with limited exceptions. As of this writing the proposal had not been finalized. Practices that already encrypt everywhere will not need to change much if it is.

The breach safe harbor

Encryption matters for another reason: breach notification. Under 45 CFR 164.402, the duty to notify patients applies to unsecured PHI. HHS guidance explains that electronic PHI is secured if it has been encrypted consistent with NIST standards and the key has not been breached. The guidance points to:

• At rest: NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices.
• In transit: NIST Special Publications 800-52 (TLS), 800-77 (IPsec VPNs) and 800-113 (SSL VPNs), or other methods validated under FIPS 140.
• At end of life: NIST Special Publication 800-88, Guidelines for Media Sanitization, for destroying data.

What encryption does not protect against

Encryption is essential, but it is a lock on the box, not a guard at the door. It does not help when:

• A legitimate user is logged in. Data is decrypted for anyone with valid access. If a staff password is phished, the attacker sees what that staff member sees. That is why multi-factor authentication and role-based access matter just as much.
• The key travels with the data. A laptop with full-disk encryption but a password taped to the lid is not protected. HHS's safe harbor only applies if the key was not also compromised.
• Data leaves your control. A text message delivered to a patient's phone sits on that phone. Standard SMS is not end-to-end encrypted. The safeguard there is minimal content, not encryption.
• The message goes to the wrong person. Encryption delivers data securely to whoever the system sends it to, including the wrong recipient.

Questions to ask a vendor

"We use bank-level encryption" is not an answer. These questions get specifics:

1. Which version of TLS do you require for connections? NIST's TLS guidance, SP 800-52 Rev. 2, calls for TLS 1.2 at minimum and support for TLS 1.3.
2. Is all stored patient data encrypted, including databases, file uploads, logs and backups?
3. What algorithm do you use for data at rest? AES with 256-bit keys is common.
4. Who manages the encryption keys, how is access to them controlled and how often are they rotated?
5. Is data encrypted when it moves between your systems and your subcontractors, such as messaging or AI providers?
6. Are staff laptops and phones that can access our data encrypted and centrally managed?
7. Where is the data stored? Ask for the country and, ideally, the hosting provider.

Inside your own practice

Vendors are only half the picture. Check the devices and habits in your own office:

• Turn on full-disk encryption on every laptop and desktop that holds or accesses patient data. Modern operating systems include it.
• Require a passcode and encryption on any phone or tablet used for work.
• Ban unencrypted USB drives for patient data.
• Use your email system's encryption option, or a secure portal, for messages containing clinical detail.
• Record what is encrypted and how in your Security Rule risk analysis, so you can prove it if a device is ever lost.