HIPAA Encryption Requirements: The Complete Guide for Covered Entities and Business Associates

Key Takeaways

• HIPAA gives organizations flexibility on encryption, but the conditions for opting out are strict enough that most can’t meet them.
• NIST sets the technical bar: AES-256 for stored data, TLS 1.3 for data in motion.
• Getting encryption right can mean the difference between a contained incident and a public, regulated breach.
• Encryption is a lifecycle obligation, meaning that data sitting in an archive six years from now needs the same protection as data transmitted today.
• A proposed 2024 rule would close the opt-out pathway entirely, though regulatory uncertainty means the timeline is unclear.

Introduction

HIPAA encryption requirements come with a word that causes more confusion than it should: “addressable.” In this case, it doesn’t mean optional. It means that if you decide not to encrypt, you need a documented alternative that provides the same level of protection.

For most organizations handling electronic protected health information (ePHI) outside a closed internal network, that alternative doesn’t exist.

But the compliance checkbox is only part of the story. How you implement encryption, and whether it meets NIST’s specific guidance, determines something much more consequential: whether a data breach is legally required to be reported at all.

In this article, you’ll learn:

• Which NIST standards satisfy HIPAA’s requirements for data at rest and in transit, including what proper key management looks like
• How encryption can make a data breach legally non-reportable, and the exact conditions that have to be met
• Why encryption doesn’t stop at transmission
• What the obligation looks like for stored ePHI
• What a compliant archive needs to include

What HIPAA Encryption Requirements Actually Cover

The HIPAA Security Rule doesn’t say “you must encrypt all ePHI.” What it does say is more nuanced, and understanding the distinction matters when you’re building a defensible compliance program.

Encryption appears in two places within the Technical Safeguards of the Security Rule, under 45 CFR §164.312:

• §164.312(a)(2)(iv) — Access controls: Covered entities must implement a mechanism to encrypt and decrypt ePHI at rest. The intent is straightforward: anyone who accesses stored ePHI without authorization should find it completely unreadable.
• §164.312(e)(2)(ii) — Transmission security: Organizations must implement a mechanism to encrypt ePHI whenever it’s

transmitted over an electronic network. If patient data is moving between systems, it needs to be protected in transit.

Both specifications are tagged “addressable”, which, as covered above, doesn’t imply you can ignore them.

It means you have three options:

• Implement encryption,
• Implement an alternative measure that achieves the same outcome, or
• Document a risk-based justification for why neither applies.

The third option is rare in practice and difficult to defend under scrutiny.

The reason HIPAA doesn’t mandate a specific encryption algorithm is deliberate.

When the Security Rule was written, HHS recognized that technology evolves faster than regulation. Instead of locking organizations into standards that would become obsolete, the rule is intentionally technology-neutral. In other words, it specifies the outcome, not the method.

For guidance on what “good enough” actually looks like, HHS defers to NIST. Three publications are most relevant:

• NIST SP 800-111 — covers encryption of ePHI stored on end-user devices and servers
• NIST SP 800-52 — covers transport layer security for data in transit
• NIST SP 800-113 — covers VPN implementations for remote ePHI access

Following these guidelines satisfies the technical safeguard requirement and determines whether a breach qualifies for safe harbor under the Breach Notification Rule.

One thing enforcement history makes clear: “addressable” has never been treated as a pass.

OCR has issued seven-figure fines specifically for failure to encrypt, not for the breach itself, but for the documented failure to act on a known risk. The most instructive example of what that looks like in practice is covered in the breach notification section below.

Encryption Standards That Satisfy HIPAA: At Rest, In Transit, and Key Management

HIPAA encryption requirements are intentionally technology-neutral. NIST’s guidance fills in the specifics so that “we weren’t sure what to implement” is a difficult position to defend. Here’s what meets the bar, and what’s expected at each layer.

Data at rest

For ePHI stored on servers, workstations, laptops, mobile devices, or portable media, AES-256 (Advanced Encryption Standard with 256-bit keys) is the widely accepted standard.

It meets FIPS 140-2 validation requirements, which is how HHS determines if encrypted data qualifies as secured, and as such, is exempt from breach notification obligations.

Two implementation approaches are most common:

