As of March 31, 2025, PCI DSS v4.0.1 is live with new, updated, and altered requirements.
As of March 31, 2025, PCI DSS v4.0.1 is live and in full effect. With it comes a slew of new, updated, and altered requirements. In this blog, we’ll explore what those changes are, answer key questions about new PCI requirements, and lay out what you need to do to make adjustments to meet PCI 4.0.1 requirements.
While every single requirement won’t be covered here, those that have seen more impactful shifts and require you to make adjustments will be reviewed. Let’s explore what’s new in 4.0.1.
This requirement deals with the relocation of primary account number (PAN) data, if you are remotely connected to a system with access to full PAN.
Technical controls need to be in place to prevent the copying of PAN data for all users that do not have the authorization. Users with a documented business need and legitimate authorization to copy PAN data are unaffected.
But for anyone else using the system, you’ll need to make sure to have processes in place to make sure that they can't access PAN data. This might mean that you’ll need to adjust business practices, in order to limit access to cardholder data.
With the PCI version 4 update, if you are using hashing methods to protect card data, you’ll most likely need to implement a new method of hashing, one that requires a protected key to work, much like a key used in an encryption algorithm.
Consider using a library that has a validated random number generator and the ability to generate keys; it's typically more secure than trying to write your own algorithm.
Since March 31, 2025, organizations can no longer use full disk encryption as a method for protecting cardholder data.
Requirement 5.4.1 discusses phishing protection and training.
Your training needs to include phishing protection to help your staff understand and identify who's trying to contact them.
You’ll need to have methods in place to confirm the sender’s identity (e.g., checking in with IT, contacting the sender directly).
6.3.2 is concerned with custom software that your organization has created or a third party has specifically created for you.
The focus on this requirement is regarding software you've had written for you. You’ll need to get a software bill of materials. This document should be a detailed outline of all third-party software, libraries, and elements that are used in the software that you have.
The following are examples of questions that you might need to document:
Organizations will need to have a web application firewall in place for any web applications exposed to the Internet.
This requirement has been the most widely debated and discussed in the new PCI version 4 updates because it covers the tracking of scripts used on your web application payment pages.
To be compliant here, you have to know each script on your payment pages, where they came from, who authorized their use, and all of that needs to be documented and tracked. Keep in mind that some pages can have large numbers of third-party scripts running on them.
Even if you only have a handful of scripts on your pages, hackers can still inject things dynamically on your page that aren't there while it’s static.
There are many tools out there like SecurityMetrics’ Shopping Cart Monitor that both meet requirement 6.4.3 and report on suspicious scripts on payment pages directly to you. Otherwise, it would require a manual review of the code, which can be difficult and painstaking due to the number of scripts and how scripts can be dynamically included at any time during the payment process. It’s vital to know everything that gets loaded in during the actual payment process.
Previously, an eight-character password was the standard.
Now, passwords will need to be at least 12 characters with a level of required complexity.
For service providers, if you give one of your clients access to your application to view their transactions, for example, you’re now required to change those passwords on a 90-day basis or have tools in place to dynamically analyze the request and grant access based on a number of other factors (e.g., location, time, device, etc.), not just a password.
PCI DSS 4.0.1 is now requiring service providers to force clients to have better password hygiene, or the service provider can choose to add dynamic analysis tools to enhance the security of a client-chosen password.
Requirement 8.4.2 states that multi-factor authentication (MFA) has to be used for all non-console access into the cardholder data environment (CDE) for any role from any location (inside or out).
Even if your CDE is segmented off and you're accessing the systems from within your corporate network, you still have to implement MFA to access the CDE if you're not standing at the console.
This requirement requires you to get more detailed information about the MFA solution you have chosen to use.
Start with documentation provided by the vendor and review it to make sure your solution addresses the risk of replay attacks and how your solution defends against these types of attacks.
Also, be sure to confirm that both factors of authentication will be verified and successful before any access is granted to the network or system.
This may mean you have to learn more about your current MFA solution to see if it can meet the requirements. If it doesn’t, you’ll need to find a new MFA solution.
PCI Requirement 8.6.2 is ensuring you can provide evidence to your assessor during the audit around having MFA in place.
It’s fairly common for organizations to store passwords in places like configuration files to get systems running, but the new requirement no longer allows entities to have passwords written in configuration files or text files, specifically clear text passwords.
This may mean you have to recode and rework some of your startup systems in those ways.
Systems or applications need to authenticate services while running, as well as the passwords used to grant that access. These are not user accounts for interactive login, but still need to be protected from misuse.
PCI Requirements now want you to do a Targeted Risk Analysis (TRA) on what frequency you should be doing things like updating passwords in your system, and suggest you document your process to show why you made that choice; whether it’s weekly, monthly, or quarterly to show that it’s secure.
For 10.4.1.1, you’ll need to have an automated mechanism used for doing your log reviews, such as through a Security incident and Event Management (SIEM) tool.
Manual reviews of logs is no longer a viable option, but it’s likely that not many companies are still doing that. Thankfully, there are multiple options to meet this requirement. You can outsource some of it or buy your own software and configure it to alert you. You additionally need to store them according to requirement specifications: three months available for immediate review, one year total.
10.7.2 is about critical control systems, detecting if they fail, and who to notify when they do.
Previously, service providers had to monitor everything from firewalls and quarterly scans to IDS and IPS. The change here in 10.7.2 is that it now applies to everybody, not just service providers. You have to monitor the health and functioning of the systems mentioned in the requirement.
Whichever software or service you're using to do your quarterly internal vulnerability scans, it has to be able to authenticate to exposed services or software detected during a scan.
This service provider requirement is concerning monitoring outbound covert malware communication channels.Your IDS, IPS, or firewall has to be capable of monitoring for that and doing more of a deep packet inspection. When that detection system alerts on a possible issue then that alert has to be dealt with and your assessor will be looking for your process to handle those alerts as well.
Many firewalls already have this, but you might have to pay a little extra to update your licensing on your firewall to get this feature.
11.6.1 is the other half of the new e-skimming script monitoring requirements (with the other part being requirement 6.4.3).
You’ll need to make sure that your payment pages and referring payment pages are monitored for malicious scripts on a cadence that can be defined by a TRA.
It’s up to you to determine how often you want to monitor your pages. It’s impacted by things like how much your web software changes or if you have a large amount of transactions, you need to determine the risks and check for these malicious scripts as necessary. By default, the requirement suggests checking at least once every 7 days. Many tools exist that address this requirement like SecurityMetrics’ Shopping Cart Monitor. This issue is one of the new PCI DSS version 4 changes that is often most worried about, most talked about, and most debated of the requirements.
Several of the common e-skimming compromises only happen after you complete a purchase or after a customer enters their CVV number. That's when all the bad scripts can appear. Since it's a difficult problem, a professional solution may be the best option to ensure this gets squared away.
You need to make sure to monitor hardware and software technologies to ensure they're all getting patches.
You should never assume that it's happening automatically.
This requirement is about scope validation and documentation. You now have to have documentation showing that you have reviewed your scope annually. It’s likely that you've already been doing this, but now you need documented proof.
If any major change takes place in your process, such as within your network, data flows, storage locations, or third-party connections, you must revalidate your scope.
For 12.10.7, you need to initiate your incident response plan if you ever find any unencrypted PAN where it's not supposed to be.
Your incident response plan needs to do a few crucial things like making sure that you understand how long the unencrypted PAN has been there, discovering what was the root cause of it, knowing how you can fix it, providing analysis, fixing it, and providing insights on what lessons were learned.
This requirement also implies that you need to be looking for unencrypted card data, to some degree, and trying to determine if you need to modify your process.
No PCI journey is complete in one day or one week. It requires a lot of energy, but if you invest the time and effort to ensure your organization is PCI compliant, determine what applies to you, and work with experts to answer your questions, you will protect yourself and your customers with the best tools, standards, and elements available.
Download the SecurityMetrics complete PCI guide for free here.
.svg)
