17 min read

HIPAA Encryption Standards for 2026

HIPAA encryption requirements today: addressable, but expected at rest and in transit. If an encrypted laptop is stolen, safe harbor can mean no breach notice at all.

HIPAA does not require encryption outright today, but it is not optional. Encryption of ePHI (patient health information in electronic form) is “addressable.” That means you encrypt where it is reasonable and appropriate. If not, write down why and use an equivalent safeguard if reasonable. A January 2025 proposal would make encryption required, but it is not final.

HIPAA encryption standards set how you must protect electronic protected health information (ePHI), both when it is stored and when it is sent. They apply to covered entities, which means health care providers that bill electronically, plus health plans and clearinghouses. They also apply to business associates, the vendors that handle patient data for them.

Today, encryption is “addressable.” That means you must use it if it is reasonable for your practice, or write down why not. A proposed Security Rule update would make it required for all ePHI. That proposal is not final.

In 2020, Lifespan Health System wrote a check to the Office for Civil Rights for $1.04 million. The reason: an unencrypted laptop was stolen from an employee’s car. The laptop contained records for 20,431 patients. Names, medical record numbers, basic patient details and medication information: all of it sitting on a hard drive with no encryption.

Here’s the part that should keep every practice administrator up at night: if that laptop had been encrypted, HIPAA’s safe harbor provision would have meant no breach notification was required. No letters to patients. No breach report to OCR. No Wall of Shame listing. OCR also found other gaps at Lifespan, such as weak controls over devices and storage media. But one stolen, unencrypted laptop started it all, and the $1.04 million settlement followed.

Lifespan isn’t an outlier. Children’s Medical Center of Dallas paid $3.2 million in 2017 over unencrypted devices containing patient data. MD Anderson Cancer Center was hit with $4.3 million in penalties for the same issue, unencrypted laptops and thumb drives, though the Fifth Circuit threw out that penalty in 2021. The court found that MD Anderson had an encryption mechanism in place, and that HHS could not defend the penalty amount (University of Texas M.D. Anderson Cancer Center v. HHS, 985 F.3d 472 (5th Cir. 2021)). The pattern repeats across years of enforcement history: organizations that skip encryption pay for it, and they pay enormously more than encryption ever would have cost.

HIPAA itself does not name a specific encryption method. HHS guidance points to NIST, the federal agency that sets technical standards. Those NIST guides point to strong encryption, such as AES, for stored data. For data being sent, they point to TLS 1.2 or higher. This article breaks down what HIPAA requires for encryption, what would change under the proposed Security Rule update, and what you need to do right now to protect your practice and your patients.

What HIPAA Actually Says About Encryption

The HIPAA Security Rule addresses encryption in two places:

  • 45 CFR 164.312(a)(2)(iv): encryption of electronic protected health information (ePHI) at rest. This covers data stored on hard drives, servers, backup media, USB drives, and any other storage medium.
  • 45 CFR 164.312(e)(2)(ii): encryption of ePHI in transit. This covers data moving across networks: emails, file transfers, connections between your systems and your vendors.

Both of these specifications are currently classified as “addressable” under the Security Rule. And this is where most of the confusion (and most of the fines) originate.

“Addressable” does not mean optional. It never has. What it means is: you must evaluate whether the safeguard is reasonable and appropriate for your organization (sensible, given your size, risks and costs). If it is, you implement it. If it genuinely isn’t, you must document why and implement an equivalent alternative if one is reasonable and appropriate (45 CFR 164.306(d)(3)). The third option (just skipping it) isn’t on the menu.

We wrote an entire article about this distinction because it’s the most expensive misunderstanding in HIPAA compliance: Why “Addressable” Doesn’t Mean “Optional”.

In practice, OCR treats encryption as the expected standard. When investigators show up after a breach and find unencrypted devices with no documentation explaining why encryption wasn’t implemented, the conversation goes badly. The burden is on you to justify the absence of encryption, not on OCR to prove you should have had it.

Behavioral health and substance use programs carry a second rule on top of this. Opus EHR has written a clear explanation of how 42 CFR Part 2 encryption rules differ from HIPAA for behavioral health. If you run a treatment program, read both.

Encryption at Rest: Protecting Stored Patient Data

Encryption at rest means that data stored on any device or medium is unreadable without the proper decryption key. If a laptop is stolen, a server is compromised, or a backup drive is lost, encrypted data is useless to whoever finds it.

