HIPAA and your website's TLS: what "encryption in transit" actually means

Updated August 2026 · about a 6-minute read

If your website touches health information — a patient portal, an intake form, an appointment booker, anything that collects or shows ePHI — HIPAA has an opinion about how that data travels. The short version: it has to be encrypted in transit, and in practice that means TLS. What trips people up isn't setting it up once; it's the word "addressable," and a proposed rule change that's about to make that word disappear.

"Addressable" doesn't mean optional

Under today's HIPAA Security Rule, encryption in transit is an addressable implementation specification. People read "addressable" as "optional." It isn't. It means you must either implement it, or document a reasoned justification for why you didn't and what you did instead. For data crossing the public internet — which is exactly what your website does — there is no credible justification for not encrypting. So for practical purposes, TLS on any page handling ePHI is expected, full stop.

And the wiggle room is closing. A Notice of Proposed Rulemaking published in early 2025 would remove the "addressable" category entirely and make encryption of ePHI — at rest and in transit — flatly required, with no documented-exception route. It's proposed, not final, and the timeline is still moving. But the direction is one-way: plan for required, because that's where this lands.

What "TLS" means concretely here

• TLS 1.2 is the floor; 1.3 is preferred for anything new. That aligns with the same modern-cryptography bar you'll see referenced across the guidance.
• Turn off the old stuff. TLS 1.0, 1.1 and SSL should be disabled. Offering them at all is a weakness even if nothing legitimate uses them.
• Valid certificate. Trusted CA, not expired, matching the hostname. An expired cert on a page collecting patient data isn't just a bad look — it's an encryption-in-transit failure while it's broken.

None of this is exotic; most modern hosts default to a fine TLS setup. The hard part, like every framework, isn't the initial config. It's proving it stayed that way.

The evidence problem

HIPAA is enforced after the fact — during an audit, or worse, after a breach investigation. What gets scrutinised then is whether your safeguards were actually operating over time, not whether they look fine the day someone asks. A scan screenshot from last week proves one moment. It doesn't prove your TLS held every day a patient submitted a form.

The question that matters after a breach isn't "was it encrypted today?" It's "can you show it was encrypted the day the data moved?" That's a different kind of evidence — dated and continuous, not a point-in-time check.

How to stay covered without a compliance suite

The sustainable approach is the same one that works for the other frameworks: get the config right once, then have something watch it from the outside continuously and keep the dated record. Concretely:

1. TLS 1.2+ only, weak protocols disabled, valid certificate. (Probably already true.)
2. An external check every day, so a regression — an expired cert, a re-enabled old protocol — is caught the day it happens, not at audit time. This is where an unwatched certificate quietly expiring becomes a real HIPAA problem.
3. Keep the dated results as your evidence.

If you're also handling cards or pursuing other frameworks, the good news is the evidence is the same dated record — it satisfies PCI DSS, SOC 2 and ISO 27001 too. Set it up once, and it pays into all of them.

One honest caveat: this covers the external transport slice — TLS, headers, DNS. HIPAA compliance is much broader (access controls, at-rest encryption, BAAs, risk analysis). This is one control, done well, with proof — not the whole program.