Data in transit, also known as data in motion, happens when data travels across a network between a sender and a destination. As it moves through the network, it’s susceptible to interception by hackers. Organizations can mitigate this risk by encrypting data before transmission and until it reaches its destination with transport layer security (TLS). Securing data in transit is a fundamental security strategy, complementing data at rest (stored data) and data in use (processed data).
Key takeaways
- Data in transit is data actively moving across networks—between browsers and servers, mobile apps and backend services, APIs and microservices, or during database replication across regions.
- When data is not encrypted in transit, malicious actors can intercept it through packet sniffing, man-in-the-middle attacks (MITM), or session hijacking.
- Transport layer security (TLS) protects data in transit by encrypting it before it leaves the source and decrypting it only upon arrival at its destination.
- Encryption in transit is just one part of a complete data protection strategy, which must also include protecting data at rest and data in use.
- Advanced database platforms like MongoDB secure data end-to-end, using TLS for transit, standard encryption for data at rest, and capabilities like queryable encryption.
Table of contents
Understanding data in transit
Data in transit refers to data moving between locations, whether across the public internet, a private network, or services within a cloud environment. In modern, distributed applications, securing this data is a fundamental security requirement.
Data must be protected in three states: in transit, at rest, and in use.
Where data travels:
From a web browser to a web server.
Between microservices in a distributed architecture.
From a mobile app to a backend API.
Across geographical regions during database replication or migration.
Between different cloud providers in multi-cloud deployments.
Different data states introduce different security considerations. Transit data is particularly exposed because it moves across networks where unauthorized parties may attempt to intercept, inspect, or modify it.
Why data in transit is vulnerable
Data in transit rarely moves through a single, isolated path. It often crosses:
Public IP addresses on the open internet.
Corporate networks with shared infrastructure.
Private networks in virtual private clouds.
Hybrid and multi-cloud environments.
Without strong security controls, transit data can be exposed to:
Eavesdropping and packet sniffing: Attackers intercept unencrypted data to read sensitive information such as credentials or personal data.
MITM attacks: An attacker inserts themselves between a client and server to impersonate one or both parties.
Session hijacking and token theft: Stolen session cookies or access tokens allow unauthorized access to applications.
Tampering: Requests or responses are modified while in motion, potentially altering transactions or injecting malicious payloads.
Failure to protect data in transit can lead to data breaches, loss of customer trust, data loss, operational disruption, and regulatory penalties under frameworks such as GDPR, HIPAA, and PCI DSS.
How data in transit encryption works (TLS/SSL)
Encryption ensures that data is transformed into an unreadable format before it leaves a system. This is primarily achieved through transport layer security (TLS), the successor to the older SSL protocol.
A typical TLS connection involves:
The handshake: The client and server agree on encryption techniques and cipher suites.
Verification: The systems validate digital certificates issued by trusted certificate authorities (CAs).
Key exchange: Public key and private keys establish secure symmetric encryption for the session.
Once established, data moves in encrypted form. Even if intercepted, it cannot be understood without the correct decryption key.
Modern standards of success for data in transit include:
Using HTTPS for all web applications.
Supporting TLS 1.2 or TLS 1.3.
Employing strong cipher suites and asymmetric encryption.
Maintaining proper certificate rotation and revocation checks.
Enforcing strict validation of digital certificates.
Encryption applied consistently across services and environments is critical. Partial adoption can create weak links in an otherwise secure architecture.
Best practices: How to protect data in transit
To protect data in transit, organizations should apply a layered approach.
Use TLS by default—everywhere
Encrypt client-server and service-to-service traffic.
Disable legacy protocols such as TLS 1.0 and 1.1.
Ensure all external endpoints maintain a secure connection.
Validate certificates correctly
Never disable certificate verification in production.
Use trusted CAs or an internal PKI for private network deployments.
Monitor for expired or misconfigured digital certificates.
Lock down access paths
Prefer private networking over broad public exposure.
Use IP allow lists, firewalls, and security groups.
Limit which services can communicate with each other.
Protect credentials and tokens in transit
Never send passwords or encryption keys over unencrypted connections.
Use short-lived tokens and secure cookies.
Enforce HSTS to prevent downgrade attacks.
Monitor and test
Regularly scan TLS configurations.
Conduct penetration testing.
Log and alert when anomalous authentication and network traffic patterns occur.
Strong encryption techniques must be paired with operational discipline.
Guidelines for common scenarios
Web and mobile applications
Enforce HTTPS.
Use secure cookies and HSTS.
Terminate TLS at trusted load balancers.
APIs and microservices
Encrypt internal service-to-service communication.
Use mutual TLS for authentication.
Consider service meshes and zero-trust networking patterns.
Data pipelines, backups, and migrations
Encrypt replication traffic across regions.
Ensure file transfers and backup tools use secure communication protocols.
Avoid exposing migration endpoints over public IP addresses.
Regulated workloads
Strong encryption in transit supports compliance narratives for regulated industries. While encryption alone does not guarantee compliance, it is a required control in most data protection regulations.
How MongoDB protects data in transit
A secure database platform should make protecting transit data straightforward and reliable.
TLS by default in the cloud
In MongoDB Atlas, all data in transit is encrypted by default using TLS. This includes:
Connections from applications to the database server.
Traffic between nodes in a cluster.
Replication and backup traffic.
Customers do not need to manually enable encryption for standard MongoDB Atlas deployments.
Configurable, modern encryption standards
MongoDB supports modern TLS versions such as TLS 1.2, with TLS 1.3 available in many environments, along with configurable cipher suites in enterprise deployments.This allows organizations to align encryption with internal security measures and compliance requirements.
Secure connections across deployment models
MongoDB Atlas (managed cloud): TLS enforced by default.
Enterprise Advanced (self-managed): TLS configurable with enterprise controls.
Community Edition: TLS supported but must be explicitly enabled.
Regardless of deployment type, MongoDB provides the foundation for secure data in motion.
Beyond in-transit data: Full-data lifecycle protection
Protecting transit data is one part of a broader data protection strategy.
MongoDB also supports:
Encryption at rest, with disk-level encryption and customer-managed keys.
In-use encryption through client-side field level encryption.
Advanced capabilities such as queryable encryption, where sensitive fields remain encrypted at rest, in transit, and even while queried.
Queryable encryption allows applications to work with encrypted data without exposing plaintext to the database server. This significantly reduces risk from unauthorized access and helps secure data workloads that process highly sensitive information.
You should not need to bolt on encryption or become a cryptography expert to achieve secure data in transit. A modern database platform should provide these capabilities by design. The chart below highlights various encryption methods. See the full list of queryable encryption compatibility here.
Related resources
- MongoDB TLS configuration — Read step-by-step documentation on configuring TLS/SSL for secure MongoDB connections.
- Encryption in transit — Learn how MongoDB encrypts data moving across networks using TLS to protect sensitive information between applications and databases.
- Encryption at rest — Learn how MongoDB protects stored data with encryption at rest and key management options.
- Encrypting data in MongoDB — Overview of MongoDB data encryption capabilities for protecting sensitive data across its lifecycle.
- Queryable Encryption — Learn how MongoDB enables queries on encrypted data while keeping sensitive fields encrypted.