Key Considerations for PCI DSS v4.0.1 Requirements 4.2.1.1 and 12.3.3

With several new PCI DSS v4.0.1 requirements set to take effect on April 1, 2025, two requirements—4.2.1.1 and 12.3.3—have generated significant attention and questions. Let’s begin by reviewing the text of these requirements:

• 4.2.1.1:
  “An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.”
• 12.3.3:
  “Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following:
  • An up-to-date inventory of all cryptographic cipher suites and protocols in use, including the purpose and where used.
  • Active monitoring of industry trends regarding the continued viability of all cryptographic cipher suites and protocols in use.
  • Documentation of a plan to respond to anticipated changes in cryptographic vulnerabilities.”

The Relationship Between 4.2.1.1 and 12.3.3

Requirement 12.3.3 is a broad, comprehensive requirement encompassing all cryptographic use cases, including those covered under 4.2.1.1. While 4.2.1.1 focuses specifically on the inventory of trusted keys and certificates protecting PAN during transmission, 12.3.3 requires organizations to document and assess all cryptographic cipher suites and protocols used across their environments. This includes cryptographic implementations protecting cardholder data (CHD) and sensitive authentication data (SAD) in databases, files, or other locations.

The overarching goal of both requirements is to ensure organizations are cryptographically agile—capable of assessing and responding to cryptographic vulnerabilities or changes in standards without disruption. By proactively developing inventories and response plans, organizations can avoid being caught off guard when an algorithm or mode is deemed insecure or deprecated.

Recommendations for Implementing Requirements 4.2.1.1 and 12.3.3

1. Address Both Requirements Simultaneously
   Since 4.2.1.1 is a subset of 12.3.3, organizations should aim to fulfill both requirements concurrently. This approach streamlines documentation efforts and ensures all cryptographic assets are accounted for in a single process.
2. Inventory All Cryptographic Assets, Not Just PCI Scope
   Organizations often limit compliance efforts to systems within PCI scope. However, cryptographic agility is a security principle that extends beyond PCI compliance. Weak or outdated cryptography in non-PCI environments can still pose a risk to the organization, including its PCI environment. To maintain a strong security posture, a comprehensive inventory should include all cryptographic implementations, regardless of scope.
3. Focus on Cryptographic Inventories
   Developing a thorough inventory is critical for both requirements. For 4.2.1.1, this means cataloging all TLS certificates, including those used internally and externally. Many organizations overlook internally used secure communication protocols, such as:
   • TLS: Often associated with external communications, TLS is also widely used internally, such as with self-signed certificates for browser-based management tools or consoles. These certificates must be included in the inventory.
   • Secure Shell (SSH): Another commonly overlooked protocol, SSH usage must also be inventoried.

Cryptographic inventories should document:

• The algorithm and bit strength in use.
• The mode(s) of implementation.
• The specific locations and purposes for each cryptographic application.

A common pitfall is inadequate documentation for virtual private networks (VPNs). While organizations may know the VPN’s purpose and connections, they often lack details about the cryptographic algorithms and bit strengths used. This lack of information is typically due to outdated implementations or third-party-managed configurations. Regardless, all VPN cryptography must be documented, even for third-party-managed systems.

4. Understand Cryptography and Its Variations
   Not all cryptographic methods are equally secure. While detailed mathematical understanding isn’t necessary, security professionals should recognize that cryptographic strength varies widely. For instance:
   • The Advanced Encryption Standard (AES) is currently the strongest encryption standard endorsed by NIST. 128-bit, 192-bit, and 256-bit encryption are considered secure. Organizations should prioritize AES for encryption implementations.
   • Cryptography extends beyond encryption, including hashing functions, digital signatures, key derivation, and message authentication codes (MAC). While not all of these are covered under PCI DSS, they remain critical to a robust security strategy.

Organizations should reference NIST’s Special Publication 800-134Ar3 for guidance on transitioning to secure cryptographic algorithms and key lengths. This document outlines cryptographic best practices and deprecates insecure algorithms.

5. Prepare for Quantum Computing
   The advent of quantum computing underscores the urgency of cryptographic agility. Quantum computing has the potential to render many current cryptographic algorithms insecure. This is particularly concerning for organizations still relying on outdated algorithms like the Triple Data Encryption Algorithm (TDEA) or Secure Hash Algorithm 1 (SHA-1), which are already considered insecure.
   
   Organizations must proactively transition to quantum-resistant cryptography in line with NIST recommendations. Transition plans should account for end-of-life (EOL) deadlines and the complexities of replacing cryptographic implementations, such as third-party dependencies or rekeying large datasets.

Cryptographic Architecture and Active Monitoring

• Cryptographic Architecture
  A cryptographic architecture defines the organization’s approach to cryptography, including:
  • When and where cryptography is implemented.
  • The acceptable algorithms, modes, and methods (e.g., TLS, VPN, whole disk encryption, field/column encryption, etc.).
  • Guidelines for consistent implementation.

While a diagram may be helpful, a detailed written discussion of these elements is often more effective in defining cryptographic architecture.

• Active Monitoring of Cryptographic Trends
  To comply with the monitoring requirements of 12.3.3, organizations should maintain meeting minutes documenting discussions and decisions related to cryptographic trends and vulnerabilities. This includes:
  • Reviewing industry updates.
  • Assessing the impact of new vulnerabilities.
  • Planning transitions to secure algorithms.

Organizations must document clear transition plans for algorithms nearing EOL to prevent security gaps. Many commonly used algorithms are set to expire by 2030, so organizations should begin preparations immediately to ensure timely transitions.

In summary, PCI DSS v4.0.1 requirements 4.2.1.1 and 12.3.3 emphasize the need for organizations to maintain comprehensive cryptographic inventories, actively monitor industry trends, and ensure cryptographic agility. Organizations can mitigate risk and maintain compliance in an evolving threat landscape by adopting a proactive and comprehensive approach to cryptographic management.

If you want to learn more about PCI DSS 4.0.1, check out my book, Fortifying The Digital Castle.