PCI DSS 4.2.1: Strong cryptography and security protocols
PCI DSS v4.0.1 control 4.2.1: the requirement in full, the 4 testing procedures an assessor uses to verify it, and the related controls in section 4.2.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks › Section 4.2
Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:
- Only trusted keys and certificates are accepted.
- Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until its effective date; refer to applicability notes below for details.
- The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
- The encryption strength is appropriate for the encryption methodology in use.
Summary
Every place PAN crosses a public network must use strong TLS with valid, trusted certificates, and must refuse to fall back to anything weaker.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 4.2.1.a | Examine documented policies and procedures and interview personnel to verify processes are defined to include all elements specified in this requirement. |
| 4.2.1.b | Examine system configurations to verify that strong cryptography and security protocols are implemented in accordance with all elements specified in this requirement. |
| 4.2.1.c | Examine cardholder data transmissions to verify that all PAN is encrypted with strong cryptography when it is transmitted over open, public networks. |
| 4.2.1.d | Examine system configurations to verify that keys and/or certificates that cannot be verified as trusted are rejected. |
Four procedures, and they test different things. 4.2.1.a reads your documentation; 4.2.1.b reads your configuration; 4.2.1.c looks at actual transmissions; 4.2.1.d specifically tests that untrusted keys and certificates are rejected. Passing the documentation test and failing the configuration test is the normal shape of a finding here. Note also that the second bullet, on confirming certificates are valid and not expired or revoked, was a future-dated best practice and is now in force.
What to prepare
- An inventory of every endpoint that transmits PAN over a public network, including APIs, webhooks, batch file transfers and anything a partner connects to.
- Scan or configuration output per endpoint showing the protocol versions and cipher suites actually offered, not the intended ones.
- Certificate details per endpoint: issuer, expiry, and evidence the chain validates.
- Evidence that clients reject untrusted certificates, which is the part of 4.2.1.d most often missed on outbound connections your own code makes.
How to implement it
1. Enumerate the endpoints before configuring anything. The failure is almost never the main website. It is the legacy API subdomain, the partner SFTP host, or a webhook receiver that nobody listed as in scope. Anything that carries PAN across a network you do not control belongs here.
2. Disable early TLS and weak ciphers, then verify from outside. TLS 1.0 and 1.1 have been prohibited for cardholder data since 30 June 2018. Configuration intent is not evidence: test what the host actually negotiates, because a load balancer or CDN in front of your server may offer more than your server does.
3. Check the certificate chain, not just the padlock. A browser may accept a certificate because it cached an intermediate from another site. A direct client with no cache will not. Verify the server presents its full chain.
4. Do not forget the outbound direction. 4.2.1.d is about rejecting keys and certificates that cannot be verified as trusted. Application code that disables certificate verification to make an integration work is the classic failure, and it is invisible until someone reads the code.
Where this commonly fails
- Testing only the primary domain and missing an API subdomain that still accepts TLS 1.0.
- A host that offers TLS 1.2 but also still accepts 3DES, which is not strong cryptography.
- Certificate verification disabled in application code or an HTTP client library, so the service accepts any certificate presented to it.
- Relying on a green padlock in a browser as evidence, when browsers accept configurations this requirement does not.
How PCIComplianceHub helps
Our SSL/TLS scanner tests an endpoint against this control directly and returns a pass or fail per check with the evidence behind it: the protocols offered, cipher strength, certificate validity, chain of trust, hostname match, and known transport vulnerabilities. That covers the configuration side of 4.2.1.b and 4.2.1.c for the endpoint you scan. It cannot see your outbound client behaviour, so 4.2.1.d still needs a code and configuration review.
Signed in, you can retrieve your organisation's evidence for 4.2.1 as JSON: what the scanner has recorded, with the scope note above attached to it.
Related controls
Others in section 4.2:
| Control | What it requires |
|---|---|
| 4.2.1.1 | An inventory of the entity’s trusted keys and certificates used to protect PAN during… |
| 4.2.1.2 | Wireless networks transmitting PAN or connected to the CDE use industry best practices… |
| 4.2.2 | PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies |
← 4.1.2 · All controls · 4.2.1.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it 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. Nothing here is a substitute for advice from a Qualified Security Assessor.