• Full-disk encryption (FDE) encrypts everything on a device’s storage, including the operating system and all files. It’s effective for protecting against physical theft or loss. For example, if a laptop is stolen and the attacker doesn’t have the credentials to unlock it, the data is inaccessible. BitLocker, FileVault, and similar tools fall into this category.
• File or folder-level encryption protects specific data rather than the entire disk. It’s more granular and useful in environments where only certain directories or databases contain ePHI, but it requires careful scoping to ensure nothing is left unprotected.

One practical consideration that often gets overlooked: encryption and access control need to work together. NIST SP 800-111 specifically notes that systems should return data to its encrypted state automatically, meaning authenticated sessions should time out after inactivity, not stay open indefinitely.

Data in transit

For ePHI moving across any network, internal or external, TLS 1.2 is the minimum, while TLS 1.3 is the current standard. TLS 1.3 removes outdated cipher suites and reduces the risk of downgrade attacks, making it meaningfully more secure than its predecessor.

One distinction worth understanding clearly is that TLS encrypts the communication channel, not the message content itself. For email specifically, that means TLS protects the connection between mail servers, but if a message is intercepted or accessed at rest on an intermediary server, the content may still be readable. For higher-sensitivity communications, S/MIME or PGP encryption addresses the content layer directly, though it adds complexity for both senders and recipients.

This is also why channels like WhatsApp fail HIPAA’s requirements despite offering end-to-end encryption. Encryption is only one of the technical safeguards required. Without user authentication, audit logs, and access controls, the channel being encrypted doesn’t make the platform compliant.

Key management — the part most organizations underestimate

Getting encryption right technically is only half the job. How you manage the keys that control access to encrypted data is equally important, and far less commonly addressed in compliance programs.

If your encryption keys are poorly managed, compromised, or inaccessible, the encryption itself either fails to protect data or, worse, locks your own organization out of it. The Office of Civil Rights’ (OCR) enforcement investigations routinely surface inadequate key management as a contributing factor in breach incidents.

A key management program that holds up under scrutiny covers:

• Key generation and storage — Keys should be generated using FIPS-validated cryptographic modules. Hardware Security Modules (HSMs) are the gold standard for storing keys, as they keep keys isolated from the systems they protect, making it significantly harder for attackers who compromise a server to also access the keys needed to decrypt the data on it.
• Key rotation — Encryption keys shouldn’t be permanent. Rotating keys on a defined schedule and immediately following a suspected compromise, limits the window of exposure if a key is ever obtained by an unauthorized party. Your policy should specify rotation intervals and document when rotations occur.
• Access controls and custodianship — Not everyone in your IT or security team should have access to encryption keys. Define who holds key custodian roles, document those assignments, and apply the same least-privilege principles you’d apply to ePHI access itself.
• Revocation procedures — When a staff member with key access leaves, or when a device is lost or stolen, the affected keys need to be revoked and replaced immediately. This process should be written into your offboarding procedures, not handled ad hoc.
• Documentation — OCR expects to see written policies covering all of the above. Key management that exists in practice but isn’t documented is difficult to demonstrate during an audit or investigation.

The Breach Notification Safe Harbor: Why Encryption Is Your Best Insurance Policy

Most HIPAA compliance discussions treat encryption as a way to protect data. That’s true, but it undersells the argument. Properly implemented encryption also determines if a security incident becomes a reportable data breach in the first place, and that distinction carries enormous practical consequences.

Under the HIPAA Breach Notification Rule, not every unauthorized access to ePHI triggers a notification obligation. If the data involved was encrypted in accordance with NIST guidance and the encryption key was not compromised, the incident is classified as “secured”, and secured data is exempt from breach notification requirements entirely.

In plain terms: no notification to affected patients, no report to HHS, no entry on the Office for Civil Rights’ public breach database (commonly called the “Wall of Shame”), and no mandatory press release if the breach affected 500 or more individuals in a single state.

What the safe harbor actually requires

The exemption isn’t automatic. Two conditions have to be met simultaneously:

1. The encryption must meet NIST standards — Data encrypted with FIPS 140-2 validated cryptography, i.e., following SP 800-111 for data at rest and SP 800-52 for data in transit, qualifies as secured. Data encrypted with weaker or non-validated methods does not, regardless of how it’s described in your policies.

