We use essential cookies to run this site. Analytics & marketing cookies load only with your consent — see our Cookie Policy and Privacy Policy.

Talk to an expert
PCI DSS v4.0.1 · Requirement 4 of 12

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Short but unforgiving: PAN over open or public networks travels under strong cryptography, and v4 added a certificate inventory so "we use TLS" becomes provable. The findings live at the edges — legacy endpoints, wireless, and people emailing card numbers.

Reviewed by Abhay Singh, PCI SSC-qualified QSA professional · CyberSigma is a PCI SSC-listed QSA company · Part of the Requirement 1–12 series

The controls that decide your assessment

4.2.1
Strong cryptography on open/public networks

PAN transmissions over open networks use strong cryptography with trusted keys and certificates, accepting no downgrade to insecure versions (TLS 1.2+ in practice).

4.2.1.1
Inventory of trusted keys and certificates

A maintained inventory of the keys and certs protecting PAN in transit — issuer, expiry, strength. New in v4, fully effective 31 March 2025.

4.2.1.2
Wireless transmitting PAN uses strong crypto

Wireless networks carrying PAN use industry best-practice authentication and transmission encryption — WEP/WPA legacy modes are automatic findings.

4.2.2
PAN secured in end-user messaging

PAN sent via email, chat or SMS must be protected with strong cryptography — in practice: blocked by DLP and replaced with secure channels.

Control numbers reference PCI DSS v4.0.1 (June 2024). Verify wording against the standard itself — PCI SSC document library.

Where programmes actually fail

TLS 1.0/1.1 still answering on legacy endpoints

External scans find the forgotten API host or callback URL negotiating old TLS. Configuration must refuse downgrade, not just prefer 1.2.

Self-signed and expired certificates untracked

Without the 4.2.1.1 inventory, cert expiry becomes an outage AND a finding. The inventory is now the evidence of control.

Card numbers in support email

Customers email PANs; agents forward them. Without DLP quarantine + a redaction procedure, this is a live 4.2.2 failure and a Requirement 3 storage problem in mailboxes.

Evidence a QSA accepts

A policy document proves intent; configuration proves control. Bring these to the assessment:

  • External/internal TLS scan results for every PAN-transmitting endpoint
  • Certificate and key inventory with expiry and algorithm strength (4.2.1.1)
  • Wireless configuration showing strong authentication and encryption
  • DLP policy and quarantine records for PAN in messaging channels

Requirement 4 FAQ

Is TLS 1.2 mandatory?

The standard mandates "strong cryptography" rather than a version; early TLS/SSL are documented as insecure, so TLS 1.2+ with strong ciphers is the accepted implementation.

Does Requirement 4 apply inside our private network?

Requirement 4 targets open/public networks. Internal transmission is addressed through scoping and other requirements — but wireless is treated as untrusted unless proven otherwise.

Can customers send us their card number by email?

You cannot prevent what customers send, but you must not solicit PAN via messaging, and inbound PAN must be protected/purged — DLP, redaction and secure-channel alternatives are the assessable controls.

← Requirement 3: Protect Stored DataRequirement 5: Anti-Malware →

Requirement 4 in your environment

A PCI SSC-listed QSA firm can tell you in one session whether your controls will survive assessment — before the assessment.