Transmission Security

Implement technical security measures to guard against unauthorised access to ePHI transmitted over an electronic communications network. The standard at 164.312(e)(1) carries two addressable specifications: integrity controls at 164.312(e)(2)(i), and encryption at 164.312(e)(2)(ii).

Start by inventorying every transmission path. Organisations consistently under-count these, and an uninventoried path cannot be protected. Typical paths include clinical interfaces and HL7 or FHIR feeds, email, SFTP and file transfer to payers and labs, remote access sessions, API integrations, cloud replication and backup, fax over IP, mobile applications, and messaging between clinicians.

Implementation approach:
• Encrypt ePHI in transit as the default. Use TLS 1.2 as a floor and prefer TLS 1.3, with strong cipher suites, certificate validation and no fallback to deprecated protocols
• Disable SSL 3.0, TLS 1.0 and TLS 1.1, and remove export-grade and NULL cipher suites
• Validate certificates properly, including chain and hostname; accepting invalid certificates silently negates the protection
• Apply integrity controls so undetected modification in transit is prevented — authenticated encryption modes achieve confidentiality and integrity together
• Secure email carrying ePHI through TLS with enforced policy, a portal, or message-level encryption. Opportunistic TLS alone is not enforcement
• Replace legacy plaintext protocols: FTP, Telnet, HTTP and unauthenticated SMTP relay
• Encrypt internal transmission too where risk warrants; a flat internal network is not a trust boundary
• Where you decide against encryption on a given path, record the reasoning and the equivalent alternative under 164.306(d). Encryption meeting HHS guidance is also the route to the safe harbour at 164.402

Test what you configured. Scanning your own endpoints is the fastest way to find the path still negotiating TLS 1.0.

• Transmission security policy and supporting procedures
• Inventory of every ePHI transmission path, with counterparty, protocol and encryption status
• Approved protocol and cipher suite standard, including minimum TLS version
• Encryption decision record per path, with equivalent alternatives where encryption is not used
• Integrity control design for transmission, covering 164.312(e)(2)(i)
• Email security configuration, including TLS enforcement or portal arrangements
• Certificate inventory, ownership and renewal schedule
• Scan or test results demonstrating configuration matches policy
• Business associate agreements covering each external transmission counterparty
• Records of transmission-related incidents

• Enumerate transmission paths independently and compare against the inventory to find omissions
• Scan external endpoints and confirm the negotiated TLS version and cipher suites match policy
• Attempt to connect using TLS 1.0 or a weak cipher and confirm the connection is refused
• Present an invalid or expired certificate and confirm the client rejects it
• Capture traffic on a sample internal path and confirm ePHI is not observable in plaintext
• Send a test message containing ePHI by email and verify encryption was actually applied, not merely attempted
• Confirm legacy plaintext protocols are disabled by attempting to use them
• Verify integrity protection by confirming authenticated encryption or an equivalent mechanism is in use
• Check certificate expiry dates against the renewal schedule
• Confirm a signed business associate agreement exists for every external counterparty receiving ePHI