HIPAA Transmission Security 164.312(e): Encryption in Transit
HIPAA transmission security, defined in 45 CFR 164.312(e), requires technical measures that guard against unauthorized access to electronic protected health information while it travels across networks. The standard has two addressable implementation specifications: integrity controls and encryption. In practice, that means TLS 1.2 or higher, proper certificate validation and encrypted file transfers. It also means securing the path most integration environments miss: HL7 MLLP interfaces. This operational guide ends with an interface-by-interface checklist. Ask us to review your data flows for gaps.
What the Transmission Security Standard Requires
The transmission security standard at 164.312(e)(1) applies whenever ePHI moves over an electronic communications network, including the internet, private networks, wireless connections and links between cloud services. It contains two implementation specifications, both addressable: integrity controls at 164.312(e)(2)(i) and encryption at 164.312(e)(2)(ii). Addressable means each must be assessed and implemented, replaced with an equivalent alternative, or documented. For how this fits the wider rule, see our HIPAA technical safeguards overview.
Integrity Controls — Addressable
Implement security measures ensuring transmitted ePHI is not improperly modified without detection until disposed of. TLS provides cryptographic integrity in transit, while message validation and acknowledgements catch application-level problems that TLS alone cannot detect.
Encryption — Addressable
Implement a mechanism to encrypt ePHI whenever deemed appropriate. For modern systems, encrypting every network path carrying ePHI is reasonable and expected, so documented exceptions should be rare, narrow and supported by risk analysis.
Networks Inside Your Perimeter
Internal networks are not automatically safe. Traffic between application servers, databases, integration engines and cloud services can be intercepted by attackers who gain internal access, so internal connections carrying ePHI need encryption too.
Breach Notification Safe Harbor
ePHI encrypted according to HHS guidance is not considered unsecured if intercepted, provided keys remain protected. This safe harbor can mean the difference between a reportable breach and a manageable security incident.
Documenting Your Assessment
Record every network path carrying ePHI, the protection applied and any exceptions with reasoning. This inventory supports audits, simplifies partner security questionnaires and helps teams spot new paths added over time.
TLS Standards and Certificate Validation
HIPAA encryption in transit is usually implemented with Transport Layer Security. HHS guidance points to NIST publications for acceptable configurations, and current NIST guidance supports TLS 1.2 as a minimum, with TLS 1.3 preferred where available. Older SSL and early TLS versions are considered insecure and should be disabled everywhere. Configuration details matter as much as protocol versions, because weak cipher suites or skipped certificate validation can silently undermine otherwise encrypted connections completely.
Use TLS 1.2 as a Minimum
Disable SSL and TLS 1.0 and 1.1 on every server, load balancer and client library. Many legacy integrations still negotiate outdated versions unless explicitly blocked, so test each endpoint rather than assuming defaults.
Prefer TLS 1.3 Where Supported
TLS 1.3 removes weak cipher options, simplifies configuration and improves performance. Enable it wherever both sides support it, while keeping TLS 1.2 with strong cipher suites for partners that cannot yet upgrade.
Validate Certificates Properly
Clients must check certificate validity, expiry, hostname and trusted issuer. Code that disables certificate validation to fix connection errors creates man-in-the-middle risk, and it is a surprisingly common shortcut in integration scripts.
Consider Mutual TLS for Systems
For system-to-system connections, mutual TLS lets both sides authenticate with certificates. It strengthens authentication for integration partners and APIs, supporting person or entity authentication requirements alongside transmission security. Rotate certificates on schedule.
Manage Certificate Lifecycles
Track certificate expiry dates, automate renewals where possible and alert before expiration. Expired certificates are one of the most common causes of unplanned interface outages across hospital and lab environments.
MLLP, File Transfers and Email
The most commonly missed transmission paths in healthcare are not websites or APIs. They are HL7 MLLP feeds, batch file transfers and email. Plain MLLP sends HL7 messages over TCP without encryption, and many interfaces have run that way for years inside hospital networks. File transfers and email carry large volumes of PHI too. Our HL7 integration team regularly finds unencrypted feeds during integration assessments. Each path is covered below with practical guidance.
MLLP Over TLS
Wrap MLLP connections in TLS directly, or tunnel them through site-to-site VPNs when partners cannot support TLS. Integration engines such as Mirth Connect support TLS listeners and senders with proper certificate configuration.
SFTP for Batch Files
SFTP runs over SSH, uses a single port and supports key-based authentication, making it simpler to secure and firewall. It is the most common choice for lab, billing and claims batch transfers today.
FTPS as an Alternative
FTPS adds TLS to traditional FTP. It can be secure when configured correctly, but multiple ports and firewall complexity make it harder to manage. Never use plain FTP for files containing ePHI.
Email Containing PHI
TLS between mail servers protects messages in transit only when both servers support it. For sensitive content, use encrypted email services, secure portals or S/MIME, and never rely on unencrypted email by default.
Patient-Requested Communication
Patients may request communication by unencrypted email after being informed of the risks. Document that request and warning, and still use encrypted methods for communication with providers, partners and vendors.
Interface-by-Interface Transmission Checklist
The value of transmission security comes from coverage, not intentions. A single unencrypted path can expose ePHI even when every other connection is protected. Use the checklist below to review each interface type in your environment, recording the protection applied and any gaps. Pair it with our HIPAA software development checklist for application-level controls. Repeat the review whenever new partners, systems or cloud services are added. Record findings in one shared inventory.
Web Applications and Portals
Enforce HTTPS with TLS 1.2 or higher, enable HSTS, redirect all HTTP requests and use secure cookies. Confirm that third-party scripts and embedded content also load over encrypted connections only.
APIs and FHIR Endpoints
Require TLS for every API call, validate certificates and use OAuth 2.0 tokens. Our FHIR integration projects also apply rate limiting and request logging for traceability. Reject plain HTTP requests outright.
HL7 Interfaces
Check every MLLP listener and sender for TLS or VPN protection. Document each partner connection, including ports, certificates and responsible contacts, and remove any plain TCP connections carrying ePHI. Review quarterly.
Databases and Internal Services
Enable encrypted connections between applications and databases, message queues, caches and internal microservices. Internal traffic is often overlooked, yet attackers inside networks can intercept it just as easily. Test with packet capture.
Backups, Replication and Monitoring
Encrypt database replication, backup transfers and log shipping. Monitoring agents and log collectors can capture ePHI unexpectedly, so their network traffic needs the same protection as primary data flows. Verify agent settings.
Frequently Asked Questions
What does 45 CFR 164.312(e) require?
45 CFR 164.312(e) requires technical security measures guarding against unauthorized access to ePHI transmitted over electronic communications networks. It includes two addressable implementation specifications: integrity controls, ensuring transmitted data is not improperly modified undetected, and encryption, protecting ePHI in transit whenever appropriate, typically using TLS.
Is encryption in transit required by HIPAA?
Encryption in transit is addressable, not required. You must assess it and implement encryption, an equivalent alternative, or document why neither applies. For modern systems sending ePHI over networks, encryption is almost always reasonable and appropriate, and it supports breach notification safe harbor protections if data is intercepted.
What TLS version is required for HIPAA?
HIPAA does not name a TLS version. HHS guidance refers to NIST standards, which support TLS 1.2 as a minimum, with TLS 1.3 preferred where supported. SSL and TLS 1.0 and 1.1 should be disabled. Strong cipher suites and proper certificate validation are equally important.
Do HL7 MLLP interfaces need encryption?
Yes, when they carry ePHI across networks. Plain MLLP sends messages unencrypted over TCP. Protect MLLP connections with TLS directly or with site-to-site VPN tunnels, and document each connection. Unencrypted MLLP is one of the most common transmission security gaps found in healthcare integration environments.
Is SFTP or FTPS better for HIPAA file transfers?
Both can meet HIPAA transmission security expectations when configured correctly. SFTP is usually simpler, using one port and SSH keys, which makes firewall management easier. FTPS uses TLS but requires multiple ports and more configuration. Plain FTP should never be used for files containing ePHI.
Can PHI be sent by email under HIPAA?
Yes, with appropriate safeguards. Use encrypted email, secure portals or S/MIME for PHI. Patients may request unencrypted email after being warned of risks, and that request should be documented. Communication with providers, partners and vendors should always use encrypted methods covered by appropriate agreements.
Want a Review of Your ePHI Data Flows?
Our integration engineers are ready to help. Free consultation, no obligation.