Innovate. Accelerate. Win.
September 18-19 | Las Vegas and Virtual
#MIMSummit2023 Join top security leaders looking to redefine what’s possible at the must-see industry event of 2023.
Enterprises that store, process, or transfer payment card data are required to secure cardholder data under the Payment Card Industry Data Security Standard (PCI DSS). The PCI-SSC released the PCI DSS 4.0 standard (PDF) on March 31, 2022. After March 31, 2024, the new standard—which contains several of the earlier restrictions as well as 11 new controls—will be mandated.
Best Practices
With PCI DSS 4.0, there are approximately 47 "Best Practices,” or new and updated controls, that have been added and are required to be in place by March 31, 2025.
It is important to note that all PCI DSS v3.2.1 requirements will remain active until v3.2.1 is retired, on March 31st, 2024.
Major reasons (via Dark Reading) for the changes in the new standard:
- Promote security as a continuous process
- Enhance validation methods and procedures
- Add flexibility and support of additional methodologies to achieve security
“Introducing the customized implementation approach to PCI DSS 4.0 gives businesses more flexibility,” as pointed out by Dark Reading. “Organizations are no longer forced to follow the methods prescribed by the standard or implement a burdensome compensating control…Effective IAM and MFA combined with encryption is the overarching principle behind zero-trust security for protecting sensitive cardholder data and online payments.”

Figure 1: PCI DSS 4.0 Implementation Timeline. Source: PCI Security Standards Council / Dark Reading
Priorities for PCI DSS 4.0 compliance
Organizations will need to complete several tasks ahead of implementing new controls. This will require a focus on analysis, documentation, and meetings with stakeholders to obtain necessary information and update policies, standards, procedures, and supplemental information required by the PCI DSS 4.0 standard.
Controls identified as best practices are all relatively new or clarify updates to prior controls. Organizations will need to prioritize the implementation of these controls based on the business needs and risk environment. However, any prioritization plan should not omit any of the following requirements:
- Requirements 8.4.2 and 8.5.1: Multi-Factor Authentication (MFA) required for all access to the cardholder data environment (CDE)
- Requirements 3.5.1.1 and 3.5.1.2: Hashing and disk encryption
- Requirement 11.3.1.1: Authenticated scanning
- Requirement 12.3.1: Targeted risk analysis
- Requirement 6.4.2: Web Application Firewall (WAF) implementation
- Requirement 6.3.2: Software component management
- Requirements 6.4.3 and 11.6.1: Ensure payment page integrity
- Requirement 12.3.3: Cryptographic cipher management
- Requirement 5.4.1: Automated phishing prevention
- Requirement 7.2.4: Access control review
- Requirements 12.6.2, 12.6.3.1, and 12.6.3.2: Security awareness training
Key and certificate management and validation are a top priority
When transmitting cardholder information over open networks, strong cryptography and security protocols must be implemented to safeguard the Primary Account Number (PAN). PAN refers to the unique payment card number that identifies the issuer and the cardholder account. “Open and public” refers not only to the Internet but also wireless technologies such as Wi-Fi, Bluetooth, cellular, and satellite communications.
However, data encryption is only as strong as the underlying key and certificate management processes. PCI DSS 4.0 focuses on effectively managing and validating cryptographic keys and certificates. More specifically:
4.2.1: states that strong cryptography and security protocols should be implemented as follows to safeguard PAN during transmission over open, public networks:
- Only trusted keys and certificates are accepted.
- Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked.
- The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
- The encryption strength is appropriate for the encryption methodology in use.
4.2.1.1: this adds a new requirement to keep an inventory of trusted keys and certificates used to protect PAN during transmission and that the inventory of trusted keys and certificates is examined to verify it is kept up to date.
“The inventory of trusted keys helps the entity keep track of the algorithms, protocols, key strength, key custodians, and key expiry dates. This enables the entity to respond quickly to vulnerabilities discovered in encryption software, certificates, and cryptographic algorithms,” according to the guidance in 4.2.1.1.
These requirements reflect the core certificate and key management best practices shown in publications such as NIST SP 1800-16. Certificates are not a “fire and forget” solution. Once a certificate is installed, it must be continuously monitored for security issues breaking its validity, renewed when it expires, and replaced with a new one when necessary. Using manual processes to manage the certificate lifecycle is an error-prone, unreliable, and time-consuming approach, especially if we consider the thousands of certificates an organization might need to handle on a regular basis.
Businesses can avoid certificate management problems and ensure compliance with PCI DSS 4.0 by establishing centralized, well-structured certificate lifecycle management processes. These processes should be automated to remove the margin of error and implement a security infrastructure to handle your encryption needs.
Organizations should ensure that they adhere to the PCI DSS recommendations. Better safe than sorry—it takes just one untracked certificate to break an otherwise solid machine identity management program. Preventing certificate outages is a lot simpler than dealing with their impact afterward.
The Venafi TLS Protect solution can help discover all your TLS certificates and corresponding private keys so you can protect these machine identities across your infrastructure. By automating the replacement of expiring certificates, you can eliminate outages and quickly respond to vulnerabilities, CA compromise, or other errors.
Related Posts