Full-Disk Encryption on Workstations and Laptops

This is the lowest-hanging fruit in all of healthcare security. Both major operating systems include free, built-in full-disk encryption:

  • BitLocker for Windows (included in Windows 10/11 Pro and Enterprise editions)
  • FileVault for Mac (included in every version of macOS)

Turning either of these on takes minutes. Once active, the entire hard drive is encrypted automatically. The user experience doesn’t change: staff log in the same way they always have. The only difference is that if the device is stolen or lost, the data on it is unreadable.

There is virtually no defensible reason for any practice to have unencrypted laptops or workstations in 2026. BitLocker and FileVault are free, built into the operating system, and transparent to end users. Every enforcement case involving an unencrypted stolen device is a case that didn’t need to happen.

Database and Application Encryption

If your practice runs on-premises servers or stores patient data in local databases, those databases should be encrypted using AES-256, an encryption method approved by NIST (FIPS 197). NIST also validates (officially approves) encryption products under FIPS 140-2 and its newer version, FIPS 140-3. Most modern database systems (SQL Server, PostgreSQL, MySQL) support transparent data encryption that encrypts the entire database without requiring application changes.

For cloud-based EHR systems, your vendor handles this, but you should verify it. Ask your EHR vendor: “Is our data encrypted at rest? What encryption standard do you use?” The answer should be AES-128, AES-192, or AES-256.

If they can’t answer, that’s a red flag worth digging into during your next risk assessment. The same scrutiny applies to newer tools entering healthcare workflows. If your organization is evaluating whether ChatGPT is HIPAA compliant, encryption of data at rest and in transit is one of the first questions to ask the vendor.

Mobile Devices

iPhones and iPads encrypt data by default when a passcode is set. This is one of the few areas where the default settings actually do the encryption for you. The key is making sure every device that accesses patient data has a passcode enabled, no exceptions.

Android devices vary by manufacturer and version. Most modern Android devices (version 10 and later) encrypt by default, but older devices may not. If your practice allows staff to use personal Android phones to access email or patient portals, you need a policy requiring encryption and a way to verify it.

Backup Encryption

This is the one that gets overlooked. Practices diligently encrypt their laptops and servers, then back everything up to an unencrypted external hard drive that sits in an unlocked closet. Or they send unencrypted backups to a cloud service without verifying that the data is encrypted in storage.

Your backup media (whether it’s external drives, tape, or cloud storage) needs to be encrypted with the same rigor as your primary systems. An unencrypted backup is a copy of everything you worked so hard to protect, sitting in a format anyone can read.

USB Drives and Portable Media

The safest policy is to prohibit USB drives entirely for anything involving patient data. If your practice needs portable media for legitimate purposes, those drives should be encrypted. Manufacturers like Kingston and Apricorn sell hardware-encrypted USB drives validated under FIPS 140-2 or the newer FIPS 140-3. They cost more than a basic thumb drive from an office supply store, but they cost infinitely less than a breach.

Encryption in Transit: Protecting Data in Motion

Encryption in transit protects data while it’s moving between systems: across your office network, over the internet, or between your practice and your vendors.

TLS 1.2 or Higher for All Data Transmission

TLS (Transport Layer Security) is the protocol that encrypts data moving across networks. The current minimum acceptable version is TLS 1.2. Older versions (TLS 1.0, TLS 1.1, SSL) have known vulnerabilities and should be disabled on all systems.

If your EHR, patient portal, or billing system connects over the internet, verify that it’s using TLS 1.2 or higher. Most modern systems do this by default, but legacy systems may not. Your IT person can check this in a few minutes.

HTTPS for Web-Based Systems

Every web-based system that handles patient data (your patient portal, your cloud EHR, your practice management system) should use HTTPS, not HTTP. HTTPS is simply HTTP with TLS encryption layered on top. If the URL in your browser bar doesn’t start with “https://” when you’re accessing a system that handles ePHI, something is wrong.

This applies to your own systems and to your vendors’ systems. If a vendor’s portal doesn’t use HTTPS, that’s a compliance conversation you need to have with them immediately.

Email Encryption

Email is one of the most common ways patient data leaks, and one of the hardest to secure properly.

At a minimum, your email system should use TLS encryption between mail servers. Most major email providers (Microsoft 365, Google Workspace) do this by default when both the sending and receiving servers support it. But TLS between servers is opportunistic: if the receiving server doesn’t support TLS, the email goes out unencrypted and nobody gets notified.

