Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

Requirement 4 is the smallest requirement in the standard (four controls) and the easiest to test objectively, which is why assessors expect clean evidence for it.

PCI DSS v4.0.1 breaks this requirement into 2 sections containing 6 individual controls.

What this requirement is actually asking

PAN transmitted over open, public networks must be protected with strong cryptography. In practice this means TLS 1.2 or higher, with weak protocols disabled and certificates that actually validate. Early TLS has been prohibited for cardholder data since 30 June 2018.

"Strong cryptography" is not just the protocol version. A host offering TLS 1.2 while still accepting 3DES, or presenting a certificate that fails to chain to a trusted root, does not meet this requirement even though the version number looks right.

Does it apply to you?

Any transmission of PAN across a network you do not control. Internal segments are covered by other requirements, but the moment traffic crosses the internet or a wireless network, this applies.

The controls

Requirement 4 contains 6 controls across 2 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.

4.1: Governance for protecting cardholder data in transit

Control	What it requires	Guidance
4.1.1	All security policies and operational procedures that are identified in Requirement 4…	Yes
4.1.2	Roles and responsibilities for performing activities in Requirement 4 are documented, assigned…	Yes

4.2: Strong cryptography in practice, plus never sending unprotected PAN by end-user messaging

Control	What it requires	Guidance
4.2.1	Strong cryptography and security protocols…	Yes
4.2.1.1	An inventory of the entity’s trusted keys and certificates used to protect PAN during…	Yes
4.2.1.2	Wireless networks transmitting PAN or connected to the CDE use industry best practices…	Yes
4.2.2	PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies	Yes

Evidence your assessor will ask for

• Configuration or scan output per public-facing endpoint showing the protocols and cipher suites actually offered
• An inventory of the certificates in use, with issuer, expiry and the trust chain
• A documented policy prohibiting PAN in email, SMS and chat, plus the technical control that enforces it

Where this commonly fails

• Testing only the main domain and missing an API subdomain or a legacy endpoint that still accepts TLS 1.0
• Assuming a green padlock means compliant. Browsers accept configurations this requirement does not
• A certificate that validates in a browser because of a cached intermediate, but presents an incomplete chain to a direct client

How PCIComplianceHub helps

Our SSL/TLS scanner tests an endpoint against these controls directly and returns a pass or fail per control, with the raw evidence behind it. It checks the protocols offered, cipher strength, certificate validity, chain of trust and hostname match, and known transport vulnerabilities.

Scope note. It assesses the transport configuration of the endpoint you scan. Whether that endpoint is in scope for PCI DSS is your determination, and other requirements are not covered by it.

Official source

This page is original commentary. It cites requirement identifiers and the official requirement title, and does not reproduce the text of the standard. For the authoritative wording, including each testing procedure and the customized approach objective, download PCI DSS v4.0.1 (June 2024) from the PCI Security Standards Council document library.

PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site.