PCI DSS 4.0 Cryptography Requirements: What Changed and How to Comply

PCI DSS 4.0 went into effect on March 31, 2024. The “future-dated” requirements — the new ones that organizations had extra time to implement — became mandatory on March 31, 2025. If you process, store, or transmit cardholder data, these requirements apply to you now.

The cryptography-related changes in 4.0 are significant. For the first time, PCI DSS explicitly requires a cryptographic cipher suite and protocol inventory, mandates certificate lifecycle management documentation, and strengthens requirements around key management procedures. These aren’t vague guidelines — they’re auditable requirements that your QSA will test.

---

What’s New in PCI DSS 4.0 for Cryptography

Requirement 4.2.1: Certificate and Key Inventory

New requirement (mandatory since March 2025):

“An inventory of trusted keys and certificates used to protect PAN during transmission is maintained.”

This means you must document:

• Every TLS certificate that protects cardholder data in transit
• Every encryption key used for cardholder data
• The purpose of each key/certificate
• The expiry date
• The responsible party (owner)

What auditors will ask:

• “Show me your certificate inventory for the cardholder data environment”
• “How do you track certificate expiry?”
• “Who is responsible for renewing each certificate?”
• “When was this inventory last updated?”

How to comply:

Certificate Inventory (CDE):
| Hostname | Certificate CN | Issuer | Expiry | Owner | Auto-Renew? |
|----------|---------------|--------|--------|-------|-------------|
| payment-api.internal | payment-api.internal | Vault PKI | 2026-06-15 | Platform Team | Yes (cert-manager) |
| gateway.example.com | *.example.com | DigiCert | 2026-09-01 | Infrastructure | Yes (ACM) |
| db-primary.internal | db-primary | Internal CA | 2026-08-20 | DBA Team | No (manual) |

Requirement 12.3.3: Cryptographic Cipher Suite Inventory

New requirement (mandatory since March 2025):

“An inventory of all cryptographic cipher suites and protocols in use is maintained, including purpose and where used.”

This goes beyond just TLS. You must inventory:

• TLS cipher suites on every endpoint in the CDE
• Encryption algorithms for data at rest (AES-256, etc.)
• Hashing algorithms in use
• Key exchange algorithms
• Any other cryptographic protocol (SSH, IPsec, etc.)

What auditors will ask:

• “Show me your cipher suite inventory”
• “Which cipher suites does your payment gateway support?”
• “Are any deprecated algorithms still in use?”
• “How do you ensure weak cipher suites aren’t enabled?”

How to comply:

Cryptographic Inventory (CDE):
| System | Protocol | Cipher Suites | Key Exchange | Purpose |
|--------|----------|---------------|--------------|---------|
| Payment API (Nginx) | TLS 1.3 | AES-256-GCM, ChaCha20 | X25519 | Card data in transit |
| Database (PostgreSQL) | TLS 1.2 | AES-256-GCM | ECDHE-RSA | DB connection encryption |
| Backup storage | N/A | AES-256-XTS | N/A | Card data at rest |
| Internal SSH | SSH-2 | AES-256-GCM | Ed25519 | Admin access to CDE |

Requirement 3.6.1.1: Key Management Documentation

Strengthened requirement:

Key management procedures must now explicitly document:

• How keys are generated (algorithm, key size, entropy source)
• How keys are distributed to systems
• How keys are stored (HSM, KMS, file — with protection details)
• How keys are rotated (schedule, procedure, who authorizes)
• How keys are retired and destroyed
• How compromised keys are handled (incident response)
• Crypto-periods for each key type

Requirement 4.2.1.1: Certificate Validity Monitoring

New requirement:

“Certificates used to protect PAN during transmission over open, public networks are confirmed as valid and not expired.”

This means active monitoring — not just having certificates, but proving they’re valid:

• Regular checks that certificates haven’t expired
• Verification that certificates are properly configured (correct hostname, complete chain)
• Evidence of monitoring (dashboards, alert history, scan reports)

---

The Practical Impact

