Data Encryption in Transit: Protocols and Requirements

Encryption in transit secures data moving across networks by rendering it unreadable to any party other than the intended recipient. This page describes the protocols that implement in-transit encryption, the regulatory frameworks that mandate it, the scenarios where distinct protocol choices apply, and the boundaries that govern protocol selection decisions. The scope covers both enterprise and consumer-facing network contexts within US regulatory jurisdiction.

Definition and scope

Encryption in transit — also called transport encryption or data-in-motion encryption — is the application of cryptographic protocols to data as it travels between endpoints across a network. The goal is to prevent interception, eavesdropping, and tampering during transmission, as opposed to protecting data stored on disk (at rest) or actively being computed upon (in use). This protection mode is structurally distinct from encryption at rest and field-level techniques, which address different phases of the data lifecycle.

NIST SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, defines the federal baseline for in-transit encryption and specifies TLS 1.2 as the minimum acceptable version for US federal information systems, with TLS 1.3 preferred. NIST deprecates SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 in that publication.

Regulatory mandates for in-transit encryption span multiple US frameworks:

• HIPAA Security Rule (45 CFR § 164.312(e)(1)) requires covered entities to implement technical security measures that guard against unauthorized access to ePHI transmitted over electronic communications networks.
• PCI DSS v4.0 (Payment Card Industry Security Standards Council) Requirement 4.2.1 mandates strong cryptography for all transmissions of primary account numbers over open, public networks.
• FedRAMP (Federal Risk and Authorization Management Program) baselines require TLS 1.2 or higher for all data in transit between federal cloud service components.

The organizes service providers and compliance professionals operating within these frameworks.

How it works

In-transit encryption operates through a handshake-and-session model, in which the communicating parties establish mutual authentication, negotiate cipher parameters, and then exchange data under a session key derived from that negotiation. The process follows discrete phases:

1. Handshake initiation — The client sends a ClientHello message specifying supported TLS versions and cipher suites.
2. Server authentication — The server presents a digital certificate (typically X.509) issued by a trusted Certificate Authority (CA), proving its identity.
3. Key exchange — Under TLS 1.3, the only permitted key exchange mechanisms are Ephemeral Diffie-Hellman (DHE) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), both of which provide forward secrecy. TLS 1.2 permitted RSA key exchange, which does not provide forward secrecy.
4. Session key derivation — Both parties derive symmetric session keys from the key exchange output; under TLS 1.3, this derivation uses HKDF (HMAC-based Key Derivation Function) as specified in RFC 8446.
5. Encrypted data transfer — All application-layer data is encrypted using the negotiated symmetric cipher (e.g., AES-256-GCM) and authenticated using AEAD (Authenticated Encryption with Associated Data), which simultaneously provides confidentiality and integrity.
6. Session termination — Either party sends a close-notify alert, closing the session cleanly and discarding session keys.

TLS 1.3, standardized by the Internet Engineering Task Force (IETF) in RFC 8446 (2018), reduces the handshake from 2 round-trips to 1, eliminates weak cipher suites, and mandates forward secrecy. TLS 1.2, while still broadly deployed, permits negotiation of deprecated cipher suites such as RC4 and 3DES if misconfigured, creating exploitable downgrade paths.

TLS 1.2 vs. TLS 1.3 — key structural differences:

For broader context on algorithm families underlying these protocols, see the encryption resource overview.

Common scenarios

Web application traffic (HTTPS): TLS secures HTTP traffic through the HTTPS scheme (RFC 2818). The CA/Browser Forum Baseline Requirements govern certificate issuance standards for publicly trusted CAs. As of 2020, all major browsers mark HTTP connections to sites handling sensitive data as "Not Secure."

API communication between services: Microservice architectures and REST/gRPC APIs transmit structured data across internal and external network boundaries. Mutual TLS (mTLS) extends the standard handshake so that both client and server present certificates, enabling bidirectional authentication — a requirement in zero-trust network architectures.

Email transport: SMTP with STARTTLS (RFC 3207) provides opportunistic transport encryption between mail transfer agents. DANE (DNS-Based Authentication of Named Entities, RFC 7671) supplements this by binding TLS certificates to DNS records via DNSSEC, countering man-in-the-middle attacks on STARTTLS negotiation.

VPN and site-to-site tunnels: IPsec (Internet Protocol Security) and TLS-based VPN protocols (such as those implementing RFC 8784) encrypt traffic at the network layer, covering all protocol types traversing the tunnel. IPsec operates in either Transport Mode (encrypting payload only) or Tunnel Mode (encrypting the entire IP packet).

Database client-to-server connections: Database engines including PostgreSQL, MySQL, and Microsoft SQL Server support TLS for client connections. PCI DSS Requirement 4.2.1 and HIPAA technical safeguard provisions both drive enforcement of encrypted database transport in regulated industries.

Decision boundaries

Protocol selection and configuration decisions are governed by a combination of regulatory floors, data classification, and network architecture:

Mandatory vs. addressable controls: Under HIPAA, encryption of ePHI in transit is an addressable implementation specification (45 CFR § 164.312(e)(2)(ii)), meaning covered entities must implement it unless a documented risk analysis demonstrates an equivalent alternative. PCI DSS Requirement 4.2.1 is non-addressable — it is a mandatory control for any entity transmitting cardholder data over open networks.

Federal system floors: Federal civilian agencies operating under FedRAMP or FISMA must meet the NIST SP 800-52 Rev. 2 baseline. National Security Systems follow CNSS Policy No. 15 and NSA-approved cryptographic algorithms, which set higher bars than civilian NIST guidance.

Forward secrecy requirements: Environments handling data subject to long-term sensitivity (classified, legal, or financial records) should prefer TLS 1.3 or TLS 1.2 configured exclusively with ECDHE cipher suites. RSA key exchange in TLS 1.2 allows retroactive decryption of recorded traffic if the server's private key is later compromised — a risk that ephemeral key exchange eliminates structurally.

Performance vs. security tradeoffs: TLS 1.3's 1-RTT handshake and removal of RSA key exchange reduce latency and computational overhead relative to TLS 1.2 with non-ephemeral cipher suites. For high-throughput environments such as financial transaction processors or CDN edge nodes, TLS 1.3's session resumption (0-RTT) mode provides additional latency reduction, though 0-RTT data is not replay-protected and its use requires application-layer replay mitigation.

Certificate management: Expired or misconfigured certificates cause connection failures that cascade into service outages. NIST SP 800-57 Part 1 Rev. 5 specifies key-length minimums — RSA keys of fewer than 2048 bits are no longer considered acceptable for new certificates — and lifecycle management practices for cryptographic keys.