A physician sends a lab result to a referring practice at 9:14 am and it arrives seconds later, with nothing bouncing and no warning appearing anywhere in the process. Between those two moments, the message passed through a negotiation neither party can see, and in roughly 4% of cases across healthcare, that negotiation is unsuccessful, allowing dangerous emails to slip through the cracks or safe ones to be caught up in quarantine.

Paubox analyzed 803,378 unique outbound relays across one week of customer traffic in November 2025. The resulting report found 0.48% of connections going to servers with expired certificates and 3.35% to servers using self-signed ones, which at industry scale puts up to 19 million PHI-bearing email addresses at risk.

 

Stage one, deciding whether to protect it

Gretchen Murchison, a licensed clinical social worker running Sunrise LCSW, set her practice up on Google Workspace and later found that "the BAA did not cover outside communication." A business associate agreement governs how a platform handles data inside its own systems and says nothing about a message once it has left for somebody else's server.

Most encryption failures begin here, before anything technical happens, because a person has to decide the message needs protecting. Practices relying on subject-line keywords or an encryption button inherit that decision hundreds of times a week, made by staff mid-shift.

 

Stage two, leaving the outbox

Misdirected email remains among the most common reportable breaches in healthcare, with no attacker involved at any point, and encryption does nothing about an address typed wrong. Paubox DLP inspects messages on the way out and can alert an administrator or hold delivery when PHI is heading somewhere it should not, which also covers a compromised account being used to move data out quietly.

 

Stage three, the handshake

Transport Layer Security encrypts a message while it travels between servers, though it cannot do that alone. TLS depends on certificates, which are digital files proving a server is who it claims to be, issued by an authority both sides trust. A valid one confirms three things: you reached the right server, someone independent verified it, and the encryption keys cannot be tampered with.

Certificate validation works similarly to checking a passport, where an expired document is unreliable a traveler-issued one tells you few details. A self-signed certificate is exactly the second case.

The Paubox analysis counted 30,744 certificate failures across that single week of traffic, and healthcare's vendor layer holds most of them. Billing companies, EHR add-ons, imaging services, and managed service providers all exchange email on providers' behalf, frequently on self-managed mail servers where certificates expire, and renewal automation quietly breaks without anyone noticing.

 

Stage four, the fallback

Paubox tested what Microsoft 365 and Google Workspace actually do when certificate validation fails and published the results. Google Workspace completes delivery using TLS 1.0 or 1.1, protocols that NIST's guidance on TLS implementations moved federal systems away from years ago, requiring TLS 1.2 as a minimum and TLS 1.3 support by January 2024. Microsoft 365 refuses those older protocols and then sends the message as cleartext instead, unencrypted, with no notice to the sender.

Browsers handle the same situation differently. Load a site with a broken certificate, and the connection is blocked behind a warning page you have to click through deliberately, whereas email transport is permissive by design, because a bounced message generates a support ticket and a delivered one does not.

Hoala Greevy, Paubox's CEO, described the effect of relying on forced TLS settings as something that "gives you just enough confidence to stop asking questions."

 

Stage five, what the sender sees

There is no bounce, no alert, and no log entry marking the message as unprotected. The recipient receives it, the thread continues, and the audit trail records a delivered email with nothing indicating that the encryption layer collapsed along the way.

HIPAA's Security Rule at 45 CFR 164.312(e)(1) requires technical safeguards protecting ePHI during transmission, and an organization cannot demonstrate it met that requirement for a message it holds no encryption record for. OCR has cited transport encryption failures in enforcement actions repeatedly.

 

Stage six, arrival

Portal-based encryption protects the message and routes the recipient to a separate login to read it. Laura Coughlin, Director of Product Success at Podimetrics, described the approach her team moved away from as one "which requires passwords, and that's super clunky."

Paubox research on portal use found 65% of patients stop using a portal after the first day, which converts a protected message into an unread one. Paubox Email Suite encrypts every outbound message and delivers it to the inbox directly, with no portal, no password, and no keyword for the sender to remember.

 

Stage seven, proving it two years later

An auditor or an OCR investigator eventually asks what was sent, to whom, and whether it was protected, which happens long after anyone remembers the message. Paubox Archiving keeps that record searchable, and given that OCR's most consistent enforcement finding remains an absent or inadequate risk analysis, being able to produce evidence rather than assurances carries weight.

 

What it costs when the chain breaks

A phishing attack reached eight employee email accounts at Solara Medical Supplies between April and June 2019, exposing ePHI for 114,007 individuals. OCR announced a $3 million settlement in January 2025, citing an inadequate risk analysis, insufficient security measures, and late breach notifications to individuals, HHS, and the media. Solara separately settled a class action for $9.76 million and remained under a corrective action plan monitored by OCR for two years.

OCR Director Melanie Fontes Rainer framed the agency's expectation in that announcement, saying that "health care entities that fail to address identified cybersecurity issues leave themselves vulnerable."

Learn more: HIPAA Compliant Email: The Definitive Guide

 

In the news

Researchers presenting at the USENIX Security Symposium ran the first structured analysis of STARTTLS, the mechanism that upgrades an unencrypted email connection to an encrypted one, across SMTP, POP3, and IMAP. Their paper, titled "Why TLS is better without STARTTLS," reported more than 40 vulnerabilities across 28 email clients and 23 servers.

An internet-wide scan for one particularly dangerous command injection attack found 320,000 email servers affected, roughly 2% of every email server online. The researchers concluded that STARTTLS is error-prone to implement, under-specified in the standards, and should be avoided where possible, which is a considerably blunter position than most healthcare IT teams have heard about the protocol carrying their patient data.

 

FAQs

Does TLS mean my email is encrypted?

It means encryption was attempted. Whether it succeeded depends on the certificate the receiving server presents, and platforms will often deliver anyway when that validation fails.

 

What is a self-signed certificate?

One the server generated for itself rather than obtaining from a trusted authority, so there is no independent way to confirm the server is what it claims to be. Roughly 3.35% of healthcare email connections in the Paubox sample went to servers using them.

 

If force TLS is enabled, am I covered?

Not reliably. Force TLS does not control which version of TLS gets used, so Google Workspace may complete delivery on deprecated protocols while Microsoft 365 may send unencrypted instead, and neither notifies the sender.

 

Why does this concentrate around vendors?

Business associates often run older self-managed mail servers where certificates expire, and renewal automation fails without anyone noticing. With 16% of email-related breaches involving business associates, certificate hygiene at the vendor layer affects every provider sending to them.

 

How would we know if this has happened to us?

Under standard platform behavior, you would not, because there is no bounce, no alert, and no audit entry distinguishing an encrypted delivery from a downgraded one. Organizations needing provable encryption use a service that enforces and logs it rather than attempting it.