Data in Transit Security Controls

Data in transit security controls govern the cryptographic, authentication, and network-layer mechanisms applied to information as it moves between systems, devices, or networks. This reference covers the classification of transit security controls, the technical frameworks that define them, the regulatory mandates that require them, and the structural decisions that determine which controls apply in a given architecture. These controls are foundational to compliance under frameworks administered by NIST, HHS, the PCI Security Standards Council, and the FTC.

Definition and scope

Data in transit — sometimes called data in motion — refers to any digital information actively moving across a network path, including traffic between client and server, between data centers, between cloud environments, and across public internet links. The defining characteristic is exposure to a transmission medium that is not exclusively controlled by the data owner.

NIST Special Publication 800-111 and NIST SP 800-52 Rev. 2 establish the technical baseline for protecting data in this state, distinguishing it from data at rest security (stored information) and data in use protection (information actively processed in memory).

The scope of transit security controls includes:

1. Transport-layer encryption — cryptographic protocols applied at OSI Layer 4–7 (e.g., TLS 1.2 and TLS 1.3)
2. Network-layer encryption — IPsec tunnels and VPN encapsulation at OSI Layer 3
3. Application-layer encryption — end-to-end encryption applied before data enters the transport channel
4. Message-level signing — digital signatures that verify sender identity and message integrity
5. Certificate management — public key infrastructure (PKI) governing the issuance, rotation, and revocation of TLS certificates
6. Mutual authentication — bidirectional verification of both communicating endpoints

The boundary of "in transit" begins when data leaves a controlled storage environment and ends when it arrives at the next controlled storage or processing endpoint. Any gap in that path without encryption constitutes an uncontrolled exposure window.

How it works

The dominant mechanism for data-in-transit protection is the TLS handshake protocol, standardized by the Internet Engineering Task Force (IETF) in RFC 8446 (TLS 1.3, published August 2018). The handshake negotiates cipher suites, exchanges certificates, and establishes session keys before any application data is transmitted. TLS 1.3 reduced the handshake to 1 round trip (from 2 in TLS 1.2), eliminating several legacy cipher suites including RC4, 3DES, and MD5 that had been exploited in attacks such as POODLE and BEAST.

The process for a standard TLS-protected session follows this sequence:

1. Client sends a ClientHello listing supported cipher suites and TLS version
2. Server responds with a ServerHello, selected cipher suite, and its certificate chain
3. Client validates the server certificate against a trusted Certificate Authority (CA)
4. A shared session key is derived using Ephemeral Diffie-Hellman (ECDHE) key exchange
5. Encrypted application data transmission begins; the session key is discarded after the session ends (forward secrecy)

For network-layer controls, IPsec operates in two modes: Transport Mode (encrypts only the payload) and Tunnel Mode (encrypts both payload and header), with Tunnel Mode used in site-to-site VPN configurations. The distinction matters for architectural compliance: Tunnel Mode is required when the intermediate path traverses untrusted infrastructure, as specified in NIST SP 800-77 Rev. 1.

Key management practices govern the lifecycle of the cryptographic material underpinning all of these mechanisms — a failure in key rotation or revocation can nullify an otherwise sound encryption implementation.

Common scenarios

Enterprise east-west traffic — traffic between internal microservices or application tiers within a data center or cloud environment. This traffic is frequently unencrypted inside perimeter firewalls, creating lateral movement risk exploited in post-breach reconnaissance. Zero trust data security architectures treat east-west traffic with the same controls as north-south (external) traffic.

Cloud service API calls — data exchanged between applications and cloud provider APIs traverses public internet segments. PCI DSS v4.0 (published by the PCI Security Standards Council in March 2022) mandates strong cryptography for all cardholder data transmitted over open, public networks under Requirement 4.2.1, requiring at least TLS 1.2 with a confirmed migration path to TLS 1.3.

Healthcare data exchange — protected health information security under HIPAA Technical Safeguards (45 CFR §164.312(e)(1)) requires covered entities to implement a mechanism to encrypt and decrypt ePHI whenever deemed appropriate — with the HHS Office for Civil Rights treating TLS as the de facto standard in enforcement guidance.

Financial messaging systems — financial data security standards such as SWIFT's Customer Security Programme require member institutions to encrypt all data in transit across inter-institutional messaging channels using protocols meeting a defined minimum cipher strength.

Email transmission — SMTP connections between mail servers may use STARTTLS opportunistically, but opportunistic encryption provides no guarantee if the receiving server does not support it. SMTP MTA-STS (RFC 8461) and DANE (RFC 7671) address this by enforcing encrypted transport policies.

Decision boundaries

Selecting the appropriate control layer requires evaluating four structural variables:

Protocol version thresholds — TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 (published March 2021). Any system still accepting TLS 1.0 connections fails compliance requirements under PCI DSS, NIST guidance, and most federal agency baselines derived from NIST SP 800-52 Rev. 2.

Transport vs. end-to-end encryption — TLS secures the hop between two endpoints but does not protect data at intermediary nodes (e.g., a load balancer that terminates TLS). End-to-end encryption, applied at the application layer before transmission, protects data through intermediaries. The correct choice depends on whether intermediary nodes are trusted infrastructure under organizational control.

Mutual vs. one-way authentication — standard TLS authenticates the server to the client. Mutual TLS (mTLS) authenticates both parties. mTLS is the required posture for machine-to-machine API communication in zero trust frameworks and is specified in NIST SP 800-207 (Zero Trust Architecture).

Regulatory mandate vs. architectural risk — us-data-protection-regulations impose specific requirements by sector. Organizations subject to HIPAA, PCI DSS, and FISMA face prescriptive controls. Organizations outside those mandates rely on data security risk assessment to determine proportionate controls. The absence of a regulatory mandate does not alter the technical risk profile of an unencrypted transmission path.

The interaction between transit controls and broader data classification frameworks determines the minimum required control strength — a data element classified as public requires no confidentiality protection in transit, while a regulated or confidential element triggers the full protocol stack described above.

References

• NIST SP 800-52 Rev. 2 — Guidelines for TLS Implementations
• NIST SP 800-77 Rev. 1 — Guide to IPsec VPNs
• NIST SP 800-111 — Guide to Storage Encryption Technologies
• NIST SP 800-207 — Zero Trust Architecture
• IETF RFC 8446 — TLS 1.3
• IETF RFC 8996 — Deprecating TLS 1.0 and TLS 1.1
• IETF RFC 8461 — SMTP MTA Strict Transport Security
• PCI Security Standards Council — PCI DSS v4.0
• HHS Office for Civil Rights — HIPAA Security Rule (45 CFR Part 164)
• NIST Cybersecurity Framework