For better protection, consider:

  • Portal-based secure messaging: The recipient gets a notification email and clicks a link to read the secure message in a web portal. This is how most HIPAA-compliant email services work (Paubox, Virtru, Hushmail for Healthcare).
  • End-to-end encryption: The message is encrypted from the sender’s device to the recipient’s device. More secure, but harder to implement and use.

The practical takeaway: if your practice sends patient information by email, you should have an encryption solution beyond basic TLS. “We use Gmail” or “We use Outlook” is not sufficient documentation of your email encryption controls.

VPN for Remote Access

If staff access practice systems remotely (from home, from a satellite office, from a hospital), they should be using a VPN (Virtual Private Network) that encrypts the connection between their device and your network. This is especially important when staff connect from public Wi-Fi at coffee shops, airports, or hotels. Encryption protects the data in transit, but it does not verify who is on the other end of the connection. That is where multi-factor authentication closes the gap by ensuring only authorized users access your systems remotely.

Wireless Network Encryption

Your office Wi-Fi network should use WPA3 encryption (preferred) or WPA2 at minimum. WPA and WEP are insecure and should never be used. Your clinical network (the one your EHR and workstations connect to) should be separate from your guest network, and both should require passwords.

The Safe Harbor Provision: Why Encryption Is Your Best Insurance

This is the section that makes the business case for encryption more clearly than any technical argument ever could.

Under 45 CFR 164.402, breach notification rules cover only “unsecured” protected health information. Encrypted data is not unsecured if it follows HHS guidance, which points to NIST standards. The encryption key must not also be stolen or exposed. If both are true, losing that data or having it stolen is not a reportable breach.

Read that again. If an encrypted laptop is stolen from your employee’s car, and the encryption follows the NIST standards that HHS guidance points to (such as NIST SP 800-111 for stored data), you do not have to:

  • Report the incident to OCR
  • Send notification letters to every affected patient
  • Notify the media (required for breaches affecting more than 500 residents of a state)
  • Appear on OCR’s Breach Portal (the “Wall of Shame”)
  • Face an OCR breach investigation

The financial stakes are real. Breach notification means mailing costs, call center setup, credit monitoring services, legal review, and public relations. All of that adds up before any fine is assessed.

The average healthcare data breach cost $7.42 million in 2025, per the IBM Cost of a Data Breach Report, making healthcare the most expensive industry for breaches for the fourteenth consecutive year. And the volume of attacks keeps climbing. See our look at healthcare breach trends from 2025.

Encryption costs virtually nothing by comparison. BitLocker and FileVault are free. TLS is built into every modern system. Database encryption is often a configuration setting. For a small practice, the main cost is usually IT time.

Look at it from the other direction: Children’s Medical Center of Dallas paid $3.2 million in penalties over unencrypted devices. Encrypting those devices would have cost far less than that. For most practices, encryption is one of the most cost-effective safeguards you can put in place.

What the Proposed Security Rule Would Change

Everything above describes the current rules. What HHS has proposed is even more straightforward.

The proposed HIPAA Security Rule update, published as a Notice of Proposed Rulemaking on January 6, 2025, would remove the “addressable” category entirely. Under the proposed rule, encryption of stored and sent ePHI would move from “addressable” to “required”. Only a few narrow exceptions would remain. No more “we evaluated it and decided it wasn’t reasonable.” If the proposal becomes final as written, you encrypt or you are out of compliance.

The proposed rule does not name one specific algorithm. It would require encryption that meets current, widely accepted standards. In practice, that means something like AES-256 for stored data and TLS 1.2 or higher for data being sent.

The rule is not final, and today’s rule still applies. HHS’s target for a final rule has slipped from May 2026 to July 2027. If it becomes final as proposed, practices would have about 240 days after publication to comply.

Organizations that implement encryption now will be ahead if the proposal becomes final. Organizations that wait could be scrambling to encrypt every device, every database, every email system, and every data connection in their environment before the clock runs out. That’s not a project you want to rush.

If you haven’t reviewed the full scope of what could change, our breakdown covers all seven major proposed changes: The Proposed HIPAA Security Rule: 7 Major Changes.

Encryption Checklist for Small Practices

Use this checklist to audit your current encryption posture. For each item, document whether it’s in place, and if not, what your remediation plan is. This documentation becomes part of your risk assessment.

