Encryption in Transit

“Encryption in transit” is one of those requirements that sounds straightforward until you try to prove coverage in an audit. Most organizations have TLS on their public web apps, but exams and security reviews tend to focus on what’s missed: legacy interfaces, internal traffic, email relay paths, remote access tools, APIs behind gateways, and third-party connections that quietly downgrade protocol versions.

HICP Practice 4.4 sets a clear bar for healthcare environments: protect PHI and sensitive data in transit using TLS 1.2 or higher for all network communications, and eliminate deprecated protocols across systems and interfaces ¹. For a Compliance Officer, CCO, or GRC lead, the job is to turn that into a testable control: define scope, set technical standards, validate configurations continuously, and retain evidence that stands up to scrutiny.

This page gives you requirement-level implementation guidance you can hand to IT/security, include in policy and third-party requirements, and use as an audit-ready checklist.

Regulatory text

HICP Practice 4.4 (excerpt): “Encrypt PHI and sensitive data in transit using TLS 1.2 or higher for all network communications.” ¹

Operator interpretation (what this requires you to do):

• Mandate TLS 1.2+ anywhere PHI or sensitive data traverses a network path, whether the network is public or private. ¹
• Disable deprecated protocols (SSL, TLS 1.0, TLS 1.1) across “all systems and interfaces,” which includes endpoints, load balancers, gateways, APIs, remote access, and integration middleware. ¹
• Be able to prove it with technical validation (scans, configuration baselines, change control) and operational governance (policy, standards, exceptions).

Plain-English requirement

If PHI is moving across any network connection, it must be encrypted with modern TLS (1.2 or higher). You must also ensure nothing in your environment can still negotiate older, weaker encryption protocols. In practice, this becomes a combination of: (1) a TLS configuration standard, (2) inventory of where PHI flows, (3) configuration enforcement, and (4) monitoring and evidence.

Who it applies to (entity + operational context)

Entity types in scope: Healthcare organizations and Health IT vendors ¹

Operational contexts that commonly fall in scope:

• Patient portals, scheduling apps, telehealth platforms, mobile apps
• APIs (public and private), API gateways, service mesh ingress/egress
• EHR/EMR integrations, HL7/FHIR interfaces, interface engines
• Remote access (VPN, VDI, bastion hosts), admin consoles
• Email transport components where PHI is transmitted (for example, SMTP relays) when the organization relies on transport encryption
• Internal east-west traffic in data centers and cloud networks if it carries PHI (databases replicating, app-to-DB, message queues)
• Third-party connections: payer connections, labs, imaging, transcription, billing, outsourced call centers, managed service providers

Third parties: Treat third-party integrations as first-class scope. If PHI crosses the boundary, you need both contractual requirements and technical confirmation that the connection uses TLS 1.2+ without downgrade paths.

What you actually need to do (step-by-step)

1) Define scope by mapping PHI data flows

Create a pragmatic “PHI in transit inventory”:

• List applications and systems that transmit PHI.
• Identify protocols and endpoints involved: HTTPS, SMTP, SFTP/FTPS, database connections, message queues, vendor tunnels, API calls.
• Note whether each flow is internet-facing, partner-facing, or internal.

Deliverable: Data flow register with “encryption in transit method” column and owner.

2) Set a TLS baseline standard (and make it testable)

Write a configuration standard that engineering teams can implement without guessing. Include:

• Minimum TLS version: TLS 1.2 or higher. ¹
• Deprecated protocols disabled: SSL, TLS 1.0, TLS 1.1. ¹
• Approved certificate authorities and certificate lifecycle expectations.
• Rules for weak cipher suites and key exchange (keep the language enforceable; avoid long cipher lists in policy if you can’t maintain them).
• Requirements for mutual TLS (mTLS) where appropriate (for example, service-to-service or partner connections) as a risk-based enhancement.

Tip that helps audits: Put the “TLS 1.2+ only; no SSL/TLS 1.0/1.1” requirement in both the security standard and the system hardening baseline so it is enforceable through build and change processes.

3) Enforce TLS 1.2+ at choke points first

Start where you can cover many apps quickly:

• Load balancers / reverse proxies
• Web application firewalls
• API gateways
• Ingress controllers / edge proxies
• Email gateways or secure messaging platforms (where applicable)

Set these to refuse SSL/TLS 1.0/1.1 and require TLS 1.2+. Then confirm backend services also enforce the standard, especially if internal traffic can bypass the edge.

4) Fix internal services and “quiet” integrations

The biggest gaps usually live here:

• Legacy Windows/IIS/.NET defaults
• Java apps pinned to older runtimes
• Database drivers or ODBC/JDBC settings
• Interface engines with older endpoints enabled
• Vendor-managed appliances with outdated TLS stacks

For each exception, require an explicit remediation plan: upgrade, reconfigure, or isolate and compensate (short-term only). “We can’t change it” needs to become a tracked risk decision with an owner.

5) Manage certificates and keys like a production control, not a ticket queue

Operational requirements you should formalize:

• Central inventory of certificates (internal and public-facing)
• Ownership for renewals and revocation
• Standard issuance process (internal PKI or approved public CA)
• Storage requirements for private keys (restrict access; use hardware-backed options where available)

A common audit failure is proving the protocol version but having no coherent story for certificate lifecycle governance.

6) Validate continuously (don’t rely on a one-time scan)

Build repeatable verification:

• External TLS scans of internet-facing endpoints
• Internal scans of known service ports and partner connection points
• Configuration compliance checks for standard stacks (load balancers, gateways)
• Change control triggers: any new endpoint must pass TLS baseline checks before go-live