2. The encryption key must not have been accessed or disclosed — If attackers obtained both the encrypted data and the key needed to decrypt it, the safe harbor doesn’t apply. This is why key management isn’t a secondary concern. It’s directly tied to whether you can invoke the exemption when you need it most.

If both conditions are met, the incident doesn’t meet the definition of a breach under HIPAA, and notification obligations don’t apply.

What’s actually at stake

The financial and operational consequences of a reportable breach extend well beyond the immediate incident. Organizations facing a notifiable breach must:

• Notify each affected individual within 60 days of discovering the breach
• Report to HHS, and for breaches affecting 500 or more individuals, do so immediately rather than in the annual summary
• For breaches affecting 500 or more residents of a state or jurisdiction, notify prominent media outlets in that area
• Cooperate with any subsequent OCR investigation, which may result in civil monetary penalties and a corrective action plan

Civil penalties for HIPAA violations reach up to $2,190,294 per violation category per year at the highest tier of culpability. Beyond the financial exposure, the reputational damage of appearing on OCR’s public breach database, which is permanent and publicly searchable, is a cost that’s harder to quantify but equally real.

The enforcement record makes the case

The 2017 Children’s Medical Center of Dallas settlement illustrates both sides of this equation.

The organization was fined $3.2 million after an unencrypted BlackBerry device and an unencrypted laptop were stolen, incidents that occurred years apart, and both of which had to be reported precisely because the data wasn’t encrypted. OCR’s investigation found that the organization had been warned about the encryption gap and failed to act on it.

If both devices had been encrypted to NIST standards, neither incident would have qualified as a reportable breach — no safe harbor analysis, no enforcement exposure, and no public filing.

That’s the practical case for encryption. Not just compliance, but the ability to contain an incident before it becomes a public, regulated event.

Encryption and the Archiving Obligation: The Requirement Most Organizations Overlook

Encryption is often thought of as a transmission problem, something you apply when data is moving and relax when it arrives safely at its destination. The HIPAA Security Rule doesn’t see it that way.

The obligation to protect ePHI applies for as long as that data exists in your systems, which means it extends directly into your archive.

This is where a lot of otherwise well-structured compliance programs have a gap.

The 6-year retention requirement

HIPAA requires covered entities to retain documentation related to their HIPAA compliance, including policies, procedures, and communications containing ePHI, for a minimum of six years from the date of creation or last effective use. Many states impose longer retention periods on top of that.

Six years is a long time for data to sit in a system, and the protections that applied when that data first arrived don’t expire while it waits. Encryption at rest isn’t a one-time implementation task but an ongoing obligation that covers the full retention lifecycle of every piece of ePHI your organization stores.

What the archive environment actually needs to be compliant

An email archive that meets HIPAA’s technical safeguard requirements can’t be treated as a simple storage container.

Four things need to be in place:

• Encryption — Archived ePHI must be encrypted at rest and in transit to the same standards that apply to live data, continuously, not just at the point of ingestion.
• Access controls — Not everyone in your organization should be able to search and retrieve archived communications containing ePHI. A compliant archive enforces role-based permissions, defining who can access what, under what circumstances, and restricts export and deletion rights accordingly.
• Audit trails — HIPAA requires that you be able to demonstrate who accessed ePHI, when, and what they did with it. Your archive needs to maintain detailed, tamper-evident logs of every search, view, export, and administrative action. During an OCR audit or an ediscovery request, these logs are often the first thing investigators ask for.
• Integrity controls — Archived data needs to be stored in a way that prevents unauthorized alteration or deletion. Immutable storage, where records can’t be modified or purged before their retention period expires, is the standard approach. This matters both for compliance and for legal defensibility: if archived communications are ever produced in litigation, their integrity needs to be demonstrable.

Backup is not the same as archiving

This distinction comes up often enough to be worth stating directly. A backup is a snapshot of your data at a point in time, designed to restore your systems after a failure or incident. It isn’t indexed, it isn’t searchable, and it isn’t designed to produce specific records on demand.

A data archive captures communications as they occur, indexes them for search, retains them according to configurable policies, and produces a documented chain of custody for anything retrieved from it. For HIPAA compliance purposes, and for responding to OCR audit requests or legal holds, backup alone doesn’t meet the requirement.

