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

PCI DSS v4.0.1 Requirement 4: strong cryptography for cardholder data in transit over public networks, what counts as strong, and how to evidence it.

PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1

Requirement 4 is the smallest requirement in the standard (six controls) and its core control, 4.2.1, can be checked directly against each endpoint that carries PAN.

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. SSL and early TLS are not accepted as strong cryptography. The one exception is card-present POS POI terminals verified as not susceptible to known exploits, and the termination points they connect to, under Appendix A2.

"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?

PAN sent over open, public networks such as the internet, Wi-Fi, Bluetooth, cellular and satellite links (4.2.1), and PAN sent by email, chat or any other end-user messaging, on any network (4.2.2). Encrypting PAN on internal networks is not required by 4.2.1 but is good practice, and an internal network that carries cardholder data is in scope for the other requirements.

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 process for securing PAN with strong cryptography whenever it is sent by email, SMS or chat, and the system configuration that does it (4.2.2)

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 4.2.1 directly and returns a pass or fail per check, with the raw evidence behind it. It checks the protocols offered, cipher strength, certificate validity, chain of trust and hostname match.

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.

Terms

Glossary entries that name a control in this requirement:

Official source

The commentary on this page is our own. The requirement title, and the control text in the tables above (shortened where it ends in an ellipsis), are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. Each control's own page carries its requirement text in full. For the authoritative wording, including each testing procedure and the customized approach objective, download the standard 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.