The fourth in a series on healthcare email security using HIPAA breach data and regulatory analysis.
TL;DR: The proposed HIPAA Security Rule will eliminate the "addressable" designation for encryption. Once the rule is ratified, ePHI at rest — including email archives — must be encrypted. Organizations have three paths: delete old email, rely on platform-native encryption, or add message-level protection. Each has real trade-offs, and the most common assumption ("O365 already encrypts at rest") may not hold up under the new standard.
‍
A rule that's been 12 years in the making
The HIPAA Security Rule hasn't had a major update since 2013 — back when most healthcare organizations were still migrating to electronic health records and cloud email was an emerging concept. The security landscape has changed beyond recognition since then. The regulatory framework hasn't.
The final rule (RIN 0945-AA22) is expected this month, with a 240-day compliance window. It touches nearly every aspect of HIPAA security, but one change stands out: the elimination of "addressable" implementation specifications.
Under the current rule, encryption of ePHI is "addressable" — organizations can evaluate whether it's reasonable and appropriate, and if not, document why and implement alternative measures. In practice, this has meant that many healthcare organizations have justified leaving email archives unencrypted for years. The reasoning usually goes: the email provider encrypts data on their servers, MFA is enabled on accounts, the residual risk is documented and accepted.
Under the updated rule, encryption is required. Period. ePHI at rest and in transit. MFA for all systems containing ePHI. The scope explicitly includes email systems and archives.
For any organization that's had "email data at rest" sitting as an accepted risk in a security risk assessment: that line item is about to become a finding.
Does email encryption actually mean what everyone thinks it means?
Most organizations haven't thought carefully about the answer to a question that will shape how auditors interpret the new rule for email.
Microsoft 365 and Google Workspace both encrypt data at rest at the infrastructure level. Disk-level encryption, AES-256, industry standard. When an auditor asks "is email encrypted at rest?", the answer is technically yes. This has satisfied most compliance reviews for years.
But the new rule's standard isn't just "use encryption." It requires that ePHI be rendered "unreadable, undecipherable, and unusable" to unauthorized persons who gain access.
Here's what actually happens during a healthcare email breach. An attacker compromises a credential — through phishing, session hijacking, MFA fatigue, or an adversary-in-the-middle technique. They log into the account through the normal interface. Every message is fully readable. The disk encryption is irrelevant — it protects against physical server theft, not against someone browsing an inbox with a valid session.
Physical server theft isn't how healthcare email breaches happen. According to OCR breach data, 85% of email breaches are account takeovers — authenticated sessions, not stolen hardware. The encryption that's in place addresses a 2005 threat model. The 2026 threat model is credential compromise, and disk encryption does nothing about it.
OCR hasn't explicitly ruled on whether platform-level encryption satisfies the new standard for email. But the direction of the rule is hard to miss: it eliminates the "addressable" workaround, mandates MFA at the system level, and was written against the backdrop of a breach landscape dominated by credential compromise. The bet that disk encryption alone will satisfy enforcement is a bet that gets riskier with every passing quarter.
The DLP misconception
Email DLP is the other control that comes up in these conversations — and it doesn't help here either.
Email DLP tools — Microsoft Purview's DLP policies, Google Workspace DLP, third-party solutions — are designed to prevent sensitive data from being sent outbound. They scan messages at the point of sending and block or flag content that matches policy rules. If a clinician tries to email a spreadsheet of patient SSNs to an external address, DLP catches it.
But think about what's actually in a typical clinician's inbox. Referral letters from other providers. Lab results. Insurance authorization responses. Patient messages through the portal. Five years of accumulated PHI — none of which was sent by the clinician. It was sent to them. DLP never touched it. It arrived, it sits in the archive in plaintext, and it's fully accessible to anyone with a valid session.
The new rule requires encryption of ePHI at rest. DLP operates in transit, on outbound messages. Conflating the two leaves a false sense of compliance — and a very real gap in the archive.
Three paths forward
With the "addressable" loophole closing, healthcare organizations have three realistic options for bringing email into compliance.
Path 1: Delete old email
The most direct approach: if there's no data at rest, there's no compliance problem. Set an aggressive retention policy — 90 days, 180 days, a year — and automatically purge everything older than the threshold.
Less data, less exposure. But healthcare is one of the hardest environments to implement aggressive email retention.
Clinicians routinely search old emails for patient history, referral context, and prior authorization decisions. Legal hold requirements — from litigation, OCR investigations, malpractice claims — can prohibit deletion of specific mailboxes for years. And even a strict 90-day policy leaves 90 days of PHI exposed in every inbox. A compromised account today still gives an attacker three months of patient data.
And there's a cultural problem: retention policies treat email as disposable, but clinical workflows treat it as a record. Organizations that implement aggressive deletion without clinical buy-in tend to see workarounds — PST archives on local drives, forwarding to personal accounts, copying messages into notes systems. One compliance problem gets replaced by several new ones.
Bottom line: Reduces data at rest for email outside the retention window. Doesn't protect anything within it. Doesn't address the MFA requirement. Creates operational friction that tends to generate its own compliance risks.
Path 2: Accept platform-native encryption as sufficient
The path of least resistance: document that Microsoft 365 or Google Workspace infrastructure encryption satisfies the "encrypted at rest" requirement. Update the risk assessment. Move on to the other provisions in the rule.
This has worked for years under the "addressable" framework. Many compliance consultants have accepted it. Many organizations have passed audits with it. It requires no new tools, no new workflows, no new budget.
The question is whether it holds up under the stricter standard. The argument for: encryption technology is present and meets a recognized standard (AES-256). The argument against: it doesn't render ePHI "unreadable" to an attacker with valid session credentials who reads messages through the normal interface. 144 email breaches are currently under investigation by OCR — 85% from account takeovers — and platform encryption didn't prevent any of them.
Platform-native tools also leave the MFA question unresolved. The rule requires MFA for access to systems containing ePHI. Login MFA satisfies that literally, but session hijacking bypasses login MFA entirely. A compromised session has full, unrestricted access to every message without ever encountering a second factor. Whether that satisfies the rule's intent is an open question.
Microsoft Purview and Google's tools can identify sensitive content — but configuring them for retroactive PHI detection across years of existing email is a major project. These are compliance and retention tools by design. Most organizations that start the retroactive classification effort don't finish it.
‍Bottom line: May satisfy a narrow compliance interpretation today. Carries increasing enforcement risk. Doesn't address the authenticated-session threat behind 85% of email breaches. Doesn't resolve the MFA-at-data-access question.
Path 3: Protect data at the message level
Instead of encrypting the disk or deleting the data, protect the sensitive content inside individual messages. Identify emails containing PHI, redact them at rest, and require a separate authentication step — independent of the account session — to access the content.
A compromised session sees an inbox, but sensitive messages show placeholders instead of patient data. Accessing the actual PHI requires passing an authentication challenge that the compromised session can't satisfy. The data is there when a legitimate user needs it, but genuinely unreadable to an unauthorized session — which is what the rule's "unreadable, undecipherable, and unusable" standard is asking for.
Because message-level protection applies MFA at the point of data access (not just at login), it addresses the MFA requirement in a way that survives session hijacking. And because it classifies PHI in existing email automatically — not just in new outbound messages — it produces the ePHI inventory that the rule now demands and that most organizations have never had for email.
It does require deploying a new tool, and it introduces a verification step for legitimate users accessing sensitive messages. In practice, this is a push notification or authenticator prompt — similar to EHR access — but it's a workflow change worth planning for.
‍Bottom line: Addresses encryption at rest for the actual threat model, MFA at the data level, ePHI inventory, and the enhanced audit trail requirements. Requires new tooling and rollout planning.
From risk-accepted to non-compliant
Email data at rest has lived in a gray zone for a long time. It showed up in risk assessments. It got documented as "addressable." It got deferred. Year after year, budget cycle after budget cycle.
The updated rule closes that gray zone. What was risk-accepted becomes non-compliant — with a deadline, a technical standard, and an enforcement agency that collected $9.9 million in penalties in 2024 alone.
Analysis of the OCR breach portal shows email breaches accelerating from 3 per quarter in early 2024 to 43 per quarter by mid-2025. Nearly 2 million patient records exposed through email in 24 months. The rule isn't a response to a theoretical risk. It's a response to what's already happening — and the current framework wasn't built to prevent it.
How Material Security helps
Material redacts sensitive email at rest and adds a simple challenge to access it on demand — a push notification, an authenticator prompt. Easy for legitimate users. Impossible for an attacker with a stolen session.
If a breach happens, Material provides proof of what patient data was never accessed — so your team can scope HIPAA notifications in hours, not weeks.
