Cybersecurity

HIPAA Encryption Requirements 2026: Addressable Is Dead

HIPAA encryption in 2026 — the addressable loophole is closing, AES-256 at rest, TLS 1.2+ in transit, and what to deploy while the Final Rule is still pending.

Douglyn July 10, 2026 11 min read

Large glowing padlock icon superimposed over a matrix of encrypted data streams flowing from a medical/EHR system silhouette to a distant secure cloud silhouette

Current HIPAA law lets you skip encryption. Not in words, but in effect. The Security Rule’s encryption provisions are “addressable” — meaning you can deploy them, or document why you didn’t and what you did instead. That documentation path was designed as flexibility for 2003-era operators without practical encryption options. In 2026 it’s an operational loophole that hundreds of practices are relying on and thousands more haven’t examined closely.

The proposed 2026 HIPAA Security Rule Final Rule closes that loophole. Encryption becomes required rather than addressable. AES-256 for data at rest, TLS 1.2+ for data in transit, no documentation path out. The rule remains proposed as of mid-2026 — the spring 2026 publication target came and went, roughly 4,700 public comments are still under review, and industry pressure to modify or withdraw the proposal is significant. But every downstream signal — cyber insurance carrier expectations, customer due diligence questionnaires, third-party assessor bars — is moving toward the mandatory-encryption posture whether or not the Final Rule publishes on the original timeline.