If you need a workflow system to track findings, exceptions, and evidence, Daydream can be the place to run the control as an operational program: map each PHI-bearing system to the encryption-in-transit requirement, assign owners, collect scan outputs and configs, and manage time-bound exceptions with approvals.

Required evidence and artifacts to retain

Auditors and assessors typically want “proof, not intent.” Retain:

• Policy/standard stating TLS 1.2+ requirement and deprecation of SSL/TLS 1.0/1.1 ¹
• PHI data flow inventory with in-scope systems and transmission paths
• System configuration evidence (screenshots/exports) from load balancers, API gateways, web servers showing allowed TLS versions
• Scan results (external and internal) demonstrating protocol support status
• Exception register with business justification, compensating controls, approval, and remediation plan
• Third-party evidence: contract clauses + technical confirmation (test results, vendor attestation) for TLS 1.2+ on integration endpoints
• Change records for remediation work (upgrades, configuration changes)

Common exam/audit questions and hangups

Expect these:

• “Show me that TLS 1.0/1.1 is disabled everywhere PHI transits.”
  Hangup: teams only test public URLs, not internal endpoints, admin ports, or partner circuits.
• “How do you know a new endpoint can’t be deployed with weak TLS?”
  Hangup: no pre-production gates, no standard patterns, ad hoc configuration.
• “Do your third parties meet the same requirement?”
  Hangup: contract says “encryption,” but there’s no minimum TLS version requirement or evidence.
• “What’s your exception process for legacy systems?”
  Hangup: exceptions exist informally in emails with no remediation dates or compensating controls.

Frequent implementation mistakes (and how to avoid them)

1. Scoping only ‘internet traffic’
   Fix: scope PHI flows, not just public endpoints. Internal PHI traffic still counts as “in transit.”

2. Allowing protocol downgrade for compatibility
   Fix: explicitly disable SSL/TLS 1.0/1.1 at the server side, and confirm with scans.

3. Relying on vendor attestations without technical verification
   Fix: require proof (endpoint test results) for any third-party integration moving PHI.

4. Treating certificates as a renewal calendar problem
   Fix: manage certificates as an operational control with owners, inventory, and access restrictions for private keys.

5. Writing policy that engineering can’t implement
   Fix: keep the standard crisp (TLS 1.2+; deprecated protocols disabled) and attach stack-specific hardening guidance maintained by security engineering.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat HICP Practice 4.4 as a clear industry cybersecurity expectation rather than rely on specific case comparisons. Practically, weak or missing in-transit encryption increases the likelihood of interception, credential theft, session hijacking, and exposure of PHI during transmission. It also increases the blast radius if an attacker gains a network vantage point (compromised endpoint, rogue Wi‑Fi, misrouted traffic, or compromised third party).

Practical 30/60/90-day execution plan

First 30 days (establish control and find exposure)

• Publish the TLS baseline standard: TLS 1.2+ required; SSL/TLS 1.0/1.1 disabled. ¹
• Build the PHI data flow inventory with system owners and transmission methods.
• Run an initial external scan of all internet-facing endpoints and capture evidence.
• Identify high-risk integrations (EHR interfaces, patient portal, APIs) and confirm protocol versions.

Days 31–60 (remediate high-impact areas and formalize governance)

• Remediate edge systems first (load balancers, gateways, WAF, ingress controllers).
• Create an exceptions process with required fields: scope, justification, compensating controls, owner, remediation plan.
• Add third-party contract language requiring TLS 1.2+ for PHI transmissions and prohibiting deprecated protocol support. ¹
• Stand up certificate inventory and assign renewal ownership.

Days 61–90 (make it durable and auditable)

• Expand scanning to internal segments that carry PHI (service-to-service, DB links, interface engines).
• Implement pre-deployment checks so new endpoints can’t ship with weak TLS.
• Close or formally accept remaining legacy exceptions with tracked remediation.
• Centralize evidence collection (scans, configs, exceptions, approvals) so audits don’t turn into a scramble. Daydream can host the requirement, map it to systems and third parties, and keep evidence current through recurring tasks and owner attestations.

Frequently Asked Questions

Does “encryption in transit” only apply to internet-facing systems?

No. HICP Practice 4.4 applies to “all network communications” carrying PHI or sensitive data, which includes internal traffic paths where PHI traverses the network. ¹

Is TLS 1.3 required?

The requirement is TLS 1.2 or higher, so TLS 1.3 meets the standard and is a good option where supported. Your baseline should at minimum enforce TLS 1.2+ and disable SSL/TLS 1.0/1.1. ¹

What about email—does STARTTLS count?

If you transmit PHI via email and depend on transport encryption, you need to ensure the hop uses TLS 1.2+ and cannot negotiate deprecated protocols. Many teams instead reduce reliance on opportunistic encryption by using secure messaging or portal delivery for PHI.

How do we handle a legacy medical device or appliance that can’t do TLS 1.2?

Treat it as an exception with a documented risk decision, compensating controls, and a remediation plan (upgrade, replace, or isolate with a secure gateway). Avoid silent “permanent exceptions” with no owner.

Do we need mutual TLS (mTLS) for compliance?

HICP Practice 4.4 sets a minimum of TLS 1.2+ encryption in transit. Use mTLS as a risk-based enhancement for sensitive internal service-to-service traffic and partner integrations where client authentication materially reduces risk. ¹

What evidence is strongest in an audit?

A combination works best: a TLS baseline standard, a PHI data flow inventory, repeatable scan reports showing protocol support, and configuration exports from control points like load balancers and API gateways. Add an exceptions register that shows how you handle legacy constraints.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices