The moment a PAN leaves the secure boundary of one system and travels to another, it is exposed to interception unless protected by strong cryptography. Requirement 4 mandates encryption of cardholder data in transit — not just when traversing the internet, but any time it crosses an open, public, or untrusted network.
What "Open, Public Networks" Means
PCI DSS Requirement 4.2 applies to CHD transmitted over "open, public networks" — the internet, wireless technologies, cellular/mobile technologies, Bluetooth, GPRS, satellite, general packet radio service, and dial-up. Internal private networks that are properly segmented may transmit CHD without encryption (though encryption is still recommended). When in doubt, encrypt.
| KEY IDEA | The "open, public network" scope of Requirement 4 is broader than most organizations initially assume. A payment terminal connecting to a payment gateway over cellular networks, a mobile POS app transmitting over Wi-Fi, and a payment page form submitting over the internet are all in scope for Requirement 4. Any CHD transmission that crosses a boundary you do not fully control requires strong cryptography. |
TLS Requirements — What Is Acceptable in 2026
Transport Layer Security (TLS) is the primary mechanism for encrypting data in transit. PCI DSS has progressively tightened TLS requirements.
| Protocol/Version | PCI DSS Status | Notes |
|---|---|---|
| TLS 1.3 | Accepted — preferred | Best available; removes deprecated cipher suites; recommended for all new implementations |
| TLS 1.2 | Accepted — with restrictions | Must be configured with strong cipher suites; no RC4, DES, 3DES, EXPORT ciphers |
| TLS 1.1 | Not accepted | Retired in PCI DSS — must be disabled |
| TLS 1.0 | Not accepted | Retired in PCI DSS — must be disabled everywhere in the CDE |
| SSL (all versions) | Not accepted | Retired — SSL v2 and v3 are critically vulnerable; must be disabled |
| PCT (Private Communications Technology) | Not accepted | Legacy Microsoft protocol; must be disabled |
| IMPORTANT | TLS 1.0 and all SSL versions must be disabled entirely in the CDE — not just for CHD transmission, but for all connections. Many servers maintain SSL/TLS 1.0 compatibility for legacy clients. A QSA will test all services on CDE systems for SSL/TLS version support. Finding TLS 1.0 enabled on any port of any CDE system — even a monitoring agent — is a finding. |
Certificate Management
Certificates used for CHD transmission must be valid (not expired), issued by a trusted certificate authority, and managed through a documented certificate lifecycle process. Self-signed certificates are generally not acceptable for external-facing payment services. Certificate pinning may be required for mobile payment applications.
No Unprotected PANs in Messaging Technologies
Requirement 4.2.2: The PAN must never be sent in unprotected form via end-user messaging technologies — email, instant messaging, SMS, chat. This prohibition is absolute. Organizations that send PANs via email (even internally) or include them in support tickets, chat messages, or other messaging systems must remediate this.
| The prohibition on PANs in email is one of the most commonly violated Requirement 4 controls — not through malicious intent but through operational convenience. Support teams that request card details via email, or developers who log PANs in error reports sent via email, are creating Requirement 4 violations. Training and technical controls (DLP) are both needed. |
Wireless Transmission of CHD
When CHD is transmitted over wireless networks (Wi-Fi, Bluetooth, NFC), strong cryptography is required. WPA3 is the current standard. WPA2 with specific cipher configurations may be acceptable. WPA and WEP are not acceptable. NFC communications for contactless payments must use encryption as defined by the EMV contactless specifications.
Inventory of Trusted Keys and Certificates
New in v4.0: organizations must maintain an inventory of all trusted keys and certificates used for CHD transmission. This inventory must include the algorithm, key length, expiration date, and purpose of each certificate/key.
| Certificate inventory management is a new v4.0 requirement that catches many organizations off guard. Most organizations have more certificates than they realize — load balancers, internal services, API gateways, monitoring agents. A certificate management platform (or at minimum a maintained spreadsheet with renewal alerts) is now a PCI DSS compliance requirement, not just a good practice. |