Encrypt cardholder data in transit
Requirement 4 requires that primary account numbers (PAN) are encrypted using strong cryptography and secure protocols whenever they are transmitted over open, public networks. The goal is to ensure that if data is intercepted during transit, it remains unreadable to unauthorized parties.
What it means
The intent of this control is to prevent "man-in-the-middle" attacks and packet sniffing. When cardholder data leaves your secure environment—such as when a payment is sent from a web server to a payment processor via the internet—it travels through infrastructure you do not control. Without encryption, this data is transmitted in plain text and can be easily stolen.
In practice, this applies to all public networks (the internet, cellular networks) and wireless networks. While PCI DSS focuses heavily on these untrusted paths, many organizations apply these same standards to internal traffic as a defense-in-depth measure. You must ensure that the encryption used is "strong," meaning it meets current industry standards for algorithms and key lengths.
How to meet it
- Implement strong security protocols such as TLS 1.2 or TLS 1.3 for all transmissions of cardholder data over public networks.
- Disable outdated or weak protocols, including SSL and early versions of TLS (e.g., TLS 1.0 and 1.1), on all servers and endpoints.
- Configure cipher suites to prioritize strong encryption algorithms and disable known weak ciphers (such as RC4 or DES).
- Use certificates from trusted Certificate Authorities (CAs) to verify the identity of the communicating endpoints.
- Ensure that PAN is never sent unencrypted via end-user messaging technologies, such as email, SMS, or instant messaging; if necessary, use a separate encryption layer for these messages.
- Maintain an inventory of all data flows where cardholder data is transmitted across public networks to ensure no gaps in coverage exist.
Evidence an auditor asks for
- A documented data flow diagram showing exactly where PAN travels and the protocols used at each hop.
- Configuration files or screenshots from load balancers, firewalls, or web servers proving that only strong TLS versions are enabled.
- An inventory of certificates including their expiration dates and the process used for renewal.
- Results from a vulnerability scan or an external tool (like SSL Labs) demonstrating that weak ciphers are disabled on public-facing endpoints.
Common pitfalls
- Maintaining "backward compatibility" by leaving old versions of TLS enabled, which creates a security hole that auditors will flag.
- Overlooking internal wireless networks, treating them as "safe" when they should be treated with the same rigor as public networks.
- Allowing employees to send PAN via email or chat for customer support purposes without using an approved encryption method.
- Failing to track certificate expiration dates, leading to service outages or the use of self-signed certificates in production.