How cryptography protects data in transit

How cryptography protects data in transit

When we talk about information security, it is common to think of antivirus, firewalls and strong passwords. But there is a critical moment when data is especially exposed: while it is “travelling” across the network, leaving one device and reaching another. This is what we call data in transit.

Website forms, financial transactions, APIs, chat messages, corporate e-mails, integrations between systems… all of these involve data leaving point A and reaching point B. If this path is not protected, an attacker can intercept, modify or copy that information.

This is where encryption in transit comes in: it creates a “secure tunnel” between the endpoints of the communication, making life much harder for anyone trying to snoop on the traffic. In this article, we will look at:

• What data in transit is and why it is so attractive to attackers;
• The main risks on local networks, the internet and public Wi-Fi;
• How cryptography (TLS/HTTPS, VPNs, end-to-end encryption) protects this traffic;
• Good practices and a checklist for organisations that want to raise their protection level.

1. What is data in transit?

Put simply, data in transit is information being transmitted between systems, devices or services. Some typical examples:

• You access internet banking in your browser and your account balance is sent from the server to your computer;
• A mobile app sends your credentials to an authentication API;
• Two microservices talk to each other in a cloud architecture;
• An employee accesses a company system over public Wi-Fi at the airport;
• An internal system sends logs to an observability platform in the cloud.

This data leaves one point, travels through a network (local network, internet, VPN, etc.) and reaches its destination. Along the way, it may pass through various routers, switches, proxies, firewalls and other equipment. If the traffic is not protected, any compromised intermediate point — or poorly configured network — can become a window for spying.

2. Why is data in transit such a target?

From an attacker’s point of view, intercepting data in transit can be “simpler” than directly breaking into a server or database. Some reasons:

• Open or poorly configured Wi-Fi networks expose the traffic of unsuspecting users;
• Compromised devices (routers, proxies, switches) can mirror traffic to the attacker;
• Packet-capture tools (sniffers) make it easy to observe everything flowing over an unprotected network;
• Man-in-the-Middle (MITM) attacks can position themselves between the user and the service, pretending to be each side to the other.

In a scenario without encryption, this means direct access to:

• Usernames and passwords entered in forms;
• Credit card numbers and banking data;
• Session tokens and authentication cookies;
• Documents, messages and files sent over the network.

Even inside a corporate network, assuming that “the internal network is safe” is a dangerous mistake. Insider threats, compromised devices and unauthorised access can all exploit unencrypted internal traffic.

3. Main risks for data in transit

3.1 Network sniffing

Sniffing is the practice of capturing data packets as they pass through the network. On networks without encryption (or with old protocols such as plain HTTP or FTP), an attacker can:

• Read request and response content in clear text;
• Identify credentials, ID numbers and sensitive information;
• Map which systems and services are being used.

Tools for this type of capture are widely known and available. That is why unprotected traffic is such an easy target.

3.2 Public Wi-Fi and unknown networks

Connecting to public Wi-Fi (airports, cafés, hotels) or unknown networks is a classic risk. In many cases, internal traffic on the network is not isolated, which allows:

• Other users on the same network to monitor the traffic of connected devices;
• An attacker to set up a rogue access point imitating the official network;
• Packets to be routed through misconfigured or compromised equipment.

If the user accesses services without proper encryption, the risk of exposure is high.

3.3 Man-in-the-Middle (MITM) attacks

In a Man-in-the-Middle attack, the attacker inserts themselves between the client and the server, causing:

• The user to believe they are talking to the legitimate server;
• The server to believe it is talking to the legitimate user;
• In the middle, the attacker to read, alter or log all traffic.

Without proper encryption and identity verification (such as trusted certificates), it is difficult to detect this type of attack. In some scenarios, the attacker may also attempt to downgrade the connection to weaker protocols or strip out the encryption layer altogether (SSL stripping).

3.4 Legacy protocols and weak configurations

Even when encryption is present, old or poorly configured protocols can undermine protection. Examples include:

• Use of obsolete SSL/TLS versions (such as SSLv3 and TLS 1.0/1.1);
• Support for weak cipher suites or broken algorithms;
• Insufficient certificate verification, allowing connections to fake certificates.

In such cases, an attacker can exploit known vulnerabilities or trick the client into accepting untrusted connections.

4. How does cryptography protect data in transit?

The central answer is: by creating encrypted, authenticated communication channels, ideally anchored in a chain of trust. The main examples are:

• TLS/HTTPS (for the web, APIs and many application-level protocols);
• VPNs (to build secure tunnels over insecure networks);
• End-to-end encryption (E2EE) in messaging and communications;
• TLS between services in microservice architectures.

4.1 TLS and HTTPS: the standard for a secure web

When you see the padlock in your browser and the address starts with https://, it means the connection is using TLS (Transport Layer Security). In simplified terms, this is what happens:

1. The browser connects to the server and asks to start a secure session;
2. The server presents a digital certificate, issued by a trusted certificate authority;
3. The browser validates this certificate (trust chain, validity, domain name);
4. Client and server negotiate algorithms and securely exchange secrets, usually using asymmetric cryptography to establish a symmetric session key;
5. From that point on, traffic is encrypted with symmetric cryptography (fast and efficient) using the shared key.

As a result, even if someone captures the packets on the network, they will see only encrypted data — with no direct access to the content. In addition:

• Certificate validation helps ensure you are talking to the right server;
• Additional mechanisms (such as HSTS) make it harder for attacks that try to force the use of insecure HTTP.

4.2 VPNs: building a secure tunnel over insecure networks

A VPN (Virtual Private Network) creates an encrypted tunnel between the user’s device and a remote network (such as the company network). This tunnel:

