From Addressable to Mandatory: Email Encryption Under the New HIPAA Security Rule
How to evaluate, prepare, and comply with the new HIPAA Security Rule before the clock runs out. A practical guide for healthcare IT and compliance leaders.
Key Takeaways
Why email is healthcare's most exposed compliance gap
Email remains the number one attack vector in healthcare — and one of the least-controlled channels through which electronic protected health information (ePHI) flows. Now, the proposed HIPAA Security Rule update is set to change that permanently. For the first time in more than two decades, email encryption will be mandatory — not a best practice organizations can document their way around. With the average cost of a healthcare data breach reaching nearly $11 million and penalties reaching as high as $16 million in a single case, the cost of inaction has never been higher.
The proposed HIPAA Security Rule update will make email encryption mandatory, not vaguely addressable. For IT directors, CISOs, and compliance officers at healthcare providers, payers, and suppliers, the question is no longer whether to act. It's whether to act now or scramble later.
This guide gives you a clear, authoritative, actionable path — from evaluating your current setup to building an enforcement-ready email environment to keeping patient email data safe at all times.
What is actually changing — and why it matters now
On January 6, 2025, the HHS Office for Civil Rights published a Notice of Proposed Rulemaking — the first significant update to the HIPAA Security Rule since 2003. The proposed changes reflect a fundamental shift: from documenting intent to proving technical enforcement.
The single biggest change: elimination of the "addressable" standard
Under the current rule, encryption of ePHI in transit and at rest has always been "addressable" — meaning organizations could document why encryption wasn't reasonable or appropriate and implement an alternative. Many organizations used this flexibility to avoid encryption altogether. Under the proposed rule, that door closes permanently. The new HIPAA email encryption requirements leave no room for documentation workarounds — encryption must be implemented, verifiable, and technically enforced.
The regulatory timeline
OCR's regulatory agenda targeted May 2026 for final rule publication — a deadline that has now passed without a Federal Register publication. OCR has not indicated the rule will be withdrawn, though the timing and final form remain uncertain. What is not uncertain is OCR's enforcement posture under the existing rule.
✕ May 2026 OCR target passed without Federal Register publication · Timeline based on standard federal rulemaking procedure
Even if the final rule is delayed or scaled back, OCR is actively enforcing the current Security Rule. The agency levied $7.42 million in fines in 2025 and has formally expanded its enforcement initiative to include risk management — not just risk analysis.
What mandatory email encryption requires
Compliance with the proposed rule isn't just a policy exercise — it requires specific, verifiable technical controls. Here's a breakdown of every HIPAA encryption requirement your email infrastructure must meet under the new HIPAA Security Rule.
Encryption in transit: TLS 1.2 is the minimum standard
TLS 1.2 is the minimum; TLS 1.3 is preferred. Critically, TLS must be enforced on all connectors — not just available as an option. Opportunistic TLS, which falls back to unencrypted delivery when a receiving server doesn't support it, does not meet the standard. When a recipient server cannot accept TLS, organizations need an alternative delivery mechanism such as portal-based encrypted delivery.
LuxSci enforces TLS 1.2 and TLS 1.3 on all inbound and outbound email connectors, not as an option, but as a default. Legacy protocols are disabled, ensuring no message slips through on an insecure connection.
Encryption at rest: AES-256 across all storage
AES-256 is the required standard for all stored email, attachments, and backups. This applies not just to mail servers, but to cloud email storage, archiving systems, and any mobile devices that cache email containing ePHI. Most default cloud email configurations — including Microsoft 365 and Google Workspace — provide some level of at-rest encryption, but not all configurations meet AES-256, and key management practices vary significantly.
LuxSci's SecureLine encrypts email at rest when using Escrow, PGP, or S/MIME modes, ensuring ePHI stored in LuxSci's secure database is protected. Unlike standard cloud email platforms where at-rest encryption requires significant additional configuration, SecureLine handles it automatically within these modes.
Why MFA Is Now a Non-Negotiable for Email Accessing ePHI
Highly relevant since MFA moves from addressable to mandatory under the proposed rule. Organizations must enforce authenticator-based MFA across all accounts, including shared and service accounts that are frequently overlooked, and maintain documented evidence of enforcement for OCR review.
LuxSci supports enforcement of multi-factor authentication across all email accounts, including shared and service accounts that are frequently overlooked. MFA enforcement is configurable at the organizational level, ensuring no account accessing ePHI is left unprotected.
Always-on encryption vs. DLP-dependent approaches
Traditional DLP-based encryption relies on scanning outbound email for ePHI patterns and triggering encryption on a match, but keywords get misspelled, PHI in attachments goes undetected, and staff forget to click encrypt. One missed match is a potential breach. The stronger approach is always-on encryption, where every outbound email is encrypted automatically, no filters, no toggles, no staff decisions.
LuxSci's SecureLine automatically encrypts every outbound email — no keywords, no toggles, no staff decisions required. For highly sensitive messages, additional encryption methods such as S/MIME, PGP, or secure portal delivery are triggered automatically based on recipient capabilities.
Inbound email — the overlooked obligation
HIPAA compliance applies to ePHI you receive, not just what you send. Under HIPAA, covered entities and business associates are responsible for protecting ePHI they create, receive, maintain, or transmit. Organizations should take steps to ensure emails containing ePHI are received over encrypted connections, such as enforcing TLS where possible. Once received, that ePHI must be encrypted at rest on your servers and protected with appropriate access controls, monitoring, and audit logging as part of your overall HIPAA compliance and security program.
LuxSci uses TLS on inbound email connections wherever the sending server supports it, reducing the risk of ePHI arriving unencrypted. For complete at-rest protection of received messages, SecureLine's Escrow, PGP, or S/MIME modes ensure inbound ePHI is encrypted on arrival and stored securely — not left in plain text in the inbox.
"We use Microsoft 365 / Google Workspace — we're covered." A BAA with a major cloud provider covers their infrastructure. It does not automatically configure encryption enforcement, disable legacy TLS protocols, or enforce always-on email encryption. You own the configuration. You own the compliance.
How to evaluate your email vendor for HIPAA email compliance
A signed BAA is no longer sufficient for adequate email security. The proposed rule introduces an annual written verification requirement — covered entities must confirm that their vendors have actually implemented the required technical safeguards, not just signed a document agreeing to do so.
Use the interactive scorecard below to evaluate your current email vendor across the seven dimensions of HIPAA compliance and email security.
Patient-requested unencrypted email — what it covers
A common source of false confidence is the belief that if a patient requests communication via their personal unencrypted email, the organization's encryption obligations are waived. This reflects a misunderstanding of how the Privacy Rule and Security Rule interact.
Under the HIPAA Privacy Rule, if a patient provides an email address or initiates communication by email, consent is implied. However, the Security Rule governs how the organization must protect ePHI on its own infrastructure. A patient's choice of communication channel does not relieve the organization of its obligation to apply HIPAA email encryption on its own systems before transmission.
Encrypt on your end. Deliver in a way the patient can access — whether a standard encrypted message they can open, or in those rare cases a secure portal when needed. The opt-out addresses the patient's channel preference. Your infrastructure obligation remains unchanged. Document all patient communication preferences.
From assessment to enforcement-ready —
6-step HIPAA email encryption roadmap
The organizations that emerge strongest from this transition are the ones moving now — before a final rule is published and the compliance clock starts. Here is the roadmap.
Inventory all email systems. Identify every workflow where ePHI is transmitted. Map your gaps against the proposed rule requirements. This is your baseline.
Apply the 7-dimension framework from Section 3. Identify gaps in your current vendor's capabilities. Determine if they can close them — or if replacement is required.
Enforce TLS 1.2+ on all connectors. Deploy HITRUST-certified, HIPAA compliant email solution. Enforce MFA. Encrypt stored email. Configure key management.
Remove 'addressable' language from all policies. Update BAAs. Document encryption standards in your risk assessment. Update data flow maps.
Ensure staff understand new requirements. Make encrypted email frictionless enough that workarounds don't emerge. Document all training for OCR records.
Penetration testing. Vulnerability scanning. Tabletop exercises. Final compliance gap assessment. Establish quarterly review cadence going forward. Obtain vendor confirmation that required safeguards are implemented.
Organizations that begin now have runway. Those that wait until after the final rule is published will face a compressed 180-day deadline — often impossible to meet without emergency spending, rushed implementations, and external consultants at premium rates.
What “enforcement-ready” HIPAA email encryption looks like
In this new world, OCR doesn't just want to see your policies. They want your logs, your test results, your vendor agreements, and your training records. Documentation of intent is no longer sufficient. Here is what an enforcement-ready email environment looks like.
Ready to find out where you stand?
LuxSci has provided HIPAA-compliant email solutions to healthcare organizations for over 20 years. We serve some of healthcare's leading providers, payers, and suppliers, including Athenahealth, 1-800 Contacts, Hinge Health and Delta Dental — securely sending hundreds of millions of emails per month. From encrypted email delivery for transactional and marketing emails to secure forms to archiving and audit logging to BAA-backed infrastructure, we help you meet the new HIPAA email standard without disrupting the way your teams work.
This guide is based on the HIPAA Security Rule NPRM published January 6, 2025 (90 FR 800). The final rule has not yet been published. Organizations should review official HHS guidance upon final rule publication and reconcile compliance programs against official requirements. This document does not constitute legal advice.
The HIPAA Security Rule final rule hasn't been published yet — do we still need to act now?
Yes. The regulatory delay does not change your obligations under the existing HIPAA Security Rule, which is actively enforced. OCR recorded 21 settlements in 2025 and has formally expanded its enforcement initiative to include risk management. This includes what organizations actually do about identified risks, not just whether they've assessed them. Beyond enforcement, the cybersecurity threat environment hasn't paused. Email remains the number one attack vector in healthcare. When the final rule is published, organizations will have approximately 180 days to comply. Those who haven't prepared will face a compressed, costly scramble.
Our organization uses Microsoft 365 or Google Workspace with a signed BAA — aren't we already covered?
Not fully. A BAA with Microsoft or Google covers their infrastructure, but it does not automatically configure email encryption enforcement, disable legacy TLS protocols, or implement encryption at rest for all ePHI. Both platforms send email insecurely if the recipient's server doesn't support TLS, and neither provides encryption for ePHI by default. Under the proposed rule, organizations need to demonstrate active, enforced encryption, not just a signed agreement. A HIPAA compliant email encryption solution like LuxSci's SecureLine encryption layered on top of your existing platform, closes these gaps.
A patient has asked us to communicate with them via their personal unencrypted email. Does that waive our encryption obligation?
No — and this is one of the most common points of confusion. The HIPAA Privacy Rule allows organizations to honor a patient's preferred communication channel when the patient provides consent. However, this Privacy Rule provision does not override the Security Rule's requirement to encrypt ePHI on your own infrastructure. Your obligation is to encrypt on your end and deliver in a way the patient can access, whether that's a standard encrypted message or, in rare cases, a secure portal. The patient's channel preference does not relieve you of your infrastructure obligation. All patient communication preferences should be documented.
What is the difference between TLS encryption and end-to-end encryption, and which one does HIPAA require?
TLS (Transport Layer Security) encrypts email in transit — between servers — but the message can be decrypted at the server level and is not protected at rest. The proposed HIPAA Security Rule requires both encryption in transit (TLS 1.2 or higher) and encryption at rest (AES-256). TLS alone does not satisfy the at-rest requirement. LuxSci's SecureLine technology supports TLS, S/MIME, PGP, and secure portal delivery, automatically selecting the appropriate method based on recipient capabilities.
How do we evaluate whether our current email vendor meets the new proposed HIPAA Security Rule requirements?
Start with seven core dimensions: whether a current BAA exists and reflects the proposed rule's 24-hour breach notification requirement; whether TLS 1.2 or 1.3 is enforced (not just available) on all connectors; whether email is encrypted at rest with AES-256; whether MFA can be enforced across all accounts; whether the vendor produces audit logs sufficient for OCR review; whether the vendor holds current security certifications (HITRUST, SOC 2 Type II, or GDPR-compliant); and whether they can provide annual written verification of their technical safeguards. Use the interactive vendor scorecard in Section 3 of this guide to evaluate your current vendor — or contact LuxSci for a free compliance assessment.