PCI DSS Requirement 4 Explained

Any business that stores, processes, or transmits payment card data must comply with the PCI DSS. Among its 12 requirements, Requirement 4 is all about what happens when card data is on the move—for example, from a customer’s browser to your website, from your app to your API, or from your systems to a payment processor.

This article explains PCI DSS Requirement 4 in practical terms: what “strong cryptography” really means, which protocols and settings are acceptable, where organizations commonly fail, and how to make encrypted transmission the default in your environment.

What is PCI DSS (in a nutshell)?

The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard created by the major card brands (Visa, Mastercard, American Express, Discover, JCB) to reduce card fraud and protect cardholder data.

If your organization stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), PCI DSS applies to you – whether you’re a tiny online shop or a large payment processor.

The standard is organized into 12 requirements, grouped under six goals (build and maintain a secure network, protect data, maintain a vulnerability program, etc.). Requirement 4 focuses on data in transit—protecting it when it moves over networks you don’t fully control.

What does Requirement 4 cover?

Whenever cardholder data leaves your safe internal environment and travels over any open or public network, it must be encrypted using strong, modern cryptography and implemented securely end-to-end.

Typical scenarios:

• A customer submitting card details through your website checkout
• Mobile apps sending payment info to your APIs
• Your systems are talking to payment gateways, acquirers, or third-party services
• Files containing card data are being transferred to a service provider (e.g., SFTP, secure APIs)

What counts as an “open, public network”?

PCI DSS examples include:

• The internet
• Wireless technologies (Wi-Fi, GSM/4G/5G, Bluetooth, etc.)
• Any network you don’t fully control or manage (e.g., a partner’s network, cloud provider networks, shared office building networks)

In practice: if your card data is leaving your well-segmented, internal cardholder data environment (CDE) and touching anything external or untrusted—treat it as open/public and encrypt it.

Strong cryptography & secure protocols: what PCI is looking for

Requirement 4 expects you to use industry-accepted strong cryptography, not just “some encryption.” That typically includes:

• TLS 1.2 or 1.3 for web and API traffic
• Strong cipher suites (e.g., AES-GCM) and secure key exchange (e.g., ECDHE)
• SSH (with strong ciphers) for administrative and file transfer use
• IPsec or other secure VPN technologies for site-to-site or remote connections
• SFTP / FTPS for file transfer (not plain FTP)

At the same time, you must disable insecure or outdated protocols and ciphers, such as:

• SSL v2 / v3, TLS 1.0, TLS 1.1
• Weak ciphers (e.g., RC4, 3DES) and export-grade suites
• Insecure key lengths (e.g., 1024-bit RSA is considered weak; 2048+ is standard)

PRO TIP

Don’t rely on default settings. Many servers and load balancers ship with weak ciphers enabled “for compatibility.” Use a hardened configuration aligned with current best practices (e.g., Mozilla SSL guidelines).

Core objectives of Requirement 4

Requirement 4 can be broken down into four main objectives:

1. Encrypt cardholder data over open/public networks using strong cryptography.
2. Use trusted certificates and validate them properly.
3. Securely manage encryption keys and certificates.
4. Document, monitor, and regularly review your controls.

Let’s go through these one by one.

1. Encrypting card data in transit

Web applications & APIs

For sites and APIs that handle card data:

• Enforce HTTPS with TLS 1.2+ on all payment pages and API endpoints.
• Use HSTS (HTTP Strict Transport Security) to force HTTPS.
• Redirect all HTTP to HTTPS and avoid serving mixed content.
• Use modern cipher suites only; prefer forward secrecy (ECDHE).

Example good practices:

• https://checkout.yourdomain.com is the only way to reach the checkout; HTTP is redirected.
• The site has a valid TLS certificate issued by a trusted CA, with no SHA-1 or expired certs.
• TLS 1.0/1.1 and obsolete ciphers are disabled across all frontends/load balancers.

PRO TIP

Use tools like SSL Labs’ SSL Server Test (or similar scanners) to regularly test your public-facing endpoints. Aim for an “A” rating and use the report to identify which weak protocols or ciphers may still be enabled.

Mobile applications

When your mobile app handles or transmits card data:

• Use HTTPS/TLS for all API calls that carry CHD/SAD.
• Implement certificate validation correctly – avoid disabling verification for debugging.
• Consider certificate pinning for high-risk applications (careful with update processes).

File transfers and batch processes

Sometimes card data is transmitted in files (e.g., settlement reports, batch authorizations):

• Use SFTP or FTPS (explicit TLS) instead of FTP.
• Or use encrypted files (e.g., PGP/GPG) combined with secure transfer protocols.
• Don’t email files containing unencrypted card data – ever.

PRO TIP

For recurring data transfers to partners, define a standard secure transfer pattern with clear configuration templates (SFTP user, keys, IP allow-lists). This avoids custom, potentially weak ad-hoc setups.

2. Trusted certificates & protection against spoofing

Requirement 4 also implicitly expects that your encryption actually protects against man-in-the-middle attacks, not just “scrambles data.”

That means:

