Cybersecurity glossary
What is Encryption in Transit?
Learn what encryption in transit means, how TLS/HTTPS, mTLS, and VPNs protect network traffic, where termination points create risk, and how it differs from encryption at rest.
Definition
Encryption in transit is the protection of data while it moves between systems, users, services, or networks, usually by using protocols such as TLS, HTTPS, mTLS, SSH, or VPN tunnels to provide confidentiality, integrity, and endpoint authentication across untrusted paths.
Why encryption in transit matters
Data rarely stays inside one machine. Users submit credentials, browsers call APIs, services exchange tokens, and backups move across networks. Encryption in transit keeps that moving data private and tamper-evident while it crosses Wi-Fi, corporate networks, cloud backbones, service meshes, and the public internet.
Without it, anyone with network visibility can capture session cookies, API keys, personal data, or business records. With it, attackers still see metadata such as IP addresses and timing, but the protected payload is much harder to read or modify.
What encryption in transit provides
Confidentiality
Encrypted records hide payloads from eavesdroppers on shared, hostile, or misconfigured networks.
Integrity
Authenticated encryption detects tampering so altered traffic is rejected instead of silently trusted.
Authentication
Certificates, keys, or tunnel credentials help clients and services confirm who is on the other end.
Forward secrecy
Modern TLS handshakes use ephemeral keys so a later private-key compromise does not reveal old sessions.
Common ways to encrypt data in transit
TLS is the dominant building block. HTTPS uses TLS for web traffic. mTLS adds client certificates for workloads that must authenticate both sides. VPNs encrypt network traffic through a tunnel, often between a device and a private network or between sites.
Client starts a connection
A browser, app, service, or VPN client connects to a remote endpoint over an untrusted or semi-trusted network.
Endpoints negotiate protection
TLS, mTLS, SSH, IPsec, or WireGuard agrees on cryptographic parameters and checks the peer's identity.
Session keys protect traffic
After negotiation, symmetric keys encrypt application data and authenticate each record or packet.
Termination decrypts data
A server, load balancer, proxy, VPN gateway, or service mesh sidecar decrypts traffic so the next layer can process it.
Downstream controls take over
Once plaintext exists at the endpoint, authorization, logging controls, network policy, and storage encryption become critical.
TLS, mTLS, VPNs, and encryption at rest compared
| Control | Protects | Watch out for |
|---|---|---|
| TLS / HTTPS | Web, API, and application traffic between a client and server | Expired certificates, HTTP fallback, weak TLS versions, and misconfigured proxies |
| mTLS | Service-to-service and high-assurance client connections with mutual certificate authentication | Certificate issuance, rotation, revocation, and trusting forwarded client identity headers |
| VPN | Traffic inside an encrypted tunnel between users, sites, or networks | Traffic exposed after the VPN gateway and false confidence that private networks are automatically trusted |
| Encryption at rest | Stored data in databases, disks, backups, snapshots, and object stores | Data already decrypted in memory, applications, logs, exports, or query results |
Termination points are where risk returns
Encryption in transit is not magic end-to-end privacy unless every hop remains encrypted from the original sender to the final intended receiver. Many systems intentionally terminate TLS at a load balancer, CDN, API gateway, reverse proxy, ingress controller, or service mesh sidecar. That component sees plaintext.
Termination can be the right architecture, but it creates responsibilities: protect private keys, restrict administrator access, avoid logging sensitive bodies or headers, re-encrypt traffic to upstream services, and make sure identity information passed from the proxy to the app cannot be spoofed by direct callers.
Encryption in transit vs encryption at rest
Encryption in transit and encryption at rest solve different parts of the data lifecycle. Transit controls protect network movement. At-rest controls protect stored copies. A secure design usually needs both, plus application authorization and key management.
For example, a customer record can travel over HTTPS to an API, be re-encrypted with mTLS between services, then land in a database encrypted at rest. If the API logs the record in plaintext or sends it over an internal HTTP hop, one missing control can still expose it.
Deployment checklist
- Use HTTPS everywhere for web apps, APIs, admin consoles, callbacks, and webhook receivers.
- Disable SSL, TLS 1.0, and TLS 1.1; prefer TLS 1.3 and well-configured TLS 1.2 where compatibility requires it.
- Automate certificate issuance and renewal, and monitor expiry before outages or emergency overrides happen.
- Validate certificates and hostnames in clients instead of accepting self-signed or mismatched certificates by default.
- Use mTLS for sensitive service-to-service paths where workload identity matters.
- Re-encrypt traffic after CDNs, load balancers, VPN gateways, and ingress proxies when upstream networks are not fully trusted.
- Treat termination points as sensitive systems because they can read plaintext and hold private keys.
- Avoid logging secrets, tokens, request bodies, and decrypted payloads at proxies or application boundaries.
The practical takeaway
Encryption in transit protects data while it moves, most often through TLS-backed protocols such as HTTPS and mTLS or network tunnels such as VPNs. It is essential, but it ends wherever traffic is decrypted. Strong deployments pair modern TLS configuration with careful termination design, certificate operations, service identity, and encryption at rest for stored data.
Related security terms
Encryption at Rest
Protects stored data on disks, databases, backups, and object stores.
SSL/TLS
The protocol family most often used to encrypt application traffic in transit.
HTTPS
HTTP carried over TLS for secure web and API communication.
TLS Handshake
The negotiation that authenticates endpoints and establishes session keys.
Mutual TLS (mTLS)
TLS mode where both client and server authenticate with certificates.
Frequently asked questions
What is encryption in transit in simple terms?
Encryption in transit protects data while it is moving across a network, so people or devices on the path cannot easily read or alter it.
Is HTTPS encryption in transit?
Yes. HTTPS is HTTP over TLS, and it is the most familiar form of encryption in transit for websites, web apps, and APIs.
How is encryption in transit different from encryption at rest?
Encryption in transit protects data as it moves between endpoints. Encryption at rest protects stored data such as files, databases, snapshots, and backups.
Does TLS protect data after it reaches the server?
No. TLS protects the connection until a termination point decrypts the traffic. After that, application controls, internal network security, and encryption at rest must protect the data.
What is the difference between TLS and mTLS?
Standard TLS usually authenticates the server to the client. Mutual TLS also authenticates the client with a certificate, which is useful for service-to-service and zero-trust environments.
Does a VPN replace HTTPS?
No. A VPN encrypts traffic through a tunnel, but HTTPS still provides application-level server authentication and protection beyond the VPN endpoint.
What are common encryption-in-transit mistakes?
Common mistakes include accepting obsolete TLS versions, missing certificate validation, weak cipher suites, HTTP fallbacks, exposed termination points, and unencrypted traffic between internal services.
References
Explore authoritative guidance and frameworks related to encryption in transit.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.