HIPAA Encryption Rule Explained: What the Security Rule Actually Requires

HIPAA Security Rule Overview

The HIPAA Security Rule sets national standards for safeguarding electronic protected health information (ePHI). It applies to covered entities and their business associates, requiring a risk-based program that is flexible enough to fit organizations of different sizes and technical environments.

The Rule organizes safeguards into administrative, physical, and technical safeguards. Administrative safeguards include risk analysis, policies, workforce training, and vendor oversight. Technical safeguards cover access control, audit controls, integrity, person or entity authentication, and transmission security. Encryption sits within the technical safeguards and is assessed through your risk analysis.

Why encryption matters

Encryption reduces the likelihood that unauthorized access results in a reportable incident. Properly implemented encryption also interacts with breach notification requirements by potentially qualifying an incident for “safe harbor” if keys remain uncompromised.

Encryption Requirement Status

Under the Security Rule, encryption is an addressable implementation specification for data at rest and for transmission security. Addressable does not mean optional. You must evaluate whether encryption is reasonable and appropriate in your environment; if it is, implement it. If not, you must document your rationale and adopt an effective, equivalent alternative that mitigates the identified risks.

In practice, regulators expect encryption in most scenarios that involve portable devices, external transmissions, cloud storage, backups, and any context where ePHI could be exposed beyond a tightly controlled environment. Consistent decisions, documentation, and monitoring are essential to demonstrate compliance.

How to show due diligence

• Perform a current risk analysis that maps where ePHI is created, stored, transmitted, and received.
• Decide for each location and data flow whether encryption is reasonable and appropriate, and implement accordingly.
• If you choose a compensating control, document why it provides equivalent protection and review it periodically.
• Test, monitor, and keep records that your controls work as intended.

Proposed Changes to Encryption Standards

As of November 7, 2025, no final federal amendment has converted encryption from addressable to required across the board. However, federal initiatives and sector guidance continue to encourage stronger defaults and clearer minimums to keep pace with modern threats.

Commonly discussed proposals and trends include: aligning references to current NIST publications, emphasizing FIPS 140-3 validated cryptographic modules, retiring legacy protocols and ciphers, and promoting the TLS 1.3 protocol as a baseline for data in transit. Organizations are also increasingly standardizing on AES-256 encryption for data at rest and adopting cryptographic agility to simplify future upgrades.

What this means for you

Even without a new mandate, you should plan lifecycle upgrades that deprecate outdated algorithms and protocols, set organization-wide encryption baselines, and ensure vendors meet those baselines under your business associate agreements.

Scope of Encryption Requirement

Data at rest

• Endpoints and mobile devices: full-disk encryption for laptops, tablets, and smartphones; encrypted removable media or strict media controls.
• Servers and databases: storage-level or file/database-level encryption (including TDE), plus backup encryption for snapshots and archives.
• Cloud storage and SaaS: provider-native encryption with strong key management or customer-managed keys where feasible.

Data in transit

• External networks: enforce HTTPS using the TLS 1.3 protocol for portals, APIs, and web apps; use strong ciphers and perfect forward secrecy.
• Email and messaging: TLS for transport; consider S/MIME or PGP for end-to-end protection when sensitivity or risk is high.
• File transfer and integrations: secure protocols (e.g., SFTP, mTLS APIs) and VPNs where appropriate.

Cloud, vendors, and third parties

• Business associates must protect ePHI to the same standard; require encryption commitments in contracts and verify through due diligence.
• Ensure encryption extends to logs, telemetry, backups, and disaster recovery sites that may contain ePHI.

Keys and secrets

• Protect keys in secure modules (prefer FIPS 140-3 validated hardware or managed HSM services).
• Separate duties for key custodians, rotate keys, and enforce strong passphrases and MFA on key-access workflows.

Exceptions to Encryption Requirement

You may conclude encryption is not reasonable and appropriate for a particular use case, but only after a documented risk analysis and consideration of alternatives. In such cases, you must implement compensating controls that provide equivalent protection and review them periodically.

Examples of narrowly tailored exceptions

• Highly restricted, segmented systems with no ePHI egress and robust physical, administrative safeguards, and monitoring.
• Legacy integrations where encryption is technically infeasible in the short term, mitigated by network isolation, strict access controls, and accelerated remediation plans.

Be cautious: declining encryption increases exposure and may remove the possibility of safe harbor in the event of a breach. Exceptions should be rare, well justified, and time-limited.

Encryption Standards and Protocols

Recommended baselines

• Data at rest: AES-256 encryption for disks, databases, backups, and object storage.
• Data in transit: TLS 1.3 protocol with modern cipher suites; allow TLS 1.2 only where necessary and with strong ciphers.
• Email: TLS for transport; S/MIME with strong keys for messages containing extensive ePHI.
• Mobile and endpoints: native full-disk encryption, secure boot, and remote wipe.

Implementation tips

• Disable deprecated protocols and ciphers (e.g., SSL/TLS 1.0/1.1, RC4, 3DES, MD5, SHA-1).
• Use cryptographic modules validated to FIPS 140-3 where feasible and align configurations with current NIST guidance.
• Document key management: generation, storage, rotation, recovery, and destruction.
• Continuously validate configurations with automated scanning and remediate drift promptly.

Compliance and Enforcement

OCR evaluates whether your program reasonably reduced risks to ePHI. Expect scrutiny of your risk analysis, encryption decisions, policies, workforce training, vendor management, and technical evidence that controls are working. Consistency between what policies say and what systems do is essential.

Encryption directly affects breach notification requirements. If ePHI is properly encrypted and the keys are not compromised, the data is generally not considered “unsecured,” and notification may not be required. If unencrypted ePHI is exposed—or if keys are accessed—you should presume a breach and perform the required risk assessment and notifications.

Operational checklist

• Map ePHI data flows and update your risk analysis at least annually or upon significant change.
• Set enterprise encryption baselines and enforce them across assets and vendors.
• Test restorations of encrypted backups and verify key recovery procedures.
• Monitor for protocol/cipher regressions and remediate quickly.
• Maintain evidence that recognized security practices are in place over time.

Conclusion

The Security Rule makes encryption an addressable implementation specification, but a modern risk analysis will lead most organizations to encrypt ePHI at rest and in transit. Adopting strong, validated cryptography, managing keys carefully, and documenting decisions not only harden your environment but can also reduce regulatory exposure during incidents.

FAQs.

What does the HIPAA Security Rule require for encryption?

It requires you to evaluate encryption as an addressable implementation specification for ePHI at rest and in transit. If encryption is reasonable and appropriate, you must implement it. If not, you must document why and implement an effective, equivalent alternative that mitigates the same risks.

How do the proposed changes affect encryption requirements?

No finalized rule has made encryption universally mandatory as of November 7, 2025. Ongoing efforts and sector guidance encourage stronger, clearer minimums—such as preferring TLS 1.3, using AES-256 encryption for data at rest, and relying on FIPS 140-3 validated modules—so you should plan upgrades accordingly.

What are the exceptions to the HIPAA encryption mandate?

HIPAA does not impose a blanket mandate; encryption is addressable. An exception exists only when a documented risk analysis shows encryption is not reasonable and appropriate for a specific use case, and when compensating controls provide equivalent protection. Such exceptions should be rare and time-bound.

How does encryption impact breach notification under HIPAA?

Properly encrypted ePHI, with uncompromised keys, is generally not considered “unsecured,” which can eliminate breach notification obligations. If ePHI is unencrypted or if encryption keys are accessed, you must assess the incident and follow HIPAA’s breach notification requirements.