This is the deeper read on HIPAA encryption for mid-size practices in 2026 — what current law requires, what the proposed rule would add, the four scopes where encryption actually needs to be deployed, the deployment patterns that work in practice, and the discipline that gets you audit-ready even before the Final Rule publishes. It pairs with our HIPAA audit preparation 90-day checklist (sibling spoke #1), the HIPAA BAA requirements playbook (sibling spoke #2), and the 2026 HIPAA Security Rule updates for Florida practices cluster hub.

Key Takeaways

The “addressable” documentation path is going away under the proposed Final Rule. Encryption becomes required, not optional-with-documentation.
AES-256 at rest, TLS 1.2+ in transit are the technical minimums the proposed rule specifies. AES-128 is still acceptable under current law; upgrade on refresh cycles.
Encryption operates across four scopes: data at rest, in transit, backups + portable devices, and email. Full-disk encryption (BitLocker, FileVault) covers only one of the four.
Business associate encryption is your encryption. The BAA and the BA’s technical safeguards discipline determine whether your covered PHI is actually encrypted.
The audit-ready pattern is: encryption everywhere it belongs, documented in the SRA, verified with the BA, and tested in the incident response runbook. The Final Rule uncertainty doesn’t change this discipline; it just clarifies the timeline.

The Regulatory Reality — Where Encryption Stands in Mid-2026

Understanding the current state matters because operators keep asking whether the encryption changes everyone is talking about are in force.

Current enforceable law. The 2013 HIPAA Omnibus Rule’s Security Rule provisions remain the enforcement baseline. Encryption at rest and encryption in transit are both classified as “addressable” — meaning covered entities and business associates can implement them, or document why they’ve implemented an equivalent alternative. The addressable-vs-required distinction has always been narrower than operators assume: OCR has consistently interpreted “addressable” to mean “if it’s reasonable and appropriate for your organization, you must implement it,” not “optional.” But the documentation path has existed and been used.

The January 2025 NPRM. The Notice of Proposed Rulemaking published January 6, 2025 proposes eliminating the “addressable” designation entirely for most Security Rule safeguards including encryption. Under the proposed rule: encryption is required for all ePHI at rest and in transit, with limited documented exceptions requiring equivalent alternative measures. AES-256 is specifically named as the standard for data at rest, TLS 1.2 or higher for data in transit. Once the Final Rule publishes, covered entities and business associates get 180-240 days to comply.

Status as of mid-2026. The spring 2026 publication window that HHS had signaled came and went. Approximately 4,700 public comments are still under review. A coalition of 100+ hospital and provider groups has publicly asked HHS to withdraw the proposal, citing implementation cost and operational burden — including specific concerns about encryption cost for smaller practices. Industry analysts still expect 2026 publication, but the specific timing is uncertain and the possibility of withdrawal or material modification remains real.

What operators should assume. Every downstream signal — cyber insurance carrier expectations, healthcare enterprise customer due diligence, third-party assessor bars, state healthcare privacy laws — is moving toward mandatory encryption whether or not the Final Rule publishes on schedule. Practices that deploy encryption to the proposed-rule standard now will absorb the effort naturally. Practices that wait until the Final Rule publishes will be scrambling in a compressed 180-day window.

The Four Encryption Scopes

Encryption in HIPAA-relevant contexts operates across four scopes. A comprehensive posture addresses all four; a partial posture (only full-disk encryption, for example) has meaningful gaps.

1. Data at rest

PHI stored on any medium — production databases in EHR/PM/billing systems, backup archives, file shares, cloud storage, individual workstations and laptops, portable devices (external drives, USB keys, medical imaging archive drives), phones and tablets with any PHI cache.

Deployment patterns. Full-disk encryption on every workstation and laptop (BitLocker on Windows, FileVault on Mac). Database encryption enabled on the EHR/PM production system (usually a configuration your EHR vendor manages). Cloud storage encryption enabled by default in AWS/Azure/GCP HIPAA-eligible services. Portable device encryption enforced through device management (Intune, Jamf).

Common gaps. Legacy servers with unencrypted databases. Personal laptops used for after-hours work. Portable backup drives without encryption. USB keys with PHI in the finance director’s desk.

2. Data in transit

PHI moving across networks — between client applications and the EHR server, between the practice and cloud services, in HL7 interfaces to lab systems, in DICOM connections to imaging systems, in integrations with payer clearinghouses, in patient portal traffic, in remote-worker VPN traffic.

Deployment patterns. TLS 1.2 minimum (1.3 preferred) enforced on every network transmission. Web-facing systems using proper certificate management (not self-signed, not expired). HL7 and DICOM connections tunneled through TLS or VPN. Remote worker VPN using modern encryption standards (IKEv2 or WireGuard preferred over legacy PPTP or L2TP).

Common gaps. Internal-network traffic between application servers left unencrypted because “it’s inside the firewall.” Legacy HL7 connections running plaintext because the vendor doesn’t offer TLS. Self-signed certificates on internal web applications that browsers ignore.

3. Backups and portable devices

Backup infrastructure, media, and portable devices deserve their own scope because the failure modes are distinct — backup infrastructure gets targeted specifically by ransomware, and portable devices are the highest-volume lost-device-incident category.

Deployment patterns. Backup destinations with encryption at rest enabled (AWS S3 with SSE-KMS, Azure Blob with encryption, dedicated backup vendors with documented encryption). Backup data encrypted in transit to the destination. Portable devices (external drives, backup tapes if still used) with hardware or software encryption. Air-gapped or immutable backups for ransomware defense. Regular backup restoration testing to verify encrypted backups actually decrypt.

Common gaps. Backups stored on the same infrastructure as production (ransomware takes both). Encrypted backups where the encryption keys are stored with the backups (encryption without key separation is theatrical). Portable backup drives with no encryption. Retention policies that let encrypted PHI backups accumulate forever.

4. Email and clinical communication

PHI transmitted via email or clinical messaging platforms.

Deployment patterns. Enterprise email encryption on Microsoft 365 (Purview Message Encryption) or Google Workspace (S/MIME) for clinical communication involving PHI. Dedicated healthcare email encryption gateway (Paubox, Virtru, Zix, ProofPoint) for higher volume or workflow needs. Secure clinical messaging platforms (TigerConnect, Klara, OhMD) for patient communication.

Common gaps. Clinicians emailing PHI from personal accounts. Patient communication over standard SMS. Automated appointment reminders sent through non-HIPAA-eligible platforms. Voicemail systems that transcribe clinical messages to unencrypted email.

The Business Associate Encryption Gap

Your encryption is only as strong as the encryption your business associates deploy. When your EHR vendor stores PHI on their servers, their encryption is your encryption. When your billing service processes patient data, their encryption is your encryption. When your cloud provider hosts your workloads, their encryption at rest and in transit is your encryption at that layer.

The BA verification pattern proposed under the 2026 NPRM would formalize this — requiring BAs to annually verify (in writing, by a subject-matter expert) that they’ve deployed the required technical safeguards. Even before the Final Rule publishes, the discipline is worth adopting.

Practical BA encryption verification: request SOC 2 Type II reports (which document encryption at the control level). Request HITRUST certification if the BA has it. For high-risk BAs (EHR, cloud providers, large-volume claims processors), request annual written attestation from the BA’s security officer specifically covering encryption at rest, in transit, and in backups. For BAs that push back on providing documentation, see the BAA playbook — this is diligence signal.

The 5 Encryption Gaps That Recur

Patterns in denied claims, breach forensic reports, and third-party HIPAA assessments:

Unencrypted backups. The most common — production data is encrypted but the backups aren’t, or use weaker encryption, or are stored without key separation.
Unencrypted portable devices. External drives, USB keys, laptops used off-hours. High-volume lost-device incident category.
Cleartext email. Clinical communication (referrals, lab results, patient follow-ups, insurance disputes) sent over standard email without encryption enforcement.
Self-signed or expired TLS on internal apps. Practice-internal web tools (schedulers, room management, minor internal reporting apps) that were stood up without proper certificate management. Browser TLS warnings get clicked through by staff.
Cloud storage without encryption enforced. SharePoint, Google Drive, Dropbox — the practice signed up for the enterprise tier that supports HIPAA-eligible use but didn’t actually enable the encryption controls or execute the cloud provider’s BAA.

Each of these is preventable. Each is what surfaces first when preparation was rushed or absent.

What to Do This Quarter Regardless of Final Rule Timing

The audit-defensible posture doesn’t wait for the Final Rule to publish.

This month:

Inventory encryption across the four scopes. Document what’s deployed where, and what’s not.
Identify the gaps that would be findings under either current addressable-with-documentation standards OR the proposed mandatory standards. Prioritize the gaps that fail both.
Update the Security Risk Analysis to reflect the current encryption posture.

This quarter:

Deploy encryption to close the top-priority gaps identified in the inventory. Target the recurring failure modes above.
Request encryption documentation from your top 5 highest-risk business associates (EHR, cloud provider, billing service, imaging archive, patient portal).
Update BAA templates for new business associate relationships to include annual verification language.
Test backup restoration end-to-end. Verify encrypted backups actually restore.

This year:

Complete a HIPAA-focused encryption audit (self-assessed or external). Document deployment across all four scopes for every system that touches PHI.
Update all business associate agreements at renewal to include current encryption expectations and annual verification requirements.
Build the encryption evidence collection into the annual Security Risk Analysis refresh cycle so it’s a recurring practice, not a one-time project.

What BASG Does for Healthcare Encryption Programs

BASG deploys encryption discipline as part of every healthcare engagement — as an MSP that serves as business associate to healthcare covered entities, we operate our own environment to the standards the Final Rule would formalize, and we help our clients close the gaps that surface in encryption inventories.

Our healthcare IT services engagements typically include an encryption audit across the four scopes as an early workstream — because the audit surfaces the gaps that would otherwise become findings in the next OCR interaction, third-party assessment, or cyber insurance renewal. Our cybersecurity services work builds the operational discipline around encryption — key management, certificate management, backup encryption testing, portable device policy enforcement, email encryption deployment. Our industry compliance engagements integrate encryption evidence into the broader HIPAA readiness posture we help clients maintain across audit prep, BAA governance, and Security Risk Analysis refresh.

If your practice hasn’t inventoried its encryption posture across the four scopes recently, or if the Final Rule uncertainty has surfaced the question of readiness, get in touch for a 30-minute encryption gap review. We’ll walk through the current state, identify the gaps most likely to become findings under either current or proposed standards, and propose a remediation path that doesn’t depend on Final Rule timing. The encryption discipline that satisfies OCR is the same discipline that reduces breach probability, keeps cyber insurance carriers underwriting favorably, and closes the gaps most audits find first. There’s no scenario where deploying it now is wasted work.

Frequently Asked Questions

Is AES-128 still acceptable under HIPAA in 2026?

AES-128 remains acceptable under current HIPAA guidance for most use cases. HHS and NIST have consistently accepted AES-128, AES-192, and AES-256 as compliant encryption strengths. The proposed 2026 Security Rule Final Rule calls out AES-256 specifically as the standard for data at rest, but AES-128 has not been explicitly deprecated. Practically, though, most HIPAA-focused security firms recommend AES-256 for new deployments. Three reasons: (1) The performance difference on modern hardware is negligible — CPU-level AES acceleration handles either transparently. (2) NIST's post-quantum-cryptography roadmap suggests that longer symmetric keys will remain viable longer as quantum computing matures. (3) Cyber insurance carriers, customer counterparties, and third-party assessors increasingly cite AES-256 as the baseline expectation. If you're deploying new encryption in 2026, use AES-256. If you have existing AES-128 deployments that are meeting HIPAA obligations, you don't need to upgrade before the Final Rule publishes — but plan for the transition on a normal refresh cycle.

Does BitLocker (Windows) or FileVault (Mac) satisfy the HIPAA encryption rule?

Yes for the specific scope they cover, no as a complete answer. BitLocker (Windows built-in full-disk encryption) and FileVault (macOS built-in) both use AES-128 or AES-256 encryption under the hood and are HIPAA-eligible when configured correctly. They cover the disk-at-rest scope — if someone steals a laptop, the disk contents are encrypted and inaccessible without the recovery key. What they do NOT cover: data-in-use (once the user logs in, the disk is decrypted for the session); data-in-transit (network traffic is separate); email encryption (email content flows through separately); backup encryption (unless the backup destination is also encrypted); or PHI in cloud services (managed separately by the cloud provider's encryption). Practical deployment for a mid-size practice: enable BitLocker (Business or Enterprise editions of Windows) on every workstation and laptop that touches PHI, enable FileVault on every Mac, enforce via device management (Microsoft Intune, Jamf), document the deployment in the Security Risk Analysis, and pair with encryption for the other scopes (in-transit, backups, cloud, email). Full-disk encryption is table stakes, not a comprehensive solution.

How do we encrypt PHI when our EHR vendor manages the database?

Your EHR vendor's encryption is your encryption for the PHI they store. The BAA and the vendor's HIPAA compliance posture are the artifacts that matter — you don't need to (and can't) deploy your own encryption on top of their managed database. Three specific things to verify with your EHR vendor: (1) Data at rest encryption is enabled on the production database and backup replicas, with a documented encryption algorithm (AES-256 preferred, AES-128 acceptable). (2) Data in transit is encrypted from client applications and integrations (TLS 1.2 minimum, 1.3 preferred) across all endpoints — not just the primary web UI, but also HL7 interfaces, DICOM connections, integration APIs. (3) Key management is documented — where are the encryption keys stored, who has access, how are keys rotated, what's the incident response if keys are compromised. Request their SOC 2 Type II report and the HITRUST attestation if available; both will document these controls in detail. The 2026 Final Rule NPRM would require business associates to annually verify their technical safeguards deployment in writing — encryption practices are a substantial portion of what would be verified. Ask your EHR vendor now what their verification process looks like; the mature vendors already do this.

What's the deal with encrypted email — do we need a specialized platform?

For clinical communication involving PHI, yes. Standard email (Gmail, Microsoft 365 without additional controls, Yahoo, most consumer platforms) does not meet HIPAA encryption requirements out of the box. The mechanism you need is called end-to-end email encryption or transport-layer encryption enforcement. Three practical approaches for mid-size practices: (1) Enable Microsoft 365 or Google Workspace's built-in enterprise email encryption — Microsoft Purview Message Encryption or Google Workspace S/MIME. These add encryption to messages containing PHI when properly configured. Requires Microsoft 365 Business Premium or Enterprise E3+, or Google Workspace Enterprise. (2) Deploy a dedicated healthcare-grade email encryption gateway (Paubox, Virtru, Zix, ProofPoint's healthcare offering). These add a layer of encryption enforcement on top of your existing email infrastructure and typically include DLP (data loss prevention) rules to auto-encrypt messages containing PHI patterns. (3) Use a secure clinical messaging platform (Klara, TigerConnect, OhMD) for patient communication instead of email entirely. Which is right depends on volume, workflow, and how much clinical communication currently happens over email. What you can't do: rely on standard email with a disclaimer that says 'this may contain PHI, please handle securely.' Disclaimers are not encryption.

