“TLS usually” is not a control

Ask a mail administrator whether email is encrypted and the honest answer is “usually”. Mail servers negotiate TLS when both sides support it, which today covers the large majority of traffic between major providers. Three problems hide inside “usually”.

Problem 1: You don’t know which ones weren’t

Opportunistic TLS silently falls back to plain text when negotiation fails. A small share of outbound mail from any major provider is unencrypted in transit on any given day; for small clinics and firms, whose correspondents include old hospital servers, ISP addresses and small businesses, the share is higher. Without a per-message record you cannot say which messages those were, and HHS’s guidance on unsecured PHI treats an unencrypted message as unsecured whether or not you knew.

Problem 2: “Usually” fails exactly when it matters

The recipient who can’t do TLS is disproportionately the old server at a rural hospital, the insurer’s legacy gateway, the patient’s decade-old ISP mailbox. Those are the messages carrying referrals, authorizations and records.

Problem 3: Regulators ask for the control, not the average

HIPAA’s transmission security standard at 45 CFR 164.312(e), the Safeguards Rule’s encryption requirement at 16 CFR 314.4(c)(3) and professional-conduct guidance all ask what you do to protect the message, not what fraction happened to be protected. “We require TLS and deliver through an encrypted page when it isn’t available, and here is the log” is a control. “Most mail is encrypted” is a hope.

What enforced looks like

• TLS with certificate validation is required to every recipient.
• When negotiation fails, the message is held and delivered through an encrypted page with a one-time code; it is never sent in the clear.
• Every message records the path: cipher and hop, or locked delivery with open events.

That is what encrypted delivery in PXCMail means. The difference between it and “usually” is the small share that wasn’t encrypted, and the log.

---

Was this useful? Tell us at [email protected]. Related: checklists · regulations in plain English.

Sources

• 45 CFR 164.312, Technical safeguards, (e) — requires measures to guard against unauthorized access to ePHI transmitted over an electronic network, with encryption as the named specification.
• 16 CFR 314.4, Elements of an information security program, (c)(3) — requires encryption of customer information in transit over external networks and at rest.
• HHS, Guidance on securing PHI (unsecured PHI and encryption) — explains that only PHI encrypted to the stated standard is “secured” and outside breach notification.