• Encapsulates all (or part of) the traffic inside an encrypted “envelope”;
• Protects data even on public Wi-Fi or hostile environments;
• Allows the user to access internal resources as if they were physically on the corporate network.

Modern VPN protocols use strong encryption (such as AES or ChaCha20) and combine symmetric and asymmetric keys to set up and maintain the secure channel. This drastically reduces the risk of sniffing and MITM on intermediate networks.

4.3 End-to-end encryption (E2EE)

With end-to-end encryption, data is encrypted on the source device and only decrypted on the destination device. Even the intermediate server does not have access to the content in clear text.

This model is used in many secure messaging apps and voice/video calling services. Its advantages include:

• Even if the server is compromised, the attacker does not gain direct access to message content;
• Reduced risk of interception by intermediaries along the path;
• Stronger privacy for users and greater trust in the platform.

E2EE combines asymmetric cryptography (to exchange keys between users) and symmetric cryptography (to protect the content of each message efficiently).

4.4 TLS between services and APIs

It is not just traffic between user and website that needs protection. In cloud and microservice environments, it is essential to encrypt:

• Communication between internal and external APIs;
• Integrations with partners and third parties;
• Traffic between services in clusters and containers.

Here, the use of mTLS (mutual TLS) is a best practice: both client and server present certificates, ensuring that each side is who it claims to be. This prevents a malicious service from impersonating a legitimate component in the architecture.

5. Good practices for using encryption in transit correctly

Simply “turning on HTTPS” is not enough. Some important good practices include:

5.1 Use modern TLS versions and strong ciphers

• Disable legacy protocols (SSLv3, TLS 1.0, TLS 1.1);
• Prioritise TLS 1.2 and 1.3 with modern ciphers (AES-GCM, ChaCha20-Poly1305);
• Avoid algorithms and modes considered weak or obsolete;
• Apply hardening guidelines for TLS configuration.

5.2 Manage digital certificates properly

• Issue certificates from trusted certificate authorities;
• Automate renewal (to avoid unexpected expiry);
• Protect private keys associated with certificates;
• Avoid indiscriminate sharing of certificates across many services without control.

5.3 Adopt HSTS and solid configurations in web applications

• Enable HSTS (HTTP Strict Transport Security) to force HTTPS usage;
• Automatically redirect HTTP traffic to HTTPS;
• Avoid mixed content, where parts of the page are loaded over HTTP.

5.4 Encrypt “internal” traffic as well

Avoid the mindset that “inside the data centre” or “inside the VPC” everything is trustworthy. Good practices include:

• Use TLS between internal services and databases where possible;
• Protect queues, message buses and sensitive logs in transit;
• Treat the internal network as an environment that can be exploited, adopting a Zero Trust mindset.

5.5 Consider the endpoint too

Encryption in transit protects the path, but if the source or destination device is compromised, an attacker can capture data before it is encrypted or after it is decrypted. That is why it is important to:

• Keep devices updated and protected (patching, antivirus, EDR, MDM);
• Train users about phishing, malware and social engineering scams;
• Control access and privileges on devices handling sensitive data.

6. Connection to LGPD, GDPR and compliance

Data protection laws such as LGPD in Brazil and GDPR in Europe require organisations to adopt appropriate technical and organisational measures to protect personal data.

Encryption in transit is a central part of this protection because it:

• Reduces the risk of personal data exposure on internal and external networks;
• Helps demonstrate due diligence in audits and investigations;
• Complements controls such as authentication, authorisation, logging and monitoring.

Although encryption alone does not guarantee compliance, the lack of it in critical scenarios can be seen as negligence — especially when the risk is well known and the solutions are widely available.

7. Practical checklist: where to start

If your organisation wants to strengthen the protection of data in transit, use this checklist as a starting point:

1. Map data flows in transit
   • Which systems exchange data with each other (internal, external, partners)?
   • Which flows involve personal data or sensitive information?
2. Check use of HTTPS/TLS
   • Do all exposed websites and APIs use HTTPS?
   • Is there automatic redirection from HTTP to HTTPS?
3. Review TLS versions and ciphers
   • Are legacy protocols disabled?
   • Do cipher suites follow current security recommendations?
4. Strengthen remote access
   • Do staff access internal systems via a secure VPN?
   • Is corporate Wi-Fi segmented and protected with strong encryption?
5. Protect communication between services
   • Do microservices and databases use TLS?
   • Do sensitive integrations with third parties use mTLS or equivalents?
6. Manage certificates professionally
   • Is there an inventory of certificates and keys?
   • Is renewal automated and monitored?
7. Train teams
   • Do developers know best practices for HTTPS, secure APIs and crypto libraries?
   • Do infrastructure teams know how to configure TLS and VPNs securely?

8. Conclusion: protecting the path is as important as protecting the destination

Protecting only the server or the database is not enough if, along the way, data travels in clear text. Encryption in transit is what ensures that sensitive information cannot be read or altered by those “listening” to the network.

By combining well-configured TLS/HTTPS, secure VPNs, end-to-end encryption where it makes sense, and solid practices for managing certificates and keys, your organisation can significantly reduce the risk of leaks and interception-based attacks.

In a world where privacy, trust and compliance with LGPD/GDPR are competitive advantages, investing in the protection of data in transit is no longer optional — it is a basic requirement for any serious digital operation.

Extra tip: if you are already improving the protection of data in transit, it is worth looking at the full data journey as well: collection, storage, use, sharing and disposal. Data governance platforms and personal-data control solutions help connect the technical security layer with policies, records and transparency for data subjects.