HIPAA Encryption Requirements: An Updated Guide
A stolen laptop. An intercepted email. A misconfigured database. Any of these can expose patient health information and trigger a HIPAA breach investigation—unless that data is properly encrypted.
HIPAA’s encryption requirements often confuse healthcare organizations because they’re labeled “addressable” rather than “required.” Addressable does not mean optional, and getting this wrong can cost millions in penalties. This guide breaks down what HIPAA expects for encryption, which standards are commonly used to meet those expectations, and how to implement encryption for data at rest and in transit.
What HIPAA Says About Encryption
HIPAA does not mandate a specific brand or algorithm for encryption. Instead, the Security Rule includes addressable implementation specifications for encrypting electronic protected health information (ePHI) both at rest and in transit.
Covered entities and business associates must:
Conduct a risk analysis.
Decide whether encryption is reasonable and appropriate.
Either implement encryption or document and implement an equivalent alternative safeguard.
Many organizations use industry-standard encryption such as AES for stored data and TLS for transmitted data to meet these specifications.
ePHI is any individually identifiable health information that is created, received, maintained, or transmitted electronically. Patient names, diagnoses, treatment records, images, and billing information all qualify when handled in digital form.
Encryption transforms readable data into unreadable ciphertext. Only authorized parties with the correct decryption key can access the original information. When implemented correctly, encryption makes ePHI unusable, unreadable, or indecipherable to anyone who intercepts or steals it.
Why HIPAA Encryption Is Addressable, Not Absolutely Required
The word "addressable" in the HIPAA Security Rule does not mean "do it if you feel like it." In fact, HHS has proposed removing the addressable distinction entirely, which would make encryption of ePHI at rest and in transit required with limited exceptions. Under the current rule, it means you have a choice to:
Implement the addressable safeguard as written, or
Implement an equivalent alternative, and
Document your analysis and decision.
For most organizations that handle ePHI, encryption is the most practical, defensible, and cost-effective way to meet the standard of protection expected by regulators and business partners.
The Office for Civil Rights (OCR), which enforces HIPAA, rarely accepts weak or informal alternatives to encryption. If you choose not to encrypt, you must have a compelling, well-documented reason and a clearly equivalent protection in place.
How to Document an Alternative to Encryption
If encryption truly is not reasonable for a specific system or use case, you must:
Perform a formal risk analysis.
Document in detail why encryption is not reasonable and appropriate.
Design and implement an alternative control that reduces risk to a similar level.
Review and update this documentation over time.
Cost or perceived complexity alone (“we didn’t have the budget” or “it seemed complicated”) will not satisfy OCR. The bar for acceptable alternatives is high.
The Encryption Safe Harbor for Breach Notification
Under the HIPAA Breach Notification Rule, properly encrypted ePHI can qualify for safe harbor. If encrypted ePHI is lost or stolen but the encryption keys remain secure and the implementation meets recognized standards, the incident may not be considered a reportable breach.
In that scenario, you may not need to notify affected individuals, HHS, or the media. This is one of the strongest incentives to encrypt laptops, mobile devices, databases, backups, and network traffic that carry ePHI.
How to Conduct a Risk Assessment for HIPAA Encryption
Every encryption decision should be grounded in a documented risk analysis. Without it, you are guessing about where your most serious vulnerabilities are.
Identify All Systems That Store or Transmit ePHI Build and maintain an inventory of every device, server, cloud service, database, and communication channel that handles ePHI. Include:
Laptops and desktops
Mobile devices and tablets
On-premises servers and virtual machines
Cloud storage and SaaS platforms
Backup systems and removable media
Evaluate Threats and Vulnerabilities For each system, assess risks such as:
Device loss or theft
Unauthorized physical or logical access
Data interception during transmission
Misconfiguration of cloud resources
Insider threats and user error
Determine Likelihood and Impact Estimate how likely each threat is to occur and how severe the impact would be. A stolen, unencrypted laptop with thousands of patient records poses a very different risk than a well-hardened internal database with strong access controls and limited ePHI.
Decide on Encryption and Alternatives Use the risk analysis to decide where encryption is required, where it is strongly recommended, and whether any limited use cases justify an alternative safeguard.
Document and Monitor Decisions Documentation is critical for OCR audits and investigations. Record:
Your risk assessment method and findings
Where and how encryption is implemented
Any approved alternatives, with rationale
How you monitor controls over time
Review and update this documentation at least annually and whenever systems, threats, or business processes change.
Common HIPAA-Aligned Encryption Standards
The Department of Health and Human Services (HHS) points to National Institute of Standards and Technology (NIST) guidance when describing acceptable methods for rendering ePHI “unusable, unreadable, or indecipherable.” Organizations commonly adopt the following standards to align with that guidance.
AES Encryption for Data at Rest
The Advanced Encryption Standard (AES) is widely used to protect data at rest:
AES-128: 128-bit keys; widely deployed and considered secure for many use cases.
AES-192: 192-bit keys; used less often but still acceptable.
AES-256: 256-bit keys; commonly recommended for high-sensitivity healthcare workloads.
All three key lengths are acceptable when implemented correctly. Many organizations standardize on AES-256 for ePHI to align with conservative, defense-in-depth practices.
NIST and FIPS 140-Validated Cryptography
NIST issues cryptographic guidance that HHS references in its breach notification materials. Many organizations look for FIPS 140-2 or FIPS 140-3 validated cryptographic modules as a benchmark when selecting products and services for HIPAA environments.
TLS for Data in Transit
Transport Layer Security (TLS) is the de facto standard for encrypting data in transit over IP networks:
| Protocol | Use Case | HIPAA Context |
|---|---|---|
| TLS 1.2 | Data in transit | Commonly used, baseline today |
| TLS 1.3 | Data in transit | Preferred where available |
TLS 1.2 and 1.3 are widely accepted in healthcare. Older versions (such as TLS 1.0 and 1.1) are generally considered deprecated and should be disabled.
How to Encrypt Healthcare Data at Rest
Data at rest includes any ePHI stored on devices, servers, databases, or backups when it is not actively moving across a network. Because device loss and server compromises are common, encryption at rest is a core safeguard.
Full Disk Encryption
Full disk encryption (FDE) encrypts an entire storage drive, including the operating system and all files. It is often used for:
Laptops and desktops
Mobile devices
Some on-premises and cloud servers
If a device using FDE is lost or stolen and is powered off or locked, the data on the drive remains protected.
Virtual Disk or Volume Encryption
Virtual disk encryption creates an encrypted container, volume, or partition for sensitive data. This approach works well when:
You cannot turn on FDE for technical reasons, or
You want to keep ePHI isolated from other data on the same device.
File and Folder-Level Encryption
File and folder-level encryption protects specific files or directories that contain ePHI. It offers granular control but requires robust processes to ensure that all ePHI is consistently stored in encrypted locations and not copied elsewhere in plain text.
How to Encrypt Data in Transit Under HIPAA
Data in transit includes ePHI sent over networks via:
Web applications and patient portals
APIs and web services
Email and secure messaging
File transfers and remote access tools
Because network traffic can be intercepted or observed, encryption in transit is a key safeguard in HIPAA risk management.
Transport Layer Security (TLS)
TLS is used to encrypt:
Browser sessions (HTTPS)
API calls
Many email connections (SMTP, POP, IMAP with TLS)
Configure TLS to:
Use current protocols (TLS 1.2 or 1.3)
Disable weak ciphers and legacy versions
Enforce HTTPS for web applications that handle ePHI
IPSec Virtual Private Networks
IPSec-based VPNs create encrypted tunnels for remote access. They are commonly used to:
Allow clinicians and staff to connect securely from home or remote clinics
Connect on-premises data centers to cloud environments
Protect traffic between sites or networks that carry ePHI
HIPAA Database Encryption Considerations
Databases that contain ePHI are high-value targets for attackers. Encrypting databases provides protection beyond filesystem or storage-level encryption.
Transparent Data Encryption (TDE)
Transparent Data Encryption encrypts database files on disk without requiring application changes. TDE typically protects:
Data files
Transaction logs
Database backups
TDE is a straightforward way to add encryption at rest for relational databases that store ePHI.
Column-Level Encryption
Column-level encryption is used for specific sensitive fields, such as:
Social Security numbers
National identifiers
Diagnoses or highly sensitive clinical notes
This approach allows you to encrypt only the most sensitive columns while leaving other fields readable for reporting or analytics.
Application-Level Encryption
With application-level encryption, the application encrypts data before writing it to the database. Even if the database or storage layer is compromised, the attacker sees only ciphertext.
Application-level encryption is more complex to design and operate but can provide a stronger separation of duties and limit who can decrypt ePHI.
HIPAA Encryption Key Management Best Practices
Encryption is only as strong as your key management practices. Poor key management can undo the benefits of encryption.
Key Generation and Storage
Generate keys using strong, approved methods.
Store keys separately from the encrypted data.
Use hardware security modules (HSMs) or managed key management services where possible for systems that handle large volumes of ePHI.
Key Rotation and Lifecycle Management
Define and enforce a key lifecycle that covers:
Key creation and distribution
Regular rotation
Archival and recovery procedures
Secure destruction when keys are no longer needed
Long-lived, rarely rotated keys increase risk.
Access Controls for Encryption Keys
Limit access to keys to a small group of authorized personnel.
Enforce least privilege and separation of duties.
Log and monitor all key access and administrative actions.
In practice, you should be able to show:
Separate storage of keys and data
Detailed access logging and alerts
Regular rotation based on policy
Documented procedures for secure key destruction
How Firewalls Support HIPAA Security
While HIPAA does not prescribe a specific firewall product, network security controls such as firewalls and intrusion detection systems support the Security Rule’s technical safeguards.
Effective firewall configurations can help:
Segment networks: Isolate systems that store or process ePHI from general corporate or guest networks.
Control access: Limit inbound and outbound traffic to only what is needed for clinical and business workflows.
Detect intrusions: Monitor for suspicious connections, port scans, or abnormal traffic patterns.
Provide audit trails: Log network activity to support investigations and demonstrate due diligence.
Keep firewall rules and firmware up to date, and review configurations regularly as part of your risk management program.
What Happens If You Do Not Encrypt PHI
Not encrypting ePHI where it is reasonable and appropriate creates significant financial, legal, and reputational risk. According to IBM's 2025 report, healthcare data breaches cost an average of $7.42 million per incident—the highest of any industry for the fourteenth consecutive year.
OCR Enforcement Actions and Penalties
OCR enforces HIPAA and has issued significant penalties where encryption was missing or poorly implemented. The penalty structure ranges from unknowing violations to willful neglect and can reach $2,190,294 per violation category, especially when organizations fail to correct known gaps.
Breach Notification Obligations
If unencrypted ePHI is lost, stolen, or accessed by an unauthorized party, you generally must:
Conduct a breach risk assessment, and
Notify affected individuals, HHS, and in some cases the media (for incidents affecting 500 or more individuals).
When ePHI is encrypted in line with recognized standards and keys remain secure, many incidents will not meet the definition of a reportable breach, reducing the likelihood of large-scale notification and public reporting.
Reputational and Business Impact
Beyond regulatory penalties, failures to encrypt ePHI can lead to:
Loss of patient and member trust
Contract terminations or lost renewals
Increased scrutiny from partners, payers, and regulators
Higher costs for remediation, monitoring, and litigation
How Continuous Compliance Simplifies HIPAA Encryption
Manually tracking encryption controls, gathering screenshots, and assembling evidence before an audit is slow and error-prone. As environments grow, it becomes harder to know whether all systems that touch ePHI are:
Encrypted at rest where appropriate
Using strong, current protocols in transit
Covered by consistent key management policies
Continuous compliance platforms help by:
Automating evidence collection from your infrastructure, devices, and cloud services
Continuously monitoring encryption-related controls and configurations
Surfacing gaps before they become audit findings or breaches
Maintaining audit-ready documentation for frameworks like HIPAA over time
Instead of scrambling to prove encryption after the fact, teams can see their control posture in near real time and remediate issues early.
FAQs About HIPAA Encryption Requirements
Does HIPAA require end-to-end encryption for email containing ePHI?
HIPAA requires you to address the risk of transmitting ePHI over open networks. Encryption for email in transit is an addressable specification, not an absolute mandate, but in practice encryption is expected when email travels across the internet.
TLS encryption for email in transit is commonly used to meet this expectation. End-to-end encryption offers stronger protection, especially for messages that may be stored on third-party mail servers outside your direct control.
How often should organizations update their HIPAA encryption protocols?
Review your encryption protocols:
During annual or periodic risk assessments
When new vulnerabilities are discovered
When you add or change major systems, vendors, or architectures
When standards bodies or vendors deprecate algorithms or protocols
Many organizations also set policy-based review intervals (for example, annually) even if no obvious change has occurred.
Can cloud service providers handle HIPAA encryption on behalf of covered entities?
Yes. Cloud providers can manage encryption and keys on your behalf, but:
You must have a Business Associate Agreement (BAA) in place.
You remain responsible for ensuring the provider’s controls, configurations, and shared responsibility model meet your HIPAA obligations.
You should regularly review the provider’s documentation, attestations, and security posture.
What is the difference between encryption and tokenization for protecting ePHI?
Encryption converts plaintext into ciphertext using a key; the original data can be recovered by decrypting with the correct key.
Tokenization replaces sensitive data with non-sensitive tokens stored in your systems; the original values are kept in a separate, protected token vault.
Both approaches can help protect ePHI. Encryption is explicitly referenced in HIPAA guidance, while tokenization is often used alongside encryption to reduce the footprint of sensitive data in downstream systems.