What Most Organizations Are Missing

Based on common QSA findings, these are the gaps most organizations have:

Gap 1: No cipher suite inventory exists. Teams know their TLS version (“we use TLS 1.2”) but can’t list the specific cipher suites enabled on each system. They’ve never run nmap --script ssl-enum-ciphers against their own infrastructure.

Gap 2: Certificate inventory is incomplete. The team tracks certificates on the main website and payment gateway but misses: internal API certificates, database connection encryption, backup encryption certificates, and certificates on network devices within the CDE.

Gap 3: Key rotation isn’t documented. Encryption keys exist and are used, but there’s no written procedure for rotation. When the auditor asks “when was this key last rotated?” the answer is “we’re not sure” or “never.”

Gap 4: Deprecated algorithms still in use. TLS 1.0/1.1 disabled on the web server, but the database connection still uses TLS 1.0 (because the database is old). Or SSH still allows diffie-hellman-group1-sha1 (deprecated). The cipher suite inventory would catch this — but it doesn’t exist.

---

How to Build Your Cryptographic Inventory

Step 1: Scan TLS Endpoints

# Scan all endpoints in the CDE for TLS configuration
# Using testssl.sh (comprehensive)
testssl.sh --csv payment-api.example.com

# Using nmap (quick)
nmap --script ssl-enum-ciphers -p 443,8443,5432,3306 10.0.1.0/24

# Using OpenSSL (per-endpoint)
openssl s_client -connect payment-api:443 -tls1_3 2>/dev/null | grep "Cipher"

Step 2: Document Data-at-Rest Encryption

# Database encryption
psql -c "SHOW ssl_cipher;"  # PostgreSQL
mysql -e "SHOW STATUS LIKE 'Ssl_cipher';"  # MySQL

# Disk encryption
cryptsetup luksDump /dev/sda2 | grep cipher  # Linux LUKS
manage-bde -status C:  # Windows BitLocker

# Cloud storage
aws s3api get-bucket-encryption --bucket payment-data

Step 3: Inventory SSH and Other Protocols

# SSH cipher suites
ssh -Q cipher  # List supported ciphers
sshd -T | grep ciphers  # List configured ciphers on server

# IPsec (if used in CDE)
ipsec statusall | grep "IKE proposal"

Step 4: Map to a Structured Format

Create a living document (or better, an automated report) that covers:

# cryptographic-inventory.yaml
systems:
  - name: "Payment API Gateway"
    type: "web-server"
    protocols:
      - protocol: "TLS 1.3"
        ciphers: ["TLS_AES_256_GCM_SHA384", "TLS_CHACHA20_POLY1305_SHA256"]
        key_exchange: "X25519"
        certificate:
          cn: "payment-api.example.com"
          issuer: "DigiCert"
          expiry: "2026-09-15"
          key_type: "ECDSA P-256"
          auto_renew: true
    data_at_rest:
      algorithm: "AES-256-GCM"
      key_storage: "AWS KMS"
      key_rotation: "Annual (automatic)"

---

TLS Configuration for PCI DSS 4.0

Minimum Requirements

# PCI DSS 4.0 compliant Nginx configuration
ssl_protocols TLSv1.2 TLSv1.3;

# Only strong cipher suites (AEAD + forward secrecy)
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';

# Explicitly prohibited (will fail PCI scan):
# - TLS 1.0, TLS 1.1 (any version below 1.2)
# - RC4, 3DES, DES
# - CBC mode ciphers (padding oracle risk)
# - NULL ciphers
# - EXPORT ciphers
# - RSA key exchange (no forward secrecy)
# - MD5, SHA-1 for signatures

What ASV Scans Check

Approved Scanning Vendors (ASVs) test for:

• TLS version (must be 1.2+)
• Cipher suite strength (no weak ciphers)
• Certificate validity (not expired, not self-signed)
• Certificate chain completeness
• Known vulnerabilities (Heartbleed, POODLE, ROBOT, etc.)
• HSTS header presence
• Key size (RSA 2048+ minimum)

