AegisAI Perspectives · 048
HIPAA transmission security is the 164.312(e)(1) standard: guard ePHI against unauthorized access while email carries it across a network, hop by hop.
HIPAA transmission security is the standard at 45 CFR 164.312(e)(1): guard against unauthorized access to ePHI while it is transmitted over an electronic communications network, and email is one such network path1. Its two specifications, integrity controls and encryption, are labelled addressable23. AegisAI reads mail through the Microsoft 365 or Google Workspace API after delivery, with no change to mail routing, so TLS between mail servers stays a mail platform setting20.
This page covers the 164.312(e) standard itself, one email hop at a time. The full set of healthcare email rules and controls is in email security for healthcare: HIPAA rules and controls. Whether encryption is required at all is answered in does the HIPAA Security Rule require email encryption. This page explains the regulation text and NIST guidance; it is not legal advice.
List the paths, set a TLS floor, force TLS per partner, then record a decision per path710.
List every path ePHI travels. NIST SP 800-66 Rev. 2 makes this the first key activity: identify every pathway ePHI travels, inside the organization or out of it7. Email is one of the pathways it names, next to file transfers and web portals8.
Mark which paths leave your tenant. A message between two mailboxes on one platform takes a different route from one sent to a lab or a billing company.
Set TLS 1.2 as the minimum on every outbound connector. NIST SP 800-52 Rev. 2 says government servers shall use TLS 1.2 and should use TLS 1.3 as well10. Turn off TLS 1.0 and SSL 3.0, which that guide says shall not be used12.
Force TLS for each partner domain that receives ePHI. Opportunistic STARTTLS is open to a downgrade, where a man in the middle removes the STARTTLS offer and the client sends in the clear13.
Publish MTA-STS or DANE for your own domain. Both let a receiving MTA publish its TLS policy and mitigate man in the middle spoofing15.
Add message level protection where the connection is not enough. S/MIME encrypts and authenticates the message content itself, separate from TLS on the transport16.
Write one decision per path. For each addressable specification, assess whether it is reasonable and appropriate4. If it is not, document why. Then implement an equivalent alternative measure if reasonable and appropriate5.
Each control serves a named part of 164.312(e) and leaves a named gap.
| Control | 164.312(e) part it serves | What it protects | Gap it leaves |
|---|---|---|---|
| Opportunistic STARTTLS | (e)(1) standard, (e)(2)(ii) encryption | The connection, when both servers agree | Stripped by a man in the middle; most MTAs send unencrypted if certificate validation fails14 |
| Forced TLS per partner domain, TLS 1.2 floor | (e)(1), (e)(2)(ii) | The connection to one named partner | Applies only to the domains the rule lists |
| MTA-STS or DANE | (e)(1) | The receiving server publishes its TLS policy | Works only for domains that publish it |
| S/MIME | (e)(2)(i) integrity, (e)(2)(ii) encryption | Signed and encrypted message content | Needs certificates and key distribution on both sides |
| Portal delivery instead of email | (e)(1) | The message stays on a web portal pathway | The portal is a separate pathway to assess |
Illustrative example, figures are fictional. Harbor Lane Family Clinic is a fictional practice with 64 staff on one cloud mail tenant. It sends ePHI by email on three paths: lab results to 1 reference lab, claims questions to 1 billing company, and replies to patients.
The inventory finds 2 partner domains and 1 open path to patients. The outbound connector accepts TLS 1.0. Neither partner domain has a forced TLS rule, so mail to both goes out on opportunistic STARTTLS.
The security officer's fix list: set TLS 1.2 as the floor, add forced TLS rules for the lab and the billing company, and publish MTA-STS for the clinic's own domain. Patient replies with results move to the patient portal. Each path gets a one page decision record for integrity controls and encryption.
In week two, a forced TLS rule for the billing company bounces 3 messages. Its server presents an expired certificate. The clinic calls the billing company, which renews the certificate the same day, and the 3 messages go out again over TLS 1.2.
It requires technical measures that guard against unauthorized access to ePHI while it is transmitted. The text names no protocol, so the measure is yours to choose and to show.
The standard is required; its two specifications are addressable. Integrity controls mean electronically transmitted ePHI is not improperly modified without detection until disposed of. Encryption means a mechanism to encrypt ePHI whenever deemed appropriate. For an email hop, that is a decision about the connection and a decision about the message.
They fail at the paths the inventory missed. A TLS policy covers only the connections it names.
TLS encrypts the connection and not the message, so a forwarded message can leave the encrypted path23. A partner server that fails certificate validation gets the message over unencrypted TCP on most MTAs. TLS does not check the recipient, so a message to the wrong address still arrives encrypted. AegisAI's outbound email DLP reads who is sending sensitive data and to whom, checks whether that is normal, then applies your policy21. It runs on the same API connection that AegisAI inbound email security already uses22.
NIST SP 800-52 Rev. 2 mandates TLS 1.2 for government servers and support for TLS 1.3 by January 1, 202411. SP 800-52 sets a federal baseline. The HIPAA standard names no TLS version.
The same guide says TLS 1.1 should not be configured and TLS 1.0, SSL 3.0 and SSL 2.0 shall not be used. A decision record can name SP 800-52 as its reference. Software that scores message content for phishing does not set the TLS version of a hop; the mail administrator sets it on each outbound connector.
Three gaps take mail off the encrypted path, and none of them changes the message.
The first is STARTTLS stripping. A man in the middle removes the STARTTLS offer, and the sending server proceeds with an unsecured connection. The second is certificate failure fallback. Most MTAs default to sending over unencrypted TCP when certificate validation fails during the TLS handshake. Forced TLS per partner domain turns both into a bounce instead of a plain text delivery. The third is a forward to an outside address, which needs no attacker.
MTA-STS and DANE close the downgrade gap for your own domain; forced TLS closes it for each partner. NIST SP 800-177 Rev. 1 gives MTA-STS the same goal as DANE: a receiving MTA publishes its TLS policy and mitigates man in the middle spoofing.
Message level encryption closes the gap the network cannot. S/MIME protects the content itself. It needs certificate and key distribution between sender and recipient. Use it, or portal delivery, for paths where you cannot force TLS on every hop. Record the choice per path under 164.306(d)(3).
Start with the pathway inventory, then ask the sample questions. NIST published SP 800-66 Rev. 2 in February 2024 as a resource guide for the HIPAA Security Rule6.
Its first key activity for transmission security is to identify every pathway ePHI travels. Its sample questions ask whether email is on that list, next to file transfers and web portals. For encryption, it asks whether the organization has considered email encryption and automated confidentiality statements when emailing outside the organization9. Each answer belongs in the path's decision record.
It would make encryption of ePHI required with limited exceptions, removing the analysis of whether encryption is reasonable and appropriate17. It is a proposal. The rule in force still labels the encryption specification addressable.
The notice of proposed rulemaking took comments until March 7, 202518. The Spring 2025 regulatory agenda lists RIN 0945-AA22 at the Final Rule Stage, with Final Action shown as 05/00/202619. Until a final rule is published, the addressable label in 164.312(e)(2)(ii) is the text in force.
Track three numbers each week and keep the exports with the decision records.
It means guarding ePHI against unauthorized access while email carries it over a network. In practice that covers each hop: the TLS version, whether TLS is forced per partner, and whether the message itself is encrypted or signed.
TLS protects the connection, not the message. Forced TLS at a TLS 1.2 floor covers the hops you configure. A forward to an outside address, or a partner that fails certificate validation, leaves that path. Write down which paths rely on TLS alone.
They are addressable. Assess them, implement them if reasonable and appropriate, or document why not and use an equivalent alternative if reasonable and appropriate. S/MIME signing is one measure that authenticates the message content.
Opportunistic TLS encrypts when both servers agree and falls back otherwise; a man in the middle can strip the offer. Enforced TLS refuses to send without it. MTA-STS and DANE let a receiving domain publish that it requires TLS.
It proposes that, with limited exceptions. The comment period closed on March 7, 2025. The Spring 2025 agenda entry shows Final Action 05/00/2026.