Your archiving vendor is a Business Associate

One compliance detail that gets missed more often than it should: any vendor that stores, processes, or transmits ePHI on your behalf, including your email archiving provider, is a Business Associate under HIPAA. That means a signed Business Associate Agreement (BAA) is required before they touch your data.

BAA isn’t just a formality. It defines each party’s responsibilities for protecting ePHI, establishes what happens in the event of a breach, and creates a documented accountability structure that OCR expects to see.

Without a signed BAA, even a perfectly encrypted archive leaves you exposed.

The practical checklist for evaluating if your archiving solution meets HIPAA’s encryption and technical safeguard requirements:

• AES-256 encryption at rest, TLS 1.3 in transit
  Role-based access controls with granular permission levels
  Immutable storage that prevents modification or early deletion
• Full audit trails covering search, access, export, and administrative actions
• Signed BAA with the vendor
• Configurable retention policies that meet HIPAA’s 6-year minimum and any applicable state requirements
• Legal hold capability for litigation preservation

For healthcare organizations looking for a dedicated solution, Jatheon is built specifically for regulated industries where these requirements aren’t optional extras.

Archived data is data encrypted at rest and in transit, stored immutably, governed by role-based permissions, and covered by a tamper-evident audit trail, giving compliance and legal teams the documentation they need for OCR audits, ediscovery requests, and breach notification safe harbor analysis. A Business Associate Agreement is included as standard.

Who Needs to Comply: Covered Entities, Business Associates, and Everyone in Between

HIPAA’s encryption requirements extend further than many organizations expect. The three categories of covered entities:

• Healthcare providers,
• Health plans, and
• Healthcare clearinghouses.

These are the obvious starting points, but the obligation doesn’t stop there.

Any third party that performs functions or services on behalf of a covered entity involving access to ePHI is a Business Associate under HIPAA and is directly subject to the Security Rule’s requirements.

That includes:

• Email and communications archiving providers,
• Cloud storage and hosting providers,
• EHR and practice management vendors, billing and coding companies,
• IT managed service providers, and
• Legal firms with access to patient records.

The obligation flows downstream too, so if a Business Associate engages a subcontractor that handles ePHI in any capacity, that subcontractor is bound by the same requirements.

One point worth flagging for cloud and SaaS vendors: a Cloud Service Provider is considered a Business Associate even if it holds no decryption keys and can’t read the data it stores. The definition is based on the relationship, not on whether the provider can access the content.

If ePHI passes through your systems in any form, the Security Rule’s requirements follow it.

What’s Changing: The 2024 Proposed Rule and What It Means for Encryption

The HIPAA Security Rule hasn’t been substantially updated since 2013. In December 2024, the Department of Health and Human Services moved to change that, publishing a Notice of Proposed Rulemaking (NPRM) that would represent the most significant overhaul of the Security Rule in over a decade.

The single largest proposed change is the elimination of the “required” versus “addressable” distinction entirely. Under the proposed rule, encryption would no longer be addressable but unconditionally mandatory, with no documented alternative pathway.

Other notable proposals include:

• Mandatory multi-factor authentication for all ePHI access
• A 72-hour window to notify HHS following a security incident
• Annual penetration testing and vulnerability scans every six months
• Enhanced documentation requirements across administrative, physical, and technical safeguards

The comment period closed in March 2025 with nearly 5,000 responses submitted.

The rule’s path forward, however, is genuinely uncertain. Shortly after the NPRM was published, the incoming Trump administration issued a regulatory freeze pending review, leaving the proposed changes in a holding pattern with no confirmed timeline for finalization. HHS estimates first-year compliance costs at approximately $9.3 billion if the rule proceeds as written.

What to do in the meantime

The uncertainty around the final rule doesn’t change the practical recommendation.

OCR’s enforcement posture already treats encryption as effectively mandatory, and the proposed rule signals clearly where the regulatory floor is heading.

Organizations that get this right now won’t need to scramble once the final rule lands, whenever that happens.

A Practical HIPAA Encryption Checklist

Encryption compliance is a set of interconnected controls that need to be implemented, documented, and maintained over time, and not a single decision.