What if a business associate refuses to provide encryption documentation?

This is a hard signal about the BA's HIPAA posture and should be treated as a diligence red flag. Under current HIPAA, business associates must protect PHI in accordance with the Security Rule, but there's no specific obligation to prove it to covered entities. Under the 2026 Final Rule NPRM, BAs would be required to annually verify their technical safeguards deployment in writing — which would formalize the encryption documentation expectation. Even before the Final Rule publishes, refusing to provide encryption documentation signals one of three things: (1) The BA doesn't actually have proper encryption deployed and knows it. (2) The BA has encryption but hasn't documented it in a form that could be shared with clients. (3) The BA has documented encryption but is using contract friction as a negotiation tactic. In all three cases, escalate. Ask for their SOC 2 Type II report (which will document encryption at some level). Ask for their HITRUST certification if they have one. Ask for a written attestation from their security officer. If they still refuse, evaluate whether the BA relationship is worth the compliance risk — see our [BAA requirements playbook](/blog/hipaa-business-associate-agreement-requirements-2026/) for the broader vendor-diligence framework. HIPAA-eligible BAs know they need to demonstrate encryption; ones that push back on the question typically aren't equipped to serve healthcare clients.

Do we need to encrypt backups even if they're stored with a HIPAA-compliant cloud provider?

