PCI DSS Requirement 4: encryption in transit
By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 2 min read · PCI DSS
Requirement 4 is short and mostly uncontroversial, with one clause that catches organisations repeatedly: nobody may send a PAN over chat, SMS, or email.
What counts as an open public network
The internet, wireless technologies including Wi-Fi and Bluetooth, cellular technologies, and satellite communications. The definition matters because it sets the boundary of the requirement — traffic that never leaves a controlled internal network is out of Requirement 4's direct scope, though Requirement 2.2.7 still requires encryption of non-console administrative access.
In cloud environments the boundary is less obvious than it looks. Traffic between availability zones or between your VPC and a managed service may traverse infrastructure you do not control. Most organisations resolve this by encrypting everything in transit regardless, which is simpler to defend than an argument about where the provider network boundary sits.
Strong cryptography in practice
Requirement 4.2.1 requires that only trusted keys and certificates are accepted, that the protocol supports only secure versions and configurations, and that the encryption strength is appropriate. In practice this means TLS 1.2 as a floor with TLS 1.3 preferred, insecure ciphers disabled, and no fallback to earlier protocol versions.
Certificates must be valid and not expired or revoked. This sounds trivial until an expired internal certificate is discovered mid-assessment on a system nobody owned.
The certificate inventory
Requirement 4.2.1.1, added in v4.0, requires an inventory of the trusted keys and certificates used to protect PAN during transmission, kept current. This is a paperwork requirement with a real operational payoff — most organisations that build the inventory discover certificates they did not know existed, and expiry dates they were not tracking.
Automated certificate management largely solves the underlying problem, but the inventory requirement remains: you still need to be able to produce the list.
The clause that catches people
Requirement 4.2.2 states that PAN must never be sent unprotected by end-user messaging technologies — email, instant messaging, SMS, chat. This is not a systems requirement; it is a people requirement, and technical controls only partly address it.
The realistic failure mode is a customer emailing their card number to support, or a support agent asking for it over chat. You cannot prevent the customer doing it, but you can control what happens next: a documented process for handling inbound PAN in messages, DLP rules that detect and quarantine it, agent training that never asks for full PAN, and evidence that the process is followed. Assessors ask about this specifically because it is where policy and reality most often diverge.