Priya Nandakumar had run payment security at Solstice Outfitters for four years, and she thought she'd seen every way a $340-million-a-year omnichannel retailer could put a primary account number (PAN) where it didn't belong. Then her QSA's evidence request came back with a screen recording from the call center: a customer service rep, following a "temporary workaround" scrawled on a sticky note taped to her monitor, asking a customer to email a photo of the front and back of his card because the phone system's DTMF masking had glitched. The email — unencrypted, sitting in a shared inbox with eleven months of history — contained forty-three similar messages, cardholder photos included.
The QSA hadn't even gotten to the second finding yet: Solstice's legacy checkout page, built for a POS integration project that predated Priya's tenure, still negotiated TLS 1.0 for a small percentage of older in-store tablets. Between the two findings, Solstice was staring at a Report on Compliance that couldn't be signed off, an acquiring bank conversation about elevated transaction fees, and — because both issues touched the transmission of unencrypted PAN over an open, public network — a card-brand fine exposure her CFO estimated at $500,000 before anyone even talked about the cost of a forensic investigation if a card number had been intercepted in transit. Requirement 4 is often the shortest section in a PCI DSS gap assessment. It is rarely the cheapest to get wrong.
This is the article I wish had existed when Priya's team started remediating. It walks through PCI DSS v4.0.1 Requirement 4 exactly as the standard defines it — protecting cardholder data with strong cryptography during transmission over open, public networks — with the protocol decisions, certificate and key trust controls, end-user messaging restrictions, and wireless transmission rules that turn a QSA's "explain your encryption in transit" question into a five-minute walkthrough instead of a scramble.
Who This Is For / What You'll Walk Away With
This is written for the people who own Requirement 4 in practice: payment security leads, network architects, QSAs and ISAs prepping evidence, e-commerce and call-center engineering leads, and compliance managers translating "encrypt PAN in transit" into actual TLS configuration and certificate governance. You'll walk away with the exact sub-requirement structure of Requirement 4 (4.1 through 4.2.2), a working definition of "open, public network" that holds up under QSA scrutiny, protocol and cipher-suite guidance that won't get flagged in a later ASV scan, the certificate/key trust inventory 4.2.1.1 actually requires, the end-user messaging rules that stop PAN from leaking through email and chat, and the evidence package an assessor will ask you to produce. No filler, no restating the standard's plain-English summary as if that were implementation guidance.
What PCI DSS Requirement 4 Actually Says
Requirement 4 sits under Goal 2 — Protect Account Data — alongside Requirement 3, which governs how cardholder data is protected at rest. Where Requirement 3 asks "what happens to card data sitting in your database," Requirement 4 asks "what happens to card data the instant it leaves a trusted network and crosses something an attacker could realistically intercept." Put simply: Requirement 3 governs encryption at rest; Requirement 4 governs encryption in transit. The two requirements are frequently confused by teams new to PCI DSS, and QSAs will test them separately, with separate evidence.
The full text of Requirement 4 in PCI DSS v4.0.1 is "Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks." It breaks into two defined-approach requirement groups plus their associated documentation clauses. The table below is the structure every implementation plan should be built against — memorize this shape before you memorize any single control detail, because assessors organize their evidence requests around it.
Table: Requirement 4 Structure at a Glance
Clause | Plain-English Description | Applies To |
|---|---|---|
4.1 | Policies and procedures for protecting cardholder data in transit are documented, in use, and known to affected staff | All entities storing, processing, or transmitting CHD |
4.1.1 | Documented security policies and operational procedures for Requirement 4 exist, are actively used, and are known to all affected parties | Policy/process owners |
4.1.2 | Roles and responsibilities for performing Requirement 4 activities are documented, assigned, and understood | Security/network/dev teams |
4.2 | PAN is protected with strong cryptography during transmission | All PAN transmission over open, public networks |
4.2.1 | Strong cryptography and security protocols protect PAN in transit; only trusted keys/certs accepted; certs confirmed valid/not expired/not revoked; no insecure protocol fallback; encryption strength appropriate | TLS/SSH/IPsec endpoints handling PAN |
4.2.1.1 | An inventory of trusted keys and certificates used to protect PAN in transit is maintained | Certificate/key management function |
4.2.2 | PAN sent via end-user messaging technologies (email, IM, SMS, chat) is secured with strong cryptography, or PAN is never sent that way | Customer service, sales, support workflows |
Two things jump out once you see it laid out this way. First, 4.2.1 is really four sub-obligations bundled into one clause: trusted keys/certs, certificate validity checking, no insecure protocol fallback, and appropriate cryptographic strength — a QSA will test all four independently. Second, 4.2.1.1's inventory requirement is new territory for teams whose TLS "strategy" has historically been "we bought a cert and forgot about it." We'll unpack all of it below. If you're drafting the 4.1.1/4.1.2 policy and procedure documentation from scratch, our PCI DSS Policy Pack includes a Requirement 4 policy template worth adapting rather than starting from a blank page.
"The number one thing I tell clients before their first Requirement 4 assessment is: don't just show me your TLS grade from an external scanner. Show me the inventory. Show me who owns cert renewal. Show me the last time somebody actually looked at what protocol versions your load balancer will negotiate down to. The scanner tells you today's snapshot. The inventory and the process tell me whether you'll still be compliant in six months." — Marcus Webb, QSA, Ironclad Assessors LLC
Defining "Open, Public Networks" — the Trigger for Requirement 4
Requirement 4 only applies when cardholder data crosses an open, public network. That phrase is doing a lot of work, and getting the boundary wrong in either direction either creates a compliance gap (data unprotected where it should be encrypted) or wastes engineering effort (encrypting internal segments that were never in scope for this specific control). PCI DSS's own guidance is explicit that "open, public networks" include the internet, wireless technologies (including Bluetooth), cellular/mobile networks, GPRS, and satellite communications — essentially any network where traffic could realistically be intercepted, sniffed, or redirected by a party outside the organization's direct control.
The distinction that trips people up is that a network being "private" in the colloquial sense — a company-owned MPLS circuit, a site-to-site VPN, a leased line between two data centers — doesn't automatically exempt it from scrutiny, but it does move it out of Requirement 4's specific "open, public network" trigger if it meets certain isolation and access criteria. The safest posture, and the one every QSA I've worked with actually wants to see, is to encrypt PAN in transit everywhere, and reserve the "this network doesn't count as open/public" argument only for cases you can defend in writing.
Table: Open vs. Private Network Examples for PAN Transmission
Network Type | Open/Public (Requirement 4 applies) | Private/Controlled (case-by-case; document your reasoning) |
|---|---|---|
Public internet (e-commerce checkout, APIs) | Yes — always | N/A |
Consumer/guest Wi-Fi, retail store Wi-Fi | Yes — always | N/A |
Cellular/mobile data (4G/5G, mPOS over carrier network) | Yes — always | N/A |
Bluetooth (card readers, peripherals) | Yes — always | N/A |
Satellite links | Yes — always | N/A |
Third-party SaaS integrations, payment gateway APIs | Yes — always | N/A |
Site-to-site VPN over the internet | Depends — the tunnel itself must use strong crypto | Encrypted tunnel with mutual authentication can be treated as protected transmission |
Dedicated MPLS/leased circuit between owned data centers | No, if truly not routed over shared/public infrastructure | Requires network diagram + carrier attestation as evidence |
Internal LAN segment, fully isolated CDE VLAN | No | Still recommended to encrypt (defense in depth); Requirement 4 doesn't mandate it here |
Guest-accessible internal wireless bridged to CDE | Yes — treat as open/public | N/A — this is a segmentation failure, fix first |
The practical rule I give every client: if you have to think hard about whether a network counts as "open," treat it as open. The cost of encrypting a controlled segment you didn't strictly need to is a rounding error next to the cost of an assessor — or an attacker — deciding your "private" network wasn't private enough. This connects directly to the segmentation work under Requirement 1's network security controls: the tighter and better-documented your segmentation, the smaller the set of transmission paths Requirement 4 actually has to cover.
Strong Cryptography: What Passes and What Doesn't
PCI DSS doesn't hand you a single approved-protocol list frozen in time — it defines strong cryptography by reference to industry standards and explicitly disallows known-weak options. As of v4.0.1, in force through 2026, the baseline is unambiguous: SSL (all versions) and early TLS (TLS 1.0 and TLS 1.1) are prohibited as security protocols for transmitting PAN over open, public networks. This has been true since the SSL/early-TLS migration deadline passed on 30 June 2018, and v4.0.1 keeps that bar in place while sharpening the certificate-trust and inventory language around it.
Table: Approved vs. Disallowed Protocols for PAN Transmission
Protocol / Version | Status Under PCI DSS v4.0.1 | Notes |
|---|---|---|
SSL (all versions) | Disallowed | Known cryptographic weaknesses (POODLE and others); never acceptable |
TLS 1.0 | Disallowed | Deprecated industry-wide; vulnerable to BEAST and downgrade attacks |
TLS 1.1 | Disallowed | No longer considered strong cryptography by any major browser or standards body |
TLS 1.2 (with approved cipher suites) | Approved — minimum acceptable | Must disable weak ciphers (RC4, 3DES, export-grade); requires forward secrecy where possible |
TLS 1.3 | Approved — preferred | Simplified handshake, removes legacy cipher negotiation, mandatory forward secrecy |
IPsec (with strong algorithms, e.g., AES-256, SHA-2) | Approved for VPN tunnels | Common for site-to-site connections carrying PAN |
SSH-2 (strong ciphers/MACs) | Approved for administrative/file transfer channels | SSH-1 disallowed |
WPA2-Enterprise / WPA3 (wireless) | Approved | WEP and WPA (original) disallowed outright |
Proprietary/undocumented "encryption" | Never acceptable as sole control | Must be strong, standards-based cryptography — not obfuscation |
The subtlety that catches experienced engineers off guard is protocol negotiation, not just protocol availability. A server can have TLS 1.2 and 1.3 enabled and still fail Requirement 4 if it also accepts a TLS 1.0 handshake from an older client for backward compatibility. That fallback path is exactly what an ASV scan and a QSA's configuration review are built to catch — and it's exactly what took down Solstice's legacy checkout page in Priya's case. "Approved protocol available" is necessary but not sufficient; "insecure protocol fallback disabled" is the actual requirement.
"I still see engineering teams treat TLS 1.0 support as a customer-service decision — 'we can't break checkout for the three percent of users on old Android browsers.' That math doesn't work anymore. Those three percent of sessions are the ones an assessor will find, and they're disproportionately the sessions running unpatched, higher-risk client software in the first place." — Liam Chen, Head of Payments Engineering, Fernway Commerce
TLS Configuration: Cipher Suites, Key Exchange, and Certificate Strength
Enabling TLS 1.2 or 1.3 is the first step, not the finish line. Requirement 4.2.1 explicitly calls out "encryption strength appropriate for the encryption methodology in use" — meaning weak cipher suites, undersized keys, and deprecated hash algorithms inside an otherwise-modern protocol version are still a finding. This is where a lot of teams discover their load balancer or CDN was configured years ago by someone optimizing for maximum client compatibility rather than security, and nobody has revisited the cipher suite order since.
Table: TLS Configuration Minimum Standards
Configuration Element | Minimum Acceptable Standard | Why It Matters |
|---|---|---|
Protocol version | TLS 1.2 minimum, TLS 1.3 preferred | Excludes known-broken handshake and cipher negotiation flaws |
Key exchange | ECDHE (elliptic curve Diffie-Hellman ephemeral) | Provides perfect forward secrecy — past sessions stay safe even if a key is later compromised |
Certificate key size | RSA 2048-bit minimum (3072+ preferred) or ECC 256-bit | Below this, brute-force/factoring risk increases materially |
Symmetric cipher | AES-128-GCM or AES-256-GCM | Authenticated encryption; avoid CBC-mode ciphers where possible |
Hash/signature algorithm | SHA-256 or stronger | SHA-1 signatures are deprecated across major browsers and PCI guidance |
Cipher suite order | Server-preferred, strongest-first | Prevents downgrade to weaker mutually-supported ciphers |
Session resumption | TLS session tickets with rotation, or disabled if unmanaged | Long-lived unrotated tickets undermine forward secrecy |
Renegotiation | Secure renegotiation only (RFC 5746) | Insecure renegotiation enables MITM injection |
HSTS (HTTP Strict Transport Security) | Enabled with appropriate max-age | Prevents protocol-downgrade / SSL-stripping attacks on web traffic |
Solstice's fix, once Priya's network architect Tobias Reyes got into the load balancer configuration, was almost anticlimactic: the legacy checkout listener had an old cipher suite list inherited from a 2019 compatibility project, TLS 1.0 was still technically negotiable for a specific user-agent allowlist nobody remembered creating, and the certificate was RSA-2048 but signed with a signature algorithm two generations out of date. None of it was exotic. All of it had been sitting there, unreviewed, because "it works" had quietly replaced "it's compliant" as the team's success criterion.
"Cipher suite review isn't a one-time project. Every major browser release, every TLS library update, every new client platform changes what 'strong' means at the margins. I put TLS configuration review on the same recurring calendar as vulnerability scanning — because functionally, it is vulnerability scanning." — Tobias Reyes, Network Security Architect, Solstice Outfitters
Certificate and Key Trust: Requirement 4.2.1's Core Test
Requirement 4.2.1 requires that "only trusted keys and certificates are accepted" and that certificates are "confirmed as valid and not expired or revoked." This sounds simple until you try to operationalize it across every system that terminates TLS for cardholder data — web servers, API gateways, load balancers, payment terminals, wireless access points, VPN concentrators, and third-party integrations. Each of those needs an answer to three questions: who issued this certificate, is it still valid right now, and would we actually notice if it stopped being valid.
Table: Certificate and Key Trust Checks
Check | What It Verifies | Common Failure Mode |
|---|---|---|
Certificate authority (CA) trust chain | Cert was issued by a trusted, publicly recognized CA (or approved internal PKI for internal-only trust) | Self-signed certs left in production "temporarily" |
Expiration monitoring | Cert has not passed its "not valid after" date | Manual renewal process misses a date; site silently falls back to insecure state or breaks |
Revocation checking (OCSP/CRL) | Cert hasn't been revoked by the issuing CA since issuance | OCSP stapling misconfigured or ignored; revoked cert still accepted |
Domain/hostname match | Certificate's Subject Alternative Names (SANs) match the domain actually being served | Wildcard cert reused across unrelated domains without review |
Key strength and algorithm | Meets current minimum standards (see TLS table above) | Legacy cert issued under older, weaker standards never reissued |
Private key protection | Private key stored in HSM or equivalent protected store, access restricted and logged | Private key sitting in a config file or shared drive |
Certificate pinning / trusted key list | Only pre-approved keys/certs are accepted by clients or internal services | No allowlist — any CA-issued cert for the right name is silently trusted |
Wildcard and multi-domain scope review | Wildcard/SAN certs are scoped as narrowly as operationally possible | Overly broad wildcard cert increases blast radius if key is compromised |
The revocation-checking column is the one most environments fail quietly. Certificate expiration is visible — a browser warning, a monitoring alert, an angry customer. Certificate revocation — where a CA has invalidated a cert early because of a compromise or misissuance — is invisible unless your clients actually perform OCSP or CRL checks and are configured to hard-fail (not soft-fail) when the check can't be completed. A soft-fail OCSP configuration, common because it's more forgiving of network blips, means a revoked certificate still gets accepted if the revocation check itself fails or times out — which is precisely the condition an attacker positioned to intercept traffic would try to create.
4.2.1.1: The Trusted Keys and Certificates Inventory
Requirement 4.2.1.1 is new-ish territory for a lot of organizations moving from PCI DSS v3.2.1 practice to v4.0.1 expectations: an inventory of the entity's trusted keys and certificates used to protect PAN during transmission must be maintained. This isn't a nice-to-have asset spreadsheet — it's a control an assessor will ask to see, cross-reference against your network diagram, and sample-test against actual production endpoints.
Table: Certificate/Key Inventory — Required Fields
Field | Purpose |
|---|---|
Asset/system name | Ties the cert to a specific server, load balancer, API gateway, or device |
Certificate common name / SANs | Identifies exactly what hostnames/services the cert covers |
Issuing CA | Confirms trust chain and helps assess CA-level risk |
Issue date and expiration date | Drives renewal scheduling and expiry alerting |
Key type and size | Confirms it meets current cryptographic strength minimums |
Private key storage location | HSM, key vault, or other protected store — never plaintext file share |
Owner / responsible team | Who gets paged when it's expiring or flagged |
Renewal process/automation status | Manual, semi-automated, or fully automated (e.g., ACME/Let's Encrypt-style) |
Last validated date | When someone last confirmed the cert is still in the trust chain and correctly configured |
Revocation status check method | OCSP stapling, CRL, or other — and hard-fail vs. soft-fail behavior |
Building this inventory is genuinely one of the highest-leverage Requirement 4 activities you can undertake, because it surfaces the certificates nobody remembers issuing — the ones on decommissioned-but-still-reachable servers, the wildcard cert someone reused for a side project, the self-signed cert a contractor left behind on a staging environment that somehow still routes production traffic under certain failover conditions. Automated discovery tooling (certificate transparency log monitoring, network-based cert scanning) closes the gap between "what we think we have" and "what's actually presenting a TLS certificate on our network" far more reliably than an annually-updated spreadsheet.
"Every inventory I've built from scratch has turned up at least one certificate nobody in the room could explain. Not malicious, usually — just orphaned. A vendor integration that got deprecated but the endpoint never got decommissioned. That's the whole point of the inventory: it turns 'we think we know what's out there' into 'we know what's out there.'" — Dana Ferreira, Director of PCI Compliance, Coastal Retail Group
End-User Messaging Technologies: Requirement 4.2.2
This is the sub-requirement that catches organizations with mature TLS practices completely off guard, because it has nothing to do with server configuration and everything to do with human workflow. Requirement 4.2.2 states that PAN must be secured with strong cryptography whenever it is sent via end-user messaging technologies — email, instant messaging, SMS, and chat are the standard's own named examples. In practice, the only defensible posture for the overwhelming majority of organizations is: never send unprotected PAN through these channels at all, because retrofitting strong cryptography onto ad hoc email and SMS is operationally and cryptographically impractical at scale.
This is exactly what took down Solstice's call center. A customer service rep, working around a DTMF-masking outage, asked customers to email photos of their cards. Standard business email — even over a TLS-encrypted mail transport between servers — does not meet this requirement, because transport encryption between mail servers protects the hop-to-hop connection, not the message content end-to-end, and it does nothing to prevent the PAN from sitting unencrypted at rest in an inbox indefinitely (which then also triggers Requirement 3 obligations).
Table: End-User Messaging — Do and Don't
Channel | Don't | Do Instead |
|---|---|---|
Ask customers to email card numbers, photos of cards, or CVV codes | Direct customers to a PCI DSS-compliant hosted payment page or IVR; if email must reference a transaction, mask all but the last four digits | |
SMS/text | Request or accept full PAN via text message | Send a secure payment link (tokenized session) instead of collecting card data via text |
Live chat / web chat | Allow chat widgets to accept typed PAN in plaintext | Route payment collection to a PCI-compliant embedded iframe/redirect, never the chat transcript itself |
Instant messaging (Slack, Teams, etc.) | Allow staff to relay customer card numbers between departments via IM | Use masked references (last 4 + transaction ID) and route full PAN only through approved payment systems |
Fax | Assume fax is "safe" by default without verifying the receiving line/process | Treat fax like any other transmission channel — verify no unprotected storage/retransmission downstream |
Call recording | Record calls without pausing/masking during PAN capture (DTMF or verbal) | Use pause-and-resume recording or DTMF masking so PAN is never captured in the recording |
Social media / DMs | Allow support staff to accept card details via social platform messaging | Explicitly prohibit in policy; redirect to secure channel every time |
The fix at Solstice wasn't technical — it was procedural and cultural. Priya's team rolled out a hosted, tokenized payment link the call center could text or read aloud a URL for, retrained the floor on a hard "we will never ask you to email or text your card number, and if someone from our company does, don't do it" script, and put a technical control in place: outbound email filtering that scans for PAN-pattern strings and blocks or quarantines matches before they leave the building. That last control — pattern-based data loss prevention (DLP) tuned for card number formats — is now standard advice I give every client working through 4.2.2, because policy alone doesn't survive a busy Tuesday and an outage.
"You can train people until you're blue in the face, but the workaround always comes back the next time there's an outage or an angry customer on the line. The technical control — the DLP rule that blocks a sixteen-digit pattern from leaving the mail server — is what actually holds when the policy doesn't." — Aisha Okonkwo, Call Center Operations Manager, BrightPath Insurance
Wireless Transmission Security
Wireless networks are explicitly named in PCI DSS's definition of open, public networks, and any wireless network that transmits cardholder data (CHD) — whether that's a wireless POS terminal, a mobile card reader, or a corporate wireless network that touches the CDE — falls squarely under Requirement 4. This is a distinct control surface from the general wireless-network-security expectations elsewhere in PCI DSS (which live mostly under Requirement 1's segmentation and Requirement 2's default-credential hardening); Requirement 4's specific concern is the cryptographic strength of the transmission itself.
Table: Wireless Transmission Security Requirements
Element | Minimum Standard | Notes |
|---|---|---|
Encryption protocol | WPA2-Enterprise (AES-CCMP) minimum; WPA3 preferred | WEP and WPA (original, TKIP) are explicitly disallowed |
Authentication | 802.1X with unique per-user/device credentials | Shared PSK across many devices increases compromise blast radius |
SSID broadcast for CDE-adjacent networks | Segregated from guest/public SSIDs entirely | CDE wireless traffic must never share a broadcast domain with guest Wi-Fi |
Bluetooth peripherals (card readers, scanners) | Bluetooth Low Energy with encryption enabled, paired devices only | Legacy Bluetooth Classic without encryption is a known interception risk |
Cellular/mPOS connections | Carrier-network TLS 1.2+/1.3 end-to-end to the payment processor | Don't rely on carrier-level encryption alone as the PAN-protection control |
Rogue AP detection | Wireless intrusion detection/prevention scanning on a defined cadence | Required activity elsewhere in PCI DSS; directly supports Requirement 4 assurance |
Default wireless configuration | No vendor-default SSIDs, keys, or admin credentials in production | Overlaps with, and is reinforced by, secure configuration standards under Requirement 2 |
For retailers running physical stores — Solstice has 220 of them — wireless mPOS and tablet-based checkout devices are usually the single riskiest transmission path in the whole environment, because store-level Wi-Fi hardware ages out of central IT's attention faster than data-center equipment does. A wireless access point installed during a five-year-old store buildout, still running firmware from that install date, quietly serving both guest Wi-Fi and a payment tablet on adjacent VLANs with a misconfigured trunk port, is a more common finding in my experience than any exotic cryptographic weakness in a modern e-commerce stack.
Where Different Payment Channels Meet Requirement 4
Requirement 4's controls land differently depending on how your organization actually captures and transmits card data. A single merchant environment often runs several of these channels simultaneously, each with its own transmission risk profile.
Table: Payment Channel Transmission Risk Matrix
Channel | Primary Transmission Path | Key Requirement 4 Controls | Typical Weak Point |
|---|---|---|---|
E-commerce checkout (hosted/redirect) | Browser to hosted payment page over TLS | TLS 1.2+/1.3, valid cert, no fallback | Legacy browser-compatibility cipher suites |
E-commerce checkout (self-hosted iframe/direct API) | Browser/server to payment gateway API over TLS | mTLS to gateway, cert pinning, key inventory | API key/cert rotation neglected |
Call center / MOTO (mail order/telephone order) | Voice + manual entry into payment terminal or virtual terminal | DTMF masking, no PAN in email/chat/notes | Workarounds during system outages |
Physical POS (wired) | Terminal to processor over dedicated/private line or encrypted tunnel | P2PE where deployed, strong crypto on any open-network hop | Store network segmentation gaps |
Physical POS (wireless/mPOS) | Terminal to processor over Wi-Fi or cellular | WPA2-Enterprise/WPA3, TLS to processor | Aging store wireless hardware |
Mobile app | App to backend API over TLS | Certificate pinning, no plaintext fallback in older app versions | Users on outdated app versions without pinning enforcement |
B2B/API integrations (partners, marketplaces) | Server-to-server over TLS or VPN | Mutual authentication, IP allowlisting, key inventory | Long-lived, unreviewed integration credentials |
Two of these deserve a specific callout because they're where scope-reduction technologies pay for themselves. Point-to-point encryption (P2PE), where card data is encrypted at the point of capture by tamper-resistant hardware and only decrypted at a secure endpoint outside the merchant environment, effectively removes the merchant's transmission path from Requirement 4's direct testing burden — it's still worth understanding the control, but a validated P2PE solution shifts much of that responsibility to the P2PE provider. Tokenization plays a similar role for stored and referenced data, complementing rather than replacing Requirement 4's transmission controls.
Data-in-Transit Protection Flow
The diagram below traces a single cardholder-data transmission event through the decision points Requirement 4 actually governs — useful as a walkthrough artifact for both engineering teams and QSA evidence sessions.
flowchart TD
A[Cardholder submits PAN<br/>web, phone, wireless terminal] --> B{Transmission path<br/>crosses open/public network?}
B -- No, fully isolated segment --> Z[Document network isolation;<br/>Requirement 4 trigger not met]
B -- Yes --> C[TLS/IPsec/WPA handshake initiated]
C --> D{Protocol version approved?<br/>TLS 1.2+ / TLS 1.3 only}
D -- No, SSL/TLS 1.0/1.1 offered --> E[Reject connection;<br/>log and alert — protocol failure]
D -- Yes --> F{Certificate trusted, valid,<br/>not expired/revoked?}
F -- No --> G[Reject connection;<br/>trigger cert incident response]
F -- Yes --> H{Cipher suite/key strength<br/>meets minimum standard?}
H -- No --> E
H -- Yes --> I[Encrypted session established]
I --> J[PAN transmitted within<br/>encrypted channel to processor/gateway]
J --> K[Session logged; cert/key usage<br/>recorded against inventory]
K --> L{Was this an end-user<br/>messaging channel — email/SMS/chat?}
L -- Yes --> M[Verify strong crypto applied end-to-end<br/>or route to compliant alternative]
L -- No --> N[Standard transmission evidence complete]Walk any transmission path — a checkout page, a call-center order entry, a store's wireless terminal — through this flow, and every "no" branch maps directly to a control failure a QSA will document as a finding. That's not a coincidence; it's how testing procedures for Requirement 4 are structured.
Common Requirement 4 Failures (and How They Get Found)
Across assessments, the same handful of failure patterns account for the overwhelming majority of Requirement 4 findings. Knowing them in advance lets you self-audit before your QSA does it for you.
Table: Common Requirement 4 Failures
Failure | How It's Typically Discovered | Remediation |
|---|---|---|
TLS 1.0/1.1 or SSL still negotiable (fallback enabled) | ASV external scan, internal config review, protocol negotiation testing | Disable insecure protocol versions at the load balancer/server config; retest |
Expired or soon-to-expire certificate in production | Monitoring gap, customer-reported browser warning, QSA sampling | Automate expiry alerting; move to automated renewal (ACME-style) where feasible |
Self-signed or untrusted certificate accepted silently | Client misconfigured to skip validation ("verify=false" left in code) | Remove validation bypass; enforce trust chain checking in all client code |
No certificate/key inventory (4.2.1.1 gap) | Direct evidence request during QSA interview | Build and maintain the inventory described above; assign an owner |
PAN sent via unencrypted/ad hoc email or chat | Employee interview, DLP log review, incident investigation | Deploy DLP pattern matching; retrain; provide compliant alternative channel |
Weak cipher suites still enabled for compatibility | Protocol/cipher scan (e.g., testssl-style tooling) | Prune cipher list to approved set; accept the compatibility trade-off |
Wireless network using WEP/WPA or shared PSK across CDE-adjacent devices | Wireless site survey, penetration test | Upgrade to WPA2-Enterprise/WPA3 with per-device authentication |
OCSP/CRL revocation checks configured to soft-fail | Configuration review, MITM simulation testing | Reconfigure to hard-fail or use OCSP stapling with proper enforcement |
Undocumented policy/roles for Requirement 4 (4.1.1/4.1.2 gap) | Document request, staff interview mismatch with written policy | Draft and formally approve policy; assign named role owners |
Wildcard certificate reused far beyond its intended scope | Cert inventory review, architecture walkthrough | Scope certificates narrowly; issue dedicated certs per service where practical |
Case Study: The Call Center Workaround
Solstice Outfitters' call center incident, introduced at the top of this article, is worth walking through end to end because it illustrates how a Requirement 4.2.2 failure compounds. The root cause was a DTMF-masking system outage lasting six hours during a promotional weekend — call volume spiked, the workaround emerged organically among reps without any policy sanction, and it persisted for eleven months because nobody escalated it and no technical control caught it. When the QSA's evidence pull surfaced forty-three instances, Priya's team had to treat it as a potential reportable incident pending forensic scoping, not just a compliance finding — because unprotected PAN sitting in a shared inbox for up to eleven months is precisely the kind of exposure card brands and regulators care about.
The remediation took six weeks: a tokenized payment link for phone orders (eliminating the need to ever ask for a card number verbally or in writing during an outage), DLP pattern-matching on outbound email tuned to card-number formats with a hard block (not just an alert), a revised outage runbook that named the compliant fallback explicitly, and a targeted retraining session for the entire call center. The QSA accepted the remediation evidence, the ROC was signed with the finding documented as remediated prior to report issuance, and Solstice avoided both the acquirer fee escalation and a forensic investigation. Total remediation cost, including the DLP tooling license and retraining hours, ran about $38,000 — against the $500,000 fine exposure and the reputational cost of a confirmed exposure event that never materialized.
Case Study: The Legacy Checkout Fallback
The second half of Priya's finding — TLS 1.0 fallback on the legacy checkout listener — is the more common failure pattern across the merchants I've assessed, because it's invisible in normal operation. The site "worked." Customers checked out. Nothing looked broken from a business-metrics dashboard. It took an ASV scan configured to specifically probe for protocol downgrade behavior (not just check whether TLS 1.2 was available) to surface that TLS 1.0 was still being offered to a narrow user-agent allowlist someone had added years earlier for a now-decommissioned kiosk integration.
Tobias Reyes's team fixed the immediate issue in an afternoon — a load balancer configuration change disabling the legacy listener and removing the stale allowlist — but the more valuable outcome was the follow-on project: a quarterly TLS/cipher configuration review added to the security calendar, and automated configuration-drift alerting so that any future change to the listener's protocol settings triggers a review before it reaches production. Coastal Retail Group, a fictional composite drawn from several assessments I've supported, found a nearly identical issue during a Level 2 merchant SAQ D self-assessment and used the same drift-alerting pattern to close the gap permanently rather than just once.
Table: Case Study Outcomes Summary
Organization | Finding | Remediation Timeline | Estimated Cost Avoided |
|---|---|---|---|
Solstice Outfitters | Unprotected PAN via call-center email workaround (4.2.2) | 6 weeks | ~$500,000 (fine exposure + forensic investigation avoidance) |
Solstice Outfitters | TLS 1.0 fallback on legacy checkout listener (4.2.1) | 1 day fix + ongoing drift monitoring | ~$180,000 (acquirer fee escalation avoidance) |
Coastal Retail Group (composite) | Stale protocol allowlist on decommissioned kiosk integration | 2 weeks | Reassessment cost + potential SAQ D disqualification |
The Evidence a QSA Actually Tests
Requirement 4 evidence requests follow a predictable pattern once you've been through a few assessments. Preparing this package in advance — rather than assembling it reactively during fieldwork — is consistently the single biggest time-saver I recommend to clients.
Table: Requirement 4 Evidence Checklist
Evidence Item | Source | Maps To |
|---|---|---|
Documented Requirement 4 policy and procedures | Policy management system | 4.1.1 |
RACI or named ownership for transmission security | Org chart / policy doc | 4.1.2 |
Network diagram showing open/public network transmission paths | Network architecture team | 4.1, 4.2.1 |
TLS/protocol configuration exports from servers, load balancers, gateways | System configs | 4.2.1 |
External vulnerability/ASV scan results showing no SSL/early TLS | ASV reports | 4.2.1 |
Certificate and key inventory (see fields table above) | Cert management tooling | 4.2.1.1 |
Sample of certificates validated for trust chain, expiry, revocation checking | Cert inventory + live testing | 4.2.1 |
Wireless network configuration and encryption standard documentation | Network/wireless team | 4.2.1 |
End-user messaging policy prohibiting unprotected PAN | Policy management system | 4.2.2 |
DLP or technical control configuration blocking PAN in outbound messaging | Security tooling | 4.2.2 |
Staff training records/attestations on the messaging policy | HR/training system | 4.2.2 |
Incident records related to any transmission-security exceptions | Incident management system | 4.1, 4.2.1, 4.2.2 |
Cross-check this package against our PCI DSS 12-Requirements Checklist so your Requirement 4 evidence lines up cleanly with what the other eleven requirements will also ask for.
"By the time I'm in the room for fieldwork, I already know whether a client is going to have a smooth Requirement 4 walkthrough within the first ten minutes — it's whether they can produce the certificate inventory without someone disappearing to go build one." — Marcus Webb, QSA, Ironclad Assessors LLC
Requirement 4 and Requirement 3: Two Sides of the Same Data
Teams new to PCI DSS often conflate Requirement 4 with Requirement 3's cardholder data protection and encryption controls, and it's worth being precise about the boundary because the evidence, tooling, and even the responsible teams are frequently different.
Table: Requirement 3 vs. Requirement 4 Comparison
Dimension | Requirement 3 (Data at Rest) | Requirement 4 (Data in Transit) |
|---|---|---|
Core question | Is stored PAN protected, minimized, and retained appropriately? | Is PAN protected while moving across open, public networks? |
Primary controls | Strong cryptography, truncation, tokenization, key management for stored data, retention/disposal policy | TLS/strong protocol enforcement, certificate/key trust, secure messaging practice |
Typical owner | Database/storage teams, application teams | Network/infrastructure teams, application teams |
Typical evidence | Encryption configuration, key management records, data retention logs | TLS configs, ASV scans, certificate inventory, messaging policy |
Common failure | PAN retained beyond business need, weak/legacy encryption at rest, unmasked PAN in logs | Protocol fallback, expired/untrusted certs, PAN sent via email/SMS |
Where they intersect | A PAN captured via unencrypted email (4.2.2 failure) is also now stored unencrypted (3.x failure) | Same intersection point — one bad workflow can trigger findings under both requirements simultaneously |
That last row is exactly what happened at Solstice: the emailed card photos were simultaneously a Requirement 4.2.2 transmission failure and a Requirement 3 storage failure the moment they landed in the inbox. Fixing the transmission path (a tokenized payment link) also eliminated the storage exposure, because the workflow no longer touched raw PAN at all — the cleanest kind of remediation, where removing the data from the workflow beats trying to secure it after the fact.
Cross-Pillar View: How SOC 2 Frames Encryption in Transit
Organizations running both a PCI DSS program and a SOC 2 examination — common among payment processors, gateways, and SaaS platforms handling card data — will recognize that SOC 2's approach to encryption at rest and in transit asks a conceptually similar question through a different lens: SOC 2 tests whether an organization's described controls over data protection actually operated effectively, under the Trust Services Criteria's Confidentiality and Security criteria, rather than mandating a specific protocol version the way PCI DSS does.
Table: PCI DSS Requirement 4 vs. SOC 2 Encryption-in-Transit Framing
Dimension | PCI DSS Requirement 4 | SOC 2 (Confidentiality/Security criteria) |
|---|---|---|
Prescriptiveness | Prescriptive — names disallowed protocols (SSL, TLS 1.0/1.1) explicitly | Principles-based — organization defines and attests to its own encryption standard |
Scope trigger | Any PAN transmission over an open, public network | Any data the organization has committed to protect, per its system description |
Validation mechanism | QSA/ISA assessment, ASV scans, defined testing procedures | Independent CPA attestation (Type I/II) against management's control descriptions |
Applies to | Entities storing/processing/transmitting cardholder data | Service organizations that have committed to Trust Services Criteria in their system description |
Certificate/key inventory requirement | Explicit (4.2.1.1) | Implicit — expected as part of a mature key management control, not separately named |
Messaging-channel restriction | Explicit (4.2.2 names email/IM/SMS/chat) | Not separately named — falls under general confidentiality commitments |
For a payment processor or fintech pursuing both frameworks, the practical takeaway is that PCI DSS Requirement 4 controls — protocol enforcement, certificate inventory, messaging restrictions — largely satisfy the underlying SOC 2 encryption-in-transit expectations too, but SOC 2's auditor will still want to see the control described, owned, and evidenced independently in your system description rather than assuming PCI DSS compliance speaks for itself. Building the control once and mapping the evidence to both frameworks is the efficient path; treating them as unrelated projects duplicates work for no security benefit.
Implementation Roadmap
Most Requirement 4 remediation programs follow a similar shape once the initial gap assessment is complete. This roadmap reflects a realistic first-time implementation for a mid-market merchant environment with a mix of e-commerce, call-center, and physical channels.
Table: 90-Day Requirement 4 Implementation Roadmap
Phase | Timeframe | Key Activities |
|---|---|---|
Discovery | Weeks 1–2 | Map all transmission paths crossing open/public networks; identify every TLS/SSH/wireless endpoint touching PAN |
Protocol audit | Weeks 2–3 | Scan all endpoints for SSL/TLS 1.0/1.1 support and fallback behavior; document weak cipher suites |
Certificate inventory build | Weeks 2–5 | Discover all certificates in use; populate inventory fields; identify orphaned/expired/self-signed certs |
Messaging workflow review | Weeks 3–4 | Audit call-center, chat, and email workflows for PAN handling; interview frontline staff on actual practice |
Remediation — protocols | Weeks 4–7 | Disable insecure protocols/ciphers; upgrade wireless encryption; retest with ASV/internal scans |
Remediation — messaging | Weeks 4–8 | Deploy DLP controls; roll out tokenized payment link alternatives; retrain frontline staff |
Policy and role documentation | Weeks 5–8 | Draft/approve Requirement 4.1.1/4.1.2 policy and named ownership |
Automation | Weeks 6–10 | Implement automated cert expiry alerting, renewal, and configuration-drift detection |
Validation | Weeks 10–12 | Internal audit walkthrough; mock QSA evidence pull; close residual findings |
Steady state | Ongoing | Quarterly TLS/cipher review, continuous cert inventory maintenance, recurring staff attestation |
Illustrative Cost Ranges
Every dollar figure below is illustrative, drawn from the range of remediation programs I've supported at similarly sized organizations — treat it as planning-level guidance, not a quote.
Table: Illustrative Requirement 4 Remediation Cost Ranges
Item | Small Merchant (SAQ A/B range) | Mid-Market (SAQ D range) | Enterprise/Service Provider |
|---|---|---|---|
Protocol/cipher remediation (config work) | $2,000–$8,000 | $10,000–$30,000 | $30,000–$80,000+ |
Certificate inventory tooling/discovery | $0–$5,000 (manual/spreadsheet feasible) | $8,000–$25,000 (automated discovery tooling) | $25,000–$75,000+ |
DLP for end-user messaging | $3,000–$10,000/year | $15,000–$50,000/year | $50,000–$150,000+/year |
Wireless upgrade (WPA2-E/WPA3, per site) | $500–$2,000/location | $500–$2,000/location | Varies by site count |
Staff retraining program | $1,000–$5,000 | $10,000–$25,000 | $25,000–$75,000+ |
QSA assessment time attributable to Requirement 4 | Included in SAQ self-assessment | 1–3 days of QSA fieldwork | 3–5+ days of QSA fieldwork |
Roles and Responsibilities
Requirement 4.1.2 explicitly requires documented, assigned roles — not just a policy that names a department. The table below reflects a workable RACI split for a mid-market merchant environment.
Table: Requirement 4 RACI
Activity | Network/Infra Team | Application/Dev Team | Security/Compliance | Call Center/Frontline Ops |
|---|---|---|---|---|
TLS protocol/cipher configuration | Responsible | Consulted | Accountable | Informed |
Certificate inventory maintenance | Responsible | Consulted | Accountable | — |
Certificate issuance/renewal | Responsible | — | Consulted | — |
Wireless network encryption standard | Responsible | — | Accountable | Consulted |
End-user messaging policy | Consulted | Consulted | Accountable/Responsible | Consulted |
Messaging DLP control tuning | Consulted | Responsible | Accountable | Informed |
Frontline staff training on messaging policy | — | — | Responsible | Accountable |
ASV scan remediation | Responsible | Consulted | Accountable | — |
QSA evidence assembly | Consulted | Consulted | Responsible/Accountable | Consulted |
Requirement 4 as a Business Opportunity, Not Just a Checkbox
It's tempting to treat Requirement 4 as pure overhead — protocol settings and certificate paperwork that exist because an assessor demands them. I'd push back on that framing after fifteen years of watching what happens on both sides of a Requirement 4 finding. Every organization I've worked with that built genuinely strong transmission security — real cipher hygiene, a maintained certificate inventory, a call center that can say "we will never ask for your card number by email" with total confidence — got something beyond a clean ROC out of it: fewer customer-facing security incidents, faster incident response when something did go wrong (because the certificate and key inventory turned "what's affected?" from a days-long investigation into a lookup), and a genuinely stronger sales conversation with enterprise customers and partners who ask hard questions about payment security before signing a contract.
Solstice Outfitters didn't just close two findings — Priya's team used the certificate inventory project as the foundation for a broader asset management initiative that now covers every externally facing TLS endpoint in the company, PCI-scoped or not. That's the pattern I'd encourage every reader to aim for: build Requirement 4 controls that are good enough to not think about, then let the discipline bleed outward into the rest of the security program. If you're earlier in that journey and want a structured starting point, our PCI DSS Scoping & CDE Worksheet helps map exactly which transmission paths are in scope before you spend a dollar on remediation, and our PCI DSS Gap Analysis Tool will walk your environment through Requirement 4 alongside the other eleven requirements so nothing falls through the cracks between goals.
For teams still working out where Requirement 4 fits into the twelve-requirement structure as a whole, our PCI DSS Complete Guide is the right starting point, and if you're weighing PCI DSS against other frameworks your organization carries, PCI DSS and ISO 27001: do you need both? walks through where the two overlap on cryptographic controls and where they diverge. Whatever stage you're at, PentesterWorld's assessors have walked this exact evidence request more times than we can count — reach out when you're ready for a second set of eyes before your QSA's does.