The checklist below covers the core HIPAA compliance encryption requirements across the full scope of what the Security Rule expects

Summary of the Main Points

• HIPAA labels encryption “addressable,” not “required,” but that distinction is narrower than it sounds. Organizations that choose not to encrypt must document an equally effective alternative, a threshold very few can credibly meet.
• Encryption requirements apply to ePHI at rest and in transit, governed by NIST SP 800-111 and SP 800-52, respectively. AES-256 and TLS 1.3 are the accepted standards.
• Properly implemented encryption triggers a breach notification safe harbor: if ePHI is encrypted to NIST standards and the key is not compromised, the incident is not a reportable breach under the HIPAA Breach Notification Rule
• The encryption obligation doesn’t end at transmission. Archived ePHI must remain encrypted for the full six-year retention period, with access controls, audit trails, and immutable storage in place throughout.
• HIPAA’s scope extends beyond covered entities to Business Associates and their subcontractors, including cloud providers that store encrypted data but hold no decryption keys
• The December 2024 proposed Security Rule overhaul would eliminate the “addressable” classification entirely, making encryption unconditionally mandatory, though its final status remains uncertain following a regulatory freeze.

FAQ

The following questions come up often when organizations work through their HIPAA encryption requirements.

If a patient requests you communicate with them via unencrypted email, are you still required to encrypt?

Not in that specific exchange. HIPAA permits covered entities to send unencrypted email directly to patients if the patient has been informed of the risks and has explicitly requested it anyway. That exception applies only to the provider-patient communication itself — it doesn’t extend to internal systems, third-party vendors, or archived copies of those communications, which still need to meet the standard technical safeguards.

Does encryption apply to de-identified data?

No. Once data has been properly de-identified under HIPAA’s Safe Harbor or Expert Determination method, it no longer qualifies as ePHI and falls outside the Security Rule’s scope. The important word is “properly,” as partial de-identification doesn’t exist under HIPAA. All 18 identifiers must be removed, and the covered entity must have no actual knowledge that the remaining data could re-identify an individual.

What happens if we lose our encryption keys?

You lose access to the data they protect, permanently, in most cases. This is why key management and backup procedures for the keys themselves are as important as the encryption implementation. If keys are lost and ePHI becomes inaccessible as a result, you may also face a separate compliance problem: HIPAA requires that ePHI remain available to authorized users as needed for treatment, operations, and audit purposes. Inaccessible data due to key loss can constitute a violation of the availability requirement under the Security Rule.

Do BYOD policies affect our encryption obligations?

Yes. If personal devices are used to access, store, or transmit ePHI, even temporarily, those devices fall within the scope of the Security Rule’s technical safeguards. That means encryption requirements apply to the ePHI on those devices regardless of who owns the hardware. Organizations that allow BYOD need written policies governing how ePHI may be accessed on personal devices, and ideally, mobile device management (MDM) software that can enforce encryption and remotely wipe ePHI if a device is lost or an employee leaves.

Does encrypting the body of an email also cover the subject line?

Not automatically. Subject lines are often excluded from content-level encryption because they’re processed separately by mail servers. This is a practical risk because subject lines in healthcare contexts sometimes contain identifiable information like patient names or appointment details. S/MIME and some purpose-built HIPAA email encryption tools do encrypt subject lines, but it’s worth verifying explicitly with your vendor rather than assuming it’s covered.

How does the breach notification safe harbor interact with a ransomware attack?

This is an area where OCR has issued specific guidance. In a ransomware incident, ePHI is generally presumed to have been accessed or acquired by an unauthorized party, meaning the burden falls on the covered entity to demonstrate that the data was not compromised, not on OCR to prove that it was. If the affected data was encrypted prior to the attack and the encryption keys weren’t accessed, the safe harbor may still apply. If the ransomware itself encrypted previously unencrypted ePHI, that doesn’t satisfy the safe harbor, the encryption has to have been in place before the incident occurred.

About the Author

Natasa Djalovic

Natasa Djalovic is a Senior Content Writer at Jatheon, with 10+ years of experience in creating B2B and SaaS content, with a strong focus on compliance, archiving, and tech topics. Outside of work, she likes to collect and build LEGO sets, hang out with her cats, and watch documentaries.