• Use certificates from trusted Certificate Authorities (CAs).
• Ensure certificate validation is enforced on the client side (servers, apps, agents).
• Monitor for expiry and misconfiguration (e.g., wrong hostname, intermediate chain issues).

Important checks:

• The certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the hostname (e.g., pay.yourdomain.com).
• The certificate is not expired and is not self-signed (except in very controlled internal environments with proper trust stores).
• The full chain (including intermediates) is served correctly.

PRO TIP

Implement centralized certificate inventory and monitoring. Track where each certificate is deployed, when it expires, and who owns it. Expired or replaced certificates are a very common source of outages and non-compliance.

3. Securing cryptographic keys and configurations

Strong cryptography is only strong if the keys are protected and managed well.

Key management expectations include:

• Restricted access: Only a minimal, need-to-know set of admins can access private keys.
• Secure storage: Keys stored in secure keystores or HSMs (Hardware Security Modules) where appropriate, not in source code or plain text files.
• Procedures for key generation & rotation:
  • Use strong algorithms and key sizes.
  • Rotate keys periodically or after suspected compromise.
• Backups & recovery: Encrypted backups of keys with strong access controls.

4. Documenting and monitoring Requirement 4 controls

From a PCI assessor’s point of view, evidence is everything. It’s not enough to “have TLS” – you need to show you manage and monitor it.

Key documentation and evidence types:

• Network diagrams clearly showing:
  • Cardholder Data Environment (CDE)
  • Open/public network connections
  • Where encryption is applied
• Configuration evidence:
  • Web server/load balancer configuration snippets showing TLS versions and ciphers
  • VPN configurations and SSH hardening settings
• Procedures & policies:
  • Policy requiring strong cryptography for CHD transmission
  • Standard build baselines for web servers and API gateways
• Monitoring & testing results:
  • Regular vulnerability scanning of external interfaces
  • TLS/SSL configuration test reports
  • Logs showing failed/blocked connections where TLS is missing or fails

Common pitfalls that cause Requirement 4 failures

Here are some issues assessors frequently find:

1. Legacy TLS still enabled
   Systems still allow TLS 1.0/1.1 or weak ciphers “for that one old client” – often forgotten after a migration.
2. Mixed content on payment pages
   The checkout page is HTTPS, but some scripts or images load over HTTP, allowing content injection.
3. Internal services misclassified as “trusted”
   Internal links that traverse third-party or shared networks (e.g., cloud cross-region traffic) but are not encrypted.
4. Emailing card data
   Staff emailing card numbers in plain text (e.g., customer sends card details, support forwards internally).
5. APIs or integrations without proper certificate validation
   Custom API clients that “accept any certificate” to avoid connection errors.

PRO TIP

Perform a focused review of every pathway where CHD could leave your CDE. Start from the point where card data is captured (web form, POS, mobile app) and follow every hop, system, and connection outward—map where encryption starts and ends.

How to approach Requirement 4 as a project

If you’re trying to get or maintain PCI compliance, here’s a practical approach:

1. Inventory all data flows involving CHD/SAD
   • Web frontends, mobile, POS, APIs, file transfers, third-party integrations.
2. Classify each connection
   • Is it entirely within your controlled, secured data center or CDE?
   • Does it traverse the internet, public cloud networks, wireless, or partner networks?
   • If yes → treat as open/public.
3. Check encryption status
   • Is TLS/SSH/VPN in use?
   • Are versions and ciphers strong and up to date?
   • Is certificate validation properly enforced?
4. Harden configurations & standardize
   • Define standard TLS profiles.
   • Roll them out to all relevant systems via automation where possible.
5. Document & monitor
   • Update diagrams and procedures.
   • Set up periodic checks (scripts, scanners) to validate configs.

Summary

PCI DSS Requirement 4 is all about protecting cardholder data in transit whenever it crosses or touches any untrusted network. That means:

• Use strong, modern cryptography (TLS 1.2/1.3, SSH, VPN with solid algorithms).
• Disable weak protocols and ciphers.
• Ensure proper certificate management and validation.
• Secure your encryption keys and configs.
• Document, monitor, and regularly test your controls.

Suppose you treat “unencrypted CHD on any open network” as an emergency and design your systems so that encryption is the default. In that case, Requirement 4 becomes less of an audit checkbox and more of a natural, everyday security practice.

Choose Copla for PCI DSS — and stop running PCI on spreadsheets

PCI DSS is the price of accepting cards. Copla makes hitting v4.0.1 — including the March 2025 changes — faster, cheaper, and radically less painful.

Why teams choose Copla:

• Shrink your CDE, shrink your PCI bill: Scope-minimization playbooks (tokenization, hosted payments, segmentation) cut effort and assessor questions.
• v4.0.1 done-for-you: Pre-mapped controls, policies, and workflows for all 12 requirements — including TRAs, MFA, and logging/retention.
• Evidence on autopilot: Automate access reviews, training, vendor AoCs, scan/pen-test tracking, and export-ready SAQ/RoC packages.

Typical outcome: 40–70% faster readiness and 40–70% lower internal PCI cost. PCI is non-negotiable. Doing it the hard way is.