Yes, and the encryption obligation runs in both directions. The HIPAA-compliant cloud provider (AWS, Azure, Google Cloud, dedicated healthcare cloud vendors) will typically encrypt data at rest on their infrastructure by default — that's part of what makes them HIPAA-eligible. But their default encryption doesn't remove your obligation to think about the backup lifecycle: (1) The data in transit to the backup destination should be encrypted (TLS 1.2+). Verify this is enabled, not just available. (2) The backup destination's encryption keys — who controls them. If the cloud provider controls the keys, they can (theoretically or legally) access your data. If you control the keys (customer-managed encryption keys, CMK/BYOK), you have stronger control. For high-sensitivity PHI, CMK is worth the operational overhead. (3) Backup retention and destruction. Encrypted backups that live forever aren't compliant — you need a retention policy and secure destruction (crypto-shredding of the encryption key is a common pattern). (4) Backup restoration testing. Do you actually know your encrypted backups can be restored? The proposed 2026 Final Rule includes 72-hour restoration capability; encryption that prevents restoration is a bigger problem than no encryption. Test quarterly. (5) Backup separation from production. Backups that share infrastructure with production give ransomware attackers a way to encrypt both — segregated backup infrastructure is the ransomware-defense pattern.

Tags: hipaa encryption requirements 2026 hipaa encryption mandatory aes-256 hipaa hipaa encryption at rest hipaa email encryption tls 1.2 hipaa hipaa 2026 security rule

Back to Blog