TL;DR
- Requirement 4 protects cardholder data while it moves across open, public, and untrusted internal networks using strong cryptography such as TLS 1.2 or higher.
- PCI DSS v4.0.1 widened the scope beyond public networks, so internal segments carrying cardholder data now need the same level of encryption discipline.
- Weak ciphers, unmanaged certificates, and unencrypted PAN sent through email or chat remain the top reasons assessors flag this requirement during audits.
What Is PCI DSS Requirement 4?
PCI DSS Requirement 4 protects cardholder data by mandating strong cryptography whenever that data is transmitted across open, public, or untrusted networks. It exists because data in transit is exposed to a different set of threats than data sitting in a database. An attacker who intercepts an unencrypted transmission can read, alter, or replay it without ever breaching a firewall or endpoint.
Under PCI DSS, this requirement sits within the broader goal of protecting account data, alongside Requirement 3, which governs data at rest. Together, they form the backbone of cardholder data protection across its entire lifecycle. For governance leaders, Requirement 4 is often where risk assessments reveal blind spots, since teams tend to focus heavily on storage security while underestimating how many systems quietly transmit PAN in the background.
What Does Requirement 4 Actually Require Organizations To Do
Requirement 4 requires organizations to identify every point where cardholder data is transmitted, apply strong cryptography and security protocols at each point, and document the policies that govern this protection. It breaks down into a few operational obligations.
- Maintain an inventory of all transmission points, built from data flow diagrams created under Requirement 1.
- Apply strong cryptography such as TLS 1.2 or higher, SSH-2, or IPsec to every transmission over an open or untrusted network.
- Never send unprotected primary account numbers through end-user messaging technologies like email, SMS, or chat.
- Review cryptographic cipher suites and protocols at least once a year to confirm they still meet current strength standards.
- Assign clear ownership for encryption configuration so it does not default to whatever a vendor ships out of the box.
These obligations sound straightforward, but the operational reality is harder. Certificates expire, cipher suites drift out of date, and new integrations get spun up without anyone checking whether the connection is encrypted end to end.
What Counts As Strong Cryptography Under PCI DSS 4.0.1
Strong cryptography under PCI DSS 4.0.1 means encryption algorithms and protocols that are widely tested, peer reviewed, and free of known exploitable weaknesses. In practical terms, this means TLS 1.2 or 1.3 for web and API traffic, SSH-2 for administrative connections, and IPsec for site-to-site tunnels. SSL and early TLS versions no longer qualify and must be disabled wherever cardholder data touches the connection.
Key length matters as much as protocol choice. A 128-bit or higher key for symmetric algorithms and appropriately sized asymmetric keys are the accepted baseline. The NIST guidelines on TLS implementation offer a useful technical reference for teams configuring these settings, since PCI DSS itself intentionally avoids prescribing exact cipher lists that would quickly go stale.
Where Does Cardholder Data Typically Travel Across Open Networks
Cardholder data typically travels across open networks whenever it moves between a merchant’s systems and a payment processor, between branch locations over the internet, or through wireless networks connected to the cardholder data environment. It also travels internally more often than most teams assume.
- Point-of-sale devices sending authorization requests to a payment gateway.
- Web applications submitting checkout data to a hosted payment page.
- Backup and replication traffic moving between data centers.
- Support and helpdesk tools where agents may reference card details.
- Wireless access points inside retail or office locations connected to the cardholder data environment.
PCI DSS 4.0.1 makes clear that any of these paths, public or internal, bring the connected network into scope. This is a meaningful shift from earlier thinking that treated internal networks as inherently trusted.
What Changed In Requirement 4 Between PCI DSS 3.2.1 And 4.0.1
The core change in Requirement 4 between version 3.2.1 and 4.0.1 is scope expansion. The older standard focused almost entirely on open, public networks. The current standard extends strong cryptography expectations to any network segment where cardholder data could be exposed to an untrusted party, including certain internal environments.
Version 4.0.1 also formalized the requirement to document and review cryptographic cipher suites and protocols annually, rather than treating encryption configuration as a set-and-forget task. This annual review requirement pushes organizations toward continuous validation instead of point-in-time compliance, which aligns with the broader shift across PCI DSS 4.0.1 toward ongoing security monitoring. Full technical detail on every change is available in the PCI SSC Document Library.
How Do Wireless Networks And End User Messaging Fit Into Requirement 4
Wireless networks and end-user messaging fit into Requirement 4 because both are common, overlooked channels for cardholder data leakage. Any wireless network transmitting PAN or connected to the cardholder data environment must use industry-accepted strong cryptography for both authentication and transmission. Legacy protocols like WEP are explicitly disallowed.
End-user messaging technologies, including email, SMS, chat, and instant messaging, present a different risk. These tools were never designed to carry sensitive financial data, and they rarely encrypt content by default. PCI DSS requires that PAN sent through these channels either be strongly encrypted or rendered unreadable before it leaves the sender’s system. This is precisely the scenario from the earlier support-desk example, and it remains one of the most common informal workarounds that puts organizations out of compliance without anyone realizing it.
How Can Organizations Build A Sustainable Compliance Process For Requirement 4
Organizations can build a sustainable compliance process for Requirement 4 by treating encryption as a default architectural decision rather than an audit requirement to satisfy once a year. This starts with accurate, current data flow diagrams, followed by centralized certificate and cipher suite management, and closes with regular internal testing rather than waiting for the assessor’s visit.
Teams building secure payment software from the ground up should also align this work with the PCI Software Security Framework, which addresses cryptography earlier in the development lifecycle. A mature program treats Requirement 4 not as an isolated checklist item but as part of a wider governance structure that connects encryption, access control, and monitoring, similar to the controls organizations already maintain under SOC 2.
Ready to close the gaps in your cardholder data protection before your next assessment?
| Talk to Ampcus Cyber’s PCI team for a compliance strategy session built around your actual data flows. |
People Also Ask:
Does Requirement 4 apply to internal networks?
Yes. PCI DSS 4.0.1 extended strong cryptography expectations to internal network segments that could be exposed to untrusted parties, not just public networks.
Is TLS 1.1 acceptable under PCI DSS Requirement 4?
No. TLS 1.1 and earlier versions, along with SSL, are considered weak cryptography and do not meet current PCI DSS standards.
Can cardholder data be sent by email if it is encrypted?
Technically yes, but only if the data and any attachments are strongly encrypted before sending, and the encryption keys are managed securely and separately from the message itself.
Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.