---

Key Management Procedures Template

For Requirement 3.6.1.1, document your key management procedures:

# Key Management Procedures — Cardholder Data Environment

## 1. Key Generation
- Algorithm: AES-256 for data encryption, ECDSA P-256 for TLS
- Entropy source: AWS KMS (hardware RNG) or FIPS 140-2 Level 3 HSM
- Authorization: Key generation requires approval from Security Team lead
- Documentation: Key ID, purpose, owner, creation date recorded in inventory

## 2. Key Distribution
- Method: AWS KMS API (keys never leave KMS boundary) or TLS-encrypted channel
- Never transmitted via: email, chat, unencrypted file transfer, source code

## 3. Key Storage
- Data encryption keys: AWS KMS (FIPS 140-2 Level 2, non-extractable)
- TLS private keys: Kubernetes Secrets (encrypted at rest via etcd encryption)
- Backup encryption keys: HSM (FIPS 140-2 Level 3)

## 4. Key Rotation
- Data encryption keys: Annual (AWS KMS auto-rotation enabled)
- TLS certificates: 90 days (ACME auto-renewal via cert-manager)
- SSH keys: Annual (automated via Ansible)
- Authorization: Rotation is automatic; manual rotation requires Security Team approval

## 5. Key Retirement and Destruction
- Trigger: Key reaches end of crypto-period AND no data remains encrypted with it
- Method: AWS KMS scheduled deletion (7-day waiting period)
- Documentation: Destruction date, method, authorizer recorded in inventory
- Verification: Confirm key is no longer accessible after destruction

## 6. Compromised Key Response
- Immediate: Rotate key, re-encrypt affected data with new key
- Notification: Security Team within 1 hour, CISO within 4 hours
- Investigation: Determine scope of compromise, affected data, timeline
- Remediation: Full re-encryption of affected data within 72 hours

---

Audit Preparation Checklist

Before your next PCI DSS 4.0 assessment:

• Cryptographic cipher suite inventory exists and is current
• Certificate inventory for CDE is complete (all endpoints, all certificates)
• No TLS 1.0 or 1.1 anywhere in the CDE (including database connections)
• No weak cipher suites enabled (CBC, RC4, 3DES, NULL, EXPORT)
• All certificates are valid (not expired, correct hostname, complete chain)
• Certificate monitoring is active (alerts before expiry)
• Key management procedures are documented (generation through destruction)
• Key rotation schedule is defined and followed (evidence of last rotation)
• Encryption keys are stored securely (HSM/KMS, not plaintext files)
• ASV scan passes with no cryptography-related failures

---

FAQ

Q: Does PCI DSS 4.0 require specific algorithms? A: It requires “strong cryptography” as defined by industry standards (NIST). In practice: AES-128+ for symmetric, RSA-2048+ or ECC P-256+ for asymmetric, SHA-256+ for hashing, TLS 1.2+ for transport. Anything weaker will fail an ASV scan.

Q: Do internal connections need TLS too? A: If cardholder data traverses the connection, yes. PCI DSS 4.0 Requirement 4.2.1 applies to “all networks where PAN is transmitted” — not just public networks. Internal API calls carrying card data must be encrypted.

Q: How often must the cryptographic inventory be updated? A: PCI DSS doesn’t specify a frequency, but “maintained” implies it’s current. Best practice: update whenever infrastructure changes, and review quarterly at minimum. Automated inventory (scanning + cloud API queries) keeps it perpetually current.

Q: What if we can’t upgrade a legacy system to TLS 1.2? A: Document it as a compensating control. Show: what the risk is, why the system can’t be upgraded, what additional controls mitigate the risk (network segmentation, monitoring, access restrictions), and your timeline for replacement. QSAs can accept compensating controls, but they must be documented and justified.

Q: Is HSTS required by PCI DSS? A: Not explicitly required by the standard text, but ASV scans flag its absence as a finding. Implement HSTS on all public-facing endpoints in the CDE — there’s no reason not to.