HIPAA + TLS: The Certificate Compliance Angle
When you write something on a postcard, anyone who handles it can read it. The postman. The sorter. The person who picks it out of the mailbox. The neighbour who happened to be in the lobby. The postcard wasn't designed for privacy. You wrote it on something that people can read on the way past, so people read it.
When you put the same words in a sealed envelope, the equation changes. The postman still handles it. The sorter still sorts it. But none of them know what's inside. The envelope is the encryption.
That distinction - between traffic that can be read in transit and traffic that can't - is what HIPAA is asking healthcare organisations to enforce when they handle Protected Health Information (ePHI) electronically.
It is not asking with the precision of PCI-DSS. HIPAA doesn't list specific cipher suites. It uses words like "addressable" and "reasonable." The result is a standard that gives you flexibility and also gives you rope.
Here's what HIPAA actually says about TLS, what it's about to start saying differently (the 2024 proposed rule update is significant), what auditors look for, and what your organisation needs to be able to show.
What HIPAA actually says
HIPAA's Security Rule applies to electronic Protected Health Information (ePHI) - health records, treatment information, anything that could identify a patient combined with their health data.
The TLS-relevant section is § 164.312(e) - Transmission security. It has two parts.
§ 164.312(e)(1) - Standard. "Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network."
This is the high-level requirement. Doesn't say how. Just says you must.
§ 164.312(e)(2)(ii) - Implementation specification (Encryption). "Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate."
This says "Encryption" and "addressable." In HIPAA-speak, "addressable" doesn't mean "optional." It means: implement this control, or document why you've chosen an equivalent alternative, or document why no protection is needed.
In practice, for ePHI transmitted over public networks, there is no equivalent alternative to encryption that auditors will accept. So "addressable" effectively means "required."
Why TLS specifically
HIPAA doesn't say "use TLS." But the practical guidance - particularly NIST Special Publication 800-52 Rev. 2 - does.
NIST SP 800-52 Rev. 2 is the federal government's TLS configuration guidance. It says, in summary:
- TLS 1.2 minimum. TLS 1.3 strongly preferred. No SSL, no TLS 1.0, no TLS 1.1. Disabled everywhere. Strong cipher suites only. Forward secrecy. AEAD modes (AES-GCM, ChaCha20-Poly1305). Proper certificate management. Valid chains, no self-signed certs for production, regular renewal.
When a HIPAA auditor wants to know what "appropriate encryption" looks like for ePHI in transit, NIST SP 800-52 Rev. 2 is the most commonly cited reference. Compliance with it is generally treated as compliance with the HIPAA encryption expectation.
The 2024-2025 changes
In December 2024, the Department of Health and Human Services published a Notice of Proposed Rulemaking (NPRM) that would significantly strengthen the HIPAA Security Rule, including the encryption provisions.
The relevant change for TLS:
- Encryption would become required, not "addressable." The distinction goes away. ePHI in transit must be encrypted, full stop. Specific NIST-aligned guidance would be referenced more directly. The mushiness around "appropriate" tightens. Asset inventory becomes explicit. Organisations would need a current inventory of systems handling ePHI, including the encryption controls protecting each.
The NPRM is going through its comment period and rule-making process. Final adoption is expected in 2026 or 2027, with implementation periods following. The direction is clear regardless of final wording: the HIPAA-TLS bar is rising, not falling.
If your organisation handles ePHI, the time to align with this direction is now, not after the rule takes effect.
What auditors look for
A HIPAA audit (whether driven by OCR, a Business Associate Agreement, or a third-party assessor) tends to ask:
- Where is ePHI transmitted in your organisation? Internal, external, between systems, to partners, in mobile apps. Show the inventory. What encryption protects each of those transmission paths? TLS 1.2 minimum? Demonstrate. How do you know it's actually being used? Continuous monitoring, scan reports, configuration management. What happens when something drifts? Detection, response, remediation timelines. Who's responsible for each cert? Named ownership. Not "Bob handles it." What's the incident history? Including small incidents. The auditor wants to see process, not perfection.
The pattern, which we've now seen across PCI-DSS and SOC 2 and now HIPAA, is consistent: the auditor wants to see an inventory, continuous monitoring, named ownership, and evidence that incidents get handled.
What you need to be able to show
For a HIPAA TLS review, four artifacts:
- A current inventory of all systems transmitting ePHI, with the encryption controls protecting each. Configuration evidence that TLS 1.2 minimum is enforced everywhere ePHI travels. Continuous monitoring with scan reports demonstrating ongoing compliance - not a one-time snapshot. Incident-handling records showing that drift gets detected and remediated.
If you can produce these four cleanly, the HIPAA TLS conversation is short. If you can't, it's long.
One small ask
HIPAA's TLS requirements have been "addressable" for a long time, which let teams treat them as soft. That window is closing - the 2024 NPRM signals where the rule is heading. The fix is the same fix as for PCI-DSS and SOC 2: inventory, continuous monitoring, named ownership, documented response. TLS Radar handles the inventory and monitoring sides for any cert in any environment, with audit logs that survive a HIPAA review. Free tier covers three domains, which is enough to test whether your current setup would hold up.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.