Encryption in Transit

Encryption in transit protects data while it moves between systems, such as between a browser and a server or between microservices. It prevents attackers on the network from reading or modifying the data as it travels.

How It Works

The dominant mechanism is Transport Layer Security (TLS), which secures HTTPS and many other protocols. A TLS handshake uses asymmetric encryption to authenticate the server (and optionally the client) and to agree on a shared session key. The bulk of the traffic is then encrypted with fast symmetric encryption using that session key.

TLS provides three guarantees: confidentiality through encryption, integrity through message authentication codes, and authentication through certificates issued by a public key infrastructure. Modern deployments use TLS 1.2 or 1.3, strong cipher suites, and certificates from trusted certificate authorities. Within service meshes, mutual TLS authenticates both ends of every connection.

Encryption in transit applies beyond the web: database connections, message queues, API calls, and internal service-to-service traffic should all be encrypted.

Why It Matters

Networks are hostile. Public Wi-Fi, shared cloud infrastructure, and compromised routers all expose plaintext traffic to interception. Without encryption in transit, credentials, tokens, and sensitive data can be captured or altered in a man-in-the-middle attack.

Encryption in transit is now a baseline expectation. Browsers mark plain HTTP as insecure, and compliance frameworks require it for sensitive data. In a zero-trust architecture, even internal traffic is encrypted because the internal network is not assumed safe.

Like encryption at rest, it is one layer of defense in depth and must be combined with strong authentication and authorization.

Related Terms

Encryption in transit relies on asymmetric encryption, public key infrastructure, and often mutual TLS. It pairs with encryption at rest to protect data through its full lifecycle.