Encryption is the last line of defense for cardholder data. If an attacker bypasses your network segmentation, evades your monitoring, and gains access to your storage systems, encryption determines whether they get usable card numbers or ciphertext.
PCI DSS addresses encryption in two requirements: Requirement 3 covers stored cardholder data (data at rest), and Requirement 4 covers data transmitted across open, public networks (data in transit). Both underwent significant clarification in v4.0.
Requirement 3: Protecting Stored Data
The first principle of Requirement 3 is to minimize stored cardholder data. If you do not store it, you do not need to protect it. Before implementing encryption, evaluate whether you need to store the PAN at all. Tokenization can replace stored PANs with non-sensitive tokens, dramatically reducing your compliance scope.
What must be rendered unreadable
Requirement 3.5 mandates that the PAN is rendered unreadable anywhere it is stored, using one of these methods:
- Strong one-way hash functions of the entire PAN (such as SHA-256), with the hash keyed to prevent rainbow table attacks
- Truncation where only a segment of the PAN is stored (maximum first six and last four digits)
- Index tokens and securely stored pads where the mapping between token and PAN is secured separately
- Strong cryptography with associated key management processes and procedures (AES-128 minimum, AES-256 preferred)
| Method | Reversible | Use Case | Considerations |
|---|---|---|---|
| Encryption (AES) | Yes, with key | Need to retrieve original PAN | Requires key management program |
| Tokenization | Via token vault | Reference data without storing PAN | Token vault is in CDE scope |
| Hashing | No | Verification only, not retrieval | Must be keyed (HMAC) to prevent attacks |
| Truncation | No | Display/receipt purposes | Max first 6 + last 4 digits shown |
Key Management
Encryption without proper key management is security theater. If the encryption keys are stored alongside the encrypted data, or if key access is not controlled, the encryption provides no meaningful protection.
Requirement 3.6 and 3.7 mandate a complete cryptographic key management program:
- Key generation using industry-accepted methods (FIPS 140-2/140-3 validated or equivalent)
- Key distribution through secure channels, never in cleartext
- Key storage in encrypted form, with key-encrypting keys stored separately from data-encrypting keys
- Key rotation at the end of the defined cryptoperiod (typically annually for data-encrypting keys)
- Key retirement and destruction when keys expire or are compromised
- Split knowledge and dual control for manual key operations so no single person has access to the complete key
Full-disk encryption caveat: Full-disk encryption (such as BitLocker or LUKS) protects data when the disk is physically removed, but does not protect data when the system is running. PCI DSS requires that PANs be rendered unreadable at the application or database level, not just at the disk level. Full-disk encryption alone does not satisfy Requirement 3.5 for systems that are operational.
Requirement 4: Protecting Data in Transit
Requirement 4 mandates that cardholder data transmitted across open, public networks is protected with strong cryptography. This means TLS 1.2 or higher for all transmissions of cardholder data over the internet, wireless networks, or any other network that could be intercepted.
TLS requirements
- TLS 1.0, TLS 1.1, SSL 2.0, and SSL 3.0 are explicitly prohibited
- TLS 1.2 is the minimum acceptable version
- TLS 1.3 is preferred and should be implemented where possible
- Weak cipher suites must be disabled (export ciphers, NULL ciphers, RC4, DES)
- Certificate validation must be enforced; self-signed certificates in production CDE environments are a finding
Requirement 4 applies to all channels: web traffic, API communications, email containing cardholder data, file transfers, and any other transmission. Internal network traffic between CDE systems should also use encryption, even though Requirement 4 technically applies to "open, public networks." Best practice and many QSAs expect internal encryption as well.
Common Encryption Failures
- Keys stored with data. Encryption keys in the same database, same server, or same application configuration as the encrypted cardholder data. Key compromise equals data compromise
- No key rotation. Data-encrypting keys that have never been rotated since initial deployment. Define a cryptoperiod and rotate keys accordingly
- TLS 1.0/1.1 still enabled. Legacy systems or load balancers that still accept TLS 1.0 or 1.1 connections, even if TLS 1.2 is also supported
- Relying solely on full-disk encryption. Using BitLocker or LUKS as the only data-at-rest protection for databases containing PANs
- Unencrypted backups. Encrypting the production database but storing unencrypted database backups on a file share. The backups contain the same cardholder data
Need encryption assessment for PCI DSS?
Our penetration tests evaluate your encryption implementation, key management practices, and TLS configurations. Get your Requirements 3 and 4 validated before your QSA assessment.
