When you consider the brand new version 4.0 of the PCI DSS standard, it may help to picture it like your car.
We all understand that several things that need to happen to make your car run so you can successfully get from Point A to Point B. Some of them are critical—like brake pads and a functioning battery—whereas some are arguably less so, though they’re still important to your overall journey. (Think headlights or clean engine oil.)
The same is true within version 4.0, which gave us 60 new requirements to sort through and prepare for to ensure your continued compliance. That’s a lot of new concepts you’re going to need to accommodate, even if many of them won’t be official until March 2025. (They’ll be considered “best practices” until then.)
As you start to investigate these things you need to “tune up,” we want to help. As PCI Qualified Service Assessors (QSAs), we’re doing the work to familiarize ourselves with this new version we’ll need to evaluate our clients against.
Using the knowledge we’ve gleaned so far, we want to act as your “mechanic” of sorts—that is, help you understand those more critical parts of this car standard that are particularly critical to prepare for during this transition.
That’s why we’re going to outline seven of the bigger requirements among all the changes in PCI DSS v4.0. We made a video detailing the new PCI requirements as well, but in this article, we’ll help you follow the thinking behind them from our assessor’s point of view and how to ensure you comply with them in the future. We’ll also note some of the additional guidance the PCI Council has provided for some of these major updates.
With this more nuanced view of these changes, you’ll be able to better prepare for the pending shift to v4.0.
A Breakdown of 7 Major New Requirements in PCI DSS v.4.0
1. Explaining Requirement 3.5.1.2
Standard Definition: If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render primary account numbers (PAN) unreadable, it is implemented only as follows:
- On removable electronic media
- OR
- If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.
Assessor’s Perspective:
The issue with disk-level or partition-level encryption as a tool to secure PAN is that data is only encrypted when systems are powered down. When systems are running, data is in a decrypted state, hence this new requirement for another tool or mechanism to render PAN unreadable while systems are in use.
After March 2025, disk-level or partition-level encryption will no longer be an acceptable method to render PAN unreadable, so you’ll need to make other arrangements if you have it in place.
2. Explaining Requirement 4.2.1.1
Standard Definition: An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.
Assessor’s Perspective:
This requirement should make it easier for you when new vulnerabilities are discovered. With an inventory like this, you should be able to quickly determine how your environment will be impacted and where to focus remediation efforts to minimize exposure.
This is a simple requirement that could prove priceless in the triage steps of your critical security events—at the very least, it’ll help you keep tabs on certificate expiration dates.
PCI Council Guidance:
If you have any certificates, your inventory should include the issuing certification authority (CA) and certification expiration date. Documented policies and procedures should also verify that your processes for maintaining an inventory of your trusted keys and certificates are defined.
3. Explaining Requirement 5.2.3.1
Standard Definition: The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
Assessor’s Perspective:
There’s a recurring theme in all of v4.0—particularly when using the new “Customized Approach” to meet requirements—that says you must define, document, and adhere to your specific timeframes for certain tasks.
In other words, instead of the PCI Council stating a task must be done quarterly, it’s now up to you to define the cadence that makes most sense in your environment.
Definitions of words like “periodic” are now up to you to determine, and a targeted risk analysis should support those timeframe definitions. This leans towards a more risk-based approach to compliance that surfaces throughout version 4.0.
4. Explaining Requirement 6.4.2
Standard Definition: For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks.
Assessor’s Perspective:
Before, you had the option of either the web application firewall (WAF) or vulnerability scans. But in replacing the infamous 6.6 in v3.2.1, 6.4.2 now requires that a WAF be placed in front of public web applications.
After March 2025 when v4.0 takes full effect, a WAF must be present in front of public-facing applications, though it remains a “best practice” until that date. As such, you’ll need to plan for the additional costs associated with the purchasing of a WAF as well as training resources on proper configurations.
5. Explaining Requirement 8.4.2
Standard Definition: Multi-factor authentication (MFA) is implemented for all access into the cardholder data environment (CDE).
Assessor’s Perspective:
Simply put, two authentication methods are more difficult to compromise than one.
While most good stewards of PCI data have MFA for CDE access implemented already, the current requirement is for remote, non-console access. MFA will be required for any and all access as of March 2025.
PCI Council Scenario:
“If an individual first connects to the entity’s network via remote access, and then later initiates a connection into the CDE from within the network, per this requirement the individual would authenticate using MFA twice, once when connecting via remote access to the entity’s network and once when connecting via non-console administrative access from the entity’s network into the CDE.”
6. Explaining Requirement 11.3.1.2
Standard Definition: Internal vulnerability scans are performed via authenticated scanning as follows:
- Systems that are unable to accept credentials for authenticated scanning are documented.
- With sufficient privileges, for those systems that accept credentials for scanning.
- If accounts used for authenticated scanning can be used for interactive login, they are managed per Requirement 8.2.2.
Assessor’s Perspective:
Though not officially a requirement until March 2025, why this change? Authenticated scans provide far greater visibility into an entity’s vulnerability landscape.
Yes, unauthenticated scans provide a picture of the network perimeter—open ports and unsecure services, for example. However, we also need to understand what an attacker could do once they gain access. Ideally, they are not able to elevate privileges and take a walk around the network.
PCI Council Guidance:
The credentials used for these scans should be considered highly privileged. They should be protected and controlled following PCI DSS Requirements 7 and 8—except for those requirements regarding multi-factor authentication and application and system accounts.
7. Explaining Requirement 12.5.2.1
Standard Definition: PCI DSS scope is documented and confirmed at least once every six months and upon significant changes.
Assessor’s Perspective:
Though this one is particular to service providers, there is a similar new requirement for merchants (12.5.2) regarding recurring PCI scope confirmation—only for merchants, it’s annually rather than every six months.
Also in 12.5.2 is the full list of items to consider for said scoping validation It includes:
- Updating all data flows
- Identifying all locations where account data is stored
- Identifying all systems connected to the CDE
- Identifying third-party connections
During your assessment, the evidence provided should include documented results of these scope reviews.
But why is this requirement a bi-annual requirement for service providers only, not merchants?
Per the PCI Council, “service providers typically have access to greater volumes of cardholder data than merchants or can provide an entry point that can be exploited to then compromise multiple other entities. Service providers also typically have larger and more complex networks that are subject to more frequent change. The probability of overlooked changes to scope in complex and dynamic networks is greater in service providers’ environments”.
Next Steps for PCI DSS v4.0
Though it’ll take time for all of us to get comfortable with such an enormous change to this flagship standard for payment security, we are now well on our way.
Of the 60 total new requirements you’ll need to shift to eventually, you now understand 7 of those major ones a little bit better. Here’s a graphic recap to summarize:
As we all persist in deconstructing this new standard and its effect on our organizations, we’ll continue to offer our “mechanic” services, providing more information that will help streamline your transition from the familiar version of PCI DSS to this new one.
As such, we’ll be publishing more blogs and videos addressing various aspects of PCI DSS v4.0. in the coming days. Make sure you read our breakdowns of the different facets to this standard so you're even more prepared:
- What Service Providers Should Know About PCI DSS v4.0
- Decrypting Cryptographic Requirements in PCI DSS v4.0
- Factoring Multi-Factor Authentication into PCI DSS v4.0
If you'd prefer a more specific conversation, please feel free to contact us at PCIROCS@schellman.com or through our contact page with any questions you may have.