Laptops and Desktops

Mobile Devices

Email

Cloud Storage and EHR

Backups

USB Drives and Portable Media

Wireless Networks

Remote Access

Data in Transit

Every unchecked box on this list is a gap in your security posture, and a potential finding in an OCR investigation. The good news is that most of these items are straightforward to implement, and many are free. The hardest part is doing the inventory and making sure nothing gets missed.


HIPAA Encryption Standards Reference

HIPAA does not name specific algorithms, but NIST guidance and OCR enforcement actions establish clear expectations for encryption implementations.

Data StatePreferredMinimum StandardHIPAA CFR Reference
Data at rest (storage)AES-128 or AES-256AES-128 (256 preferred)164.312(a)(2)(iv)
Data in transit (email)TLS 1.2+TLS 1.2 minimum164.312(e)(2)(ii)
Data in transit (web)TLS 1.3TLS 1.2 minimum164.312(e)(1)
Full disk encryptionAES-256 (XTS mode)AES-128164.312(a)(2)(iv)
Database encryptionAES-256 (TDE or column-level)AES-128164.312(a)(2)(iv)
Backup encryptionAES-256AES-128164.312(a)(2)(iv)

Key point: The encryption safe harbor in 45 CFR 164.402 protects you when a laptop, phone, or USB drive with ePHI is lost or stolen. With proper encryption, you send no letters to patients, file no breach report to OCR, and get no media attention. The return on encryption is not theoretical. It can be the difference between a non-event and a settlement like Lifespan’s $1.04 million.

Sources

Frequently Asked Questions

What are the current HIPAA encryption standards?

HIPAA does not name a specific algorithm. Today, encrypting ePHI is “addressable.” That means you must encrypt stored and sent data if it is reasonable and appropriate for your practice. If it is not, you write down why.

Then you use an equivalent safeguard if one is reasonable and appropriate. For stored data, HHS guidance points to NIST Special Publication 800-111 (AES-128 or AES-256 fits). For data being sent, it points to NIST SP 800-52 (TLS 1.2 or higher). A proposed Security Rule update would make encryption required for all stored and sent ePHI, with limited exceptions. That proposal is not final.

Does HIPAA require end-to-end encryption for email?

No. HIPAA does not mandate a specific email encryption method. Under 45 CFR 164.312(e)(2)(ii), encrypting data in transit is addressable, not a flat rule. In practice, email that carries PHI should still be protected on its way. At a minimum, use TLS 1.2 or higher between mail servers.

If you cannot confirm TLS for the recipient, use a secure portal or an encrypted message instead. HHS guidance also allows unencrypted email to a patient who asks for it, after you warn them of the risk. Free consumer email accounts usually do not come with a business associate agreement. That is the contract HIPAA requires with vendors that handle PHI. So use a business email service that signs one.


Need help getting your encryption and security controls in order? One Guy Consulting offers affordable HIPAA compliance packages for practices of all sizes. One Guy Consulting HIPAA services

Related reading: The HIPAA Copier Hard Drive Problem: What Leaves at Lease End

FAQ

Frequently Asked Questions

Is encryption required or addressable under HIPAA?

Encryption is classified as an addressable implementation specification under the HIPAA Security Rule. However, addressable does not mean optional. You must use encryption if it is reasonable and appropriate for your practice. If it is not, write down why. Then use an equivalent safeguard if one is reasonable and appropriate (45 CFR 164.306(d)(3)). A January 2025 proposal would make encryption required, but it is not final.

What encryption standard does HIPAA require?

HIPAA does not name a specific standard. HHS breach guidance points to NIST. That means NIST SP 800-111 for stored data (AES-128 or AES-256 fits), and TLS 1.2 or higher for data being sent. Data encrypted this way is not "unsecured" under the Breach Notification Rule. So if it is lost or stolen, and the key was not also exposed, it is not a reportable breach.

Do I need to encrypt email to be HIPAA compliant?

HIPAA does not name an email encryption method. Encrypting data in transit is addressable, not a flat rule (45 CFR 164.312(e)(2)(ii)). If you send ePHI by email, you should still protect it. Use TLS for server-to-server email transport. Consider a HIPAA-compliant email encryption service for messages with patient information. HHS guidance does allow unencrypted email to a patient who asks for it after being warned of the risk.

OGC-BotHi! What can I help you with?