Articles

PCI DSS Encryption: Beyond TLS 1.2

March 15, 2026 7 min read

PCI DSS doesn’t actually require encryption for all credit card data. It requires it for data in transit over open, public networks and for sensitive authentication data at rest. The nuance is crucial.

Let’s see it in action. Imagine a simple payment gateway interaction.

// Request from merchant's POS to payment gateway
{
  "transaction_type": "sale",
  "card_number": "4111111111111111", // Encrypted with TLS
  "expiry_month": "12",
  "expiry_year": "25",
  "cvv": "123", // Encrypted with TLS, and often masked/redacted immediately after authorization
  "amount": "100.50",
  "currency": "USD"
}

// Response from payment gateway back to merchant's POS
{
  "transaction_id": "a1b2c3d4e5f6",
  "status": "approved",
  "auth_code": "987654",
  "card_number_masked": "411111******1111" // Sensitive data is not returned in full
}

This exchange, if happening over the internet, must be protected by TLS (Transport Layer Security), which encrypts the data in transit. The card_number and cvv here are conceptually encrypted before they leave the POS system and after they arrive at the gateway, due to TLS.

PCI DSS Requirement 3 is all about protecting stored cardholder data. Requirement 4 is about encrypting transmission of cardholder data across open, public networks.

Here’s the breakdown:

1. Data in Transit (PCI DSS Req 4): Anytime cardholder data (PAN, expiration date, service code, CVV, magnetic stripe data) travels over a public network (like the internet), it must be encrypted. This is non-negotiable. The most common and recommended method is TLS 1.2 or higher. Older versions like SSL or TLS 1.0/1.1 are deprecated and no longer meet PCI DSS standards.

  • Diagnosis: Use network analysis tools like Wireshark to capture traffic between your systems and external endpoints. If you see plaintext cardholder data, you have a problem. For web traffic, check your web server configuration (e.g., Apache’s SSLProtocol or Nginx’s ssl_protocols) to ensure only strong protocols are enabled.
  • Fix: Configure your web server, API gateways, and any other network-facing services to use TLS 1.2 or TLS 1.3 exclusively. For example, in Apache, you’d set SSLProtocol -all +TLSv1.2 +TLSv1.3. In Nginx, ssl_protocols TLSv1.2 TLSv1.3;.
  • Why it works: TLS establishes a secure tunnel between the client and server, encrypting all data exchanged within that tunnel using strong cryptographic algorithms. Anyone intercepting the traffic sees only garbled ciphertext.

2. Data at Rest (PCI DSS Req 3): This is where it gets more nuanced. PCI DSS doesn’t mandate encryption for all stored cardholder data. It does mandate strong protection for Sensitive Authentication Data (SAD), which includes: * Full magnetic stripe data (card number, expiration date, service code, PIN, track data) * CVV, CVC, CID (the 3- or 4-digit security code) * PINs and PIN blocks

SAD must never be stored after authorization, even if encrypted. If you must store SAD (which is very rare and highly discouraged), it must be unreadable through strong cryptography, and key management must be robust.

For non-SAD cardholder data (like PAN and expiration date), PCI DSS requires protection, but encryption is only one method. Other acceptable methods include: * Strong encryption (e.g., AES-256) with strong key management. * Truncation (e.g., showing only the first 6 and last 4 digits of the PAN, like 411111******1111). * Hashing (a one-way cryptographic function, but not suitable for PANs that need to be retrieved). * Tokenization.

  • Diagnosis (for stored PANs): Run a data discovery scan on your databases, file systems, and backups. Look for full PANs. Check your application code and database schemas to see how PANs are stored and if they are masked, truncated, encrypted, or tokenized.
  • Fix (for stored PANs):
    • Encryption: Use AES-256 with a strong key management system (KMS). Example command (conceptual, actual implementation varies by language/library): openssl enc -aes-256-cbc -salt -in plaintext_pan.txt -out encrypted_pan.bin -pass pass:your_super_secret_key. Ensure keys are stored separately and access is strictly controlled.
    • Truncation: Implement logic to store only the first 6 and last 4 digits of the PAN. When displaying, use this truncated format.
    • Tokenization: Replace the PAN with a unique token. The actual PAN is stored securely in a separate vault, and the token is used in less secure environments.
  • Why it works: Encryption renders the data unreadable without the decryption key. Truncation or masking reduces the exposed information to a non-sensitive subset. Tokenization replaces sensitive data with a surrogate value, so the original data is not present in most systems.

3. Cryptographically Secure Algorithms and Key Lengths (PCI DSS Req 3 & 4): If you are using encryption, it must be strong. This means using industry-accepted algorithms like AES (Advanced Encryption Standard) with a key length of at least 128 bits, and preferably 256 bits. For hashing, use algorithms like SHA-256 or SHA-3. Avoid deprecated algorithms like DES, MD5, or SHA-1.

  • Diagnosis: Review your implementation of encryption and hashing. Check the libraries and functions you’re using. For example, in Java, ensure you’re not using Cipher.getInstance("DES") or MessageDigest.getInstance("MD5").
  • Fix: Update your code to use current, strong algorithms. For AES-256 encryption in Python: from cryptography.fernet import Fernet; key = Fernet.generate_key(); cipher_suite = Fernet(key); encrypted_data = cipher_suite.encrypt(b"your_data"). For SHA-256 hashing: import hashlib; hashed_data = hashlib.sha256(b"your_data").hexdigest().
  • Why it works: Strong algorithms are mathematically resistant to brute-force attacks and known cryptanalytic techniques, making it infeasible for attackers to decrypt or forge data.

4. Key Management (PCI DSS Req 3): This is often the weakest link. Even with strong encryption, if your keys are compromised, your data is compromised. PCI DSS has stringent requirements for key management, including: * Protecting keys from unauthorized access. * Limiting key use to authorized personnel/systems. * Secure generation, distribution, storage, and destruction of keys. * Regular key rotation (frequency depends on key strength and usage, but often annually or more).

  • Diagnosis: Audit your key management practices. Where are your encryption keys stored? Who has access? How are they rotated? Are they hardcoded in applications (a major no-no)?
  • Fix: Implement a robust Key Management System (KMS). Cloud providers offer services like AWS KMS, Azure Key Vault, or Google Cloud KMS. For on-premises, consider dedicated hardware security modules (HSMs) or specialized KMS software. Ensure keys are never stored alongside the data they protect and that access to keys is logged and audited.
  • Why it works: Secure key management ensures that even if an attacker gains access to your encrypted data, they cannot decrypt it without also obtaining the corresponding encryption key, which is protected separately and with even higher scrutiny.

The most surprising thing about PCI DSS encryption requirements is that they are not a blanket mandate for all cardholder data at rest. The focus is heavily on sensitive authentication data (which must not be stored post-authorization) and data in transit over public networks. For other stored cardholder data like the PAN, while encryption is a strong option, truncation, masking, and tokenization are also compliant alternatives.

The next hurdle you’ll likely face after getting encryption right is understanding the nuances of tokenization and its integration into your payment processing flow.

Want structured learning?

Take the full Cryptography course →