PCI 4.0.1 – Key Changes You Need to Know

Auditwerx Triangle Logo

Share this post

Blog PCI 4.0.1 – Key Changes You Need to Know

You’ve put it off, you’ve ignored it, you’ve just been busy… whatever the case, PCI Version 4.0.1 new requirements are a reality as of April 1, 2025. Let’s dive into each new requirement.

The new requirement for storing Sensitive Authentication Data (SAD) prior to authorization is going to be a new concept for many. This will require eliminating as much SAD as possible, updating the data retention and disposal policies, as well as supporting procedures and data retention schedules. The additional requirement is that this data must be encrypted using strong cryptography when stored. SAD should be encrypted using a different encryption key than PAN.

Requirement 3.4.2 requires controls to prevent copy and/or relocation of PAN when using remote access except with explicit authorization. This requires a method to ensure remote users cannot copy PAN to their local hard drive or other location if they do not have a business need to do so.

Continuing on with encryption, if disk-level or partition-level encryption is used to encrypt PAN on fixed storage, the PAN must be rendered unreadable via another mechanism over and above the disk-level and partition-level encryption. As an added requirement, service providers must document their overall cryptographic architecture.

When PAN is being transmitted over public networks and certificates are used to encrypt it, a new requirement formalizes an already best practice… make sure those certificates are valid, not expired, and have not been revoked. It is also a requirement to maintain an inventory of all certificates and trusted keys.

A new term in PCI 4.0 is a Targeted Risk Analysis (TRA). If there are in-scope systems that are not susceptible to malware, a TRA is needed to determine how frequently those machines will be evaluated to make sure they are not at risk for malware. What might a system be that is not susceptible to malware? No system is completely immune… but some are significantly less susceptible. Air-gapped systems that are completely isolated from external networks, including the network, operate a reduced risk of malware. Read-only systems, strictly controlled operating systems (like OpenBSD or Qubes), or appliances with hardened Linux builds. Many Internet of Things (IoT), industrial, and medical devices run custom, minimalistic firmware that makes malware relatively ineffective. Any of these types of examples would need to be checked periodically to make sure they are still secure and not susceptible to malware.

Phishing remains a major concern, and PCI DSS now requires solutions to detect and protect against such attacks. The example given (but is not required) is to use DMARC, SPF, and DKIM. That’s a lot of letters… but it stands for Domain-based Message Authentication, Reporting and Conformance (DMARC), Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM).

For those that develop software, it is now a requirement to keep a list of that software and ensure it is patched and scanned for vulnerabilities. For public-facing web apps, it is now a requirement to have a control, such as a WAF (web-based application firewall) or RASP (runtime application self-protection), in place to scan the apps in real-time.

6.4.3 and 11.6.1 pertain to managing payment pages scripts. Make sure your payment pages don’t have any scripts that aren’t needed. Eliminate ads on the payment page to ease your compliance burden. For those scripts that are loaded into the consumer’s browser, it is necessary to make sure the script is authorized, authentic, and has not been changed. An inventory of all scripts is needed that includes a business or technical justification as to why it is needed on the payment page. With that said, a change and tamper detection system is now a requirement. Personnel need to be alerted when there is a modification to the payment page scripts and security-impacting HTTP headers. The incident response plan also has to be updated to respond to alerts from the change and tamper detection system.

A user access review has always been assumed, but is now a formal PCI DSS requirement. This review is performed every six months to ensure the automation is working and/or the  document procedures are being followed correctly. This review checks to make sure all user accounts (employees, contractors, system and application accounts) are needed, have the correct permissions, are active, and changing their password to comply with the policies.

Password security is always a requirement. PCI DSS now requires passwords be a minimum of 12 alphanumeric characters.

Logging is another difficult area for PCI. The new requirement states that all audit log reviews are automated. This will require a confirmation that your entire in-scope inventory is being ingested into the SIEM (Security Information and Event Management). If there are systems that cannot be ingested into the SIEM, a targeted risk analysis will be necessary.

Another requirement is to verify that critical security controls are working on a quarterly basis. This is nothing new… we used to call it business as usual… but this requirement wants a documented review, rather than informal. Most PCI shops won’t have a hard time with this one.

Vulnerability scans have received a bit of a clarification. It will be necessary to show the scanner was updated prior to running the scan. It is also necessary to demonstrate independence between the person running the scan and the people managing the systems being scanned and remediating any vulnerabilities.  A targeted risk analysis will be needed for all vulnerabilities ranked medium or lower. The TRA will need to define how quickly those will be remediated and then a rescan is performed to confirm remediation was successful. Vulnerability scans must also be authenticated scans now. While this was always the expectation, it was not being enforced.

Are you a multi-tenant service provider? Many organizations qualify as multi=tenant service providers without realizing it. The Council’s definition of a multi-tenant service provider is: A type of Third-Party Service Provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases. Services may include, but are not limited to, hosting multiple entities on a single shared server, providing e-commerce and/or “shopping cart” services, web-based hosting services, payment applications, various cloud applications and services, and connections to payment gateways and processors.

Service providers have a new requirement to detect, alert, prevent, and address covert malware communication channels. This is usually part of the intrusion detection and prevention strategy.

12.3.4 is another requirement that was always expected but not always enforced. All hardware and software technologies that are in-scope must still be supported and being patched. No more Windows 95 in the PCI environment.

While you’re already doing your scoping exercise annually, service providers are now required to perform the scoping exercise every 6 months.

Security awareness gets a bit more formalized as well. Although this again is something that was always expected, it seems to be lost at times. Security awareness training needs to be updated yearly. The environment is always changing, and new threats need to be addressed. Using the same tired PowerPoint year after year is no longer going to pass. Topics should be fresh and address the security of the cardholder data and should include phishing attacks and social engineering attacks.

Service providers are required to create a matrix for their customers that outlines how each PCI requirement will be fulfilled. Is the service provider going to fulfill it? Is it the client’s responsibility? Or will both the service provider and the client have work to do to fulfill each requirement?

While these changes may seem daunting, early preparation will make compliance smoother. Reach out to your QSA for guidance to ensure a successful transition to PCI 4.0.1 It’s better to know the requirement and make sure you’re complying before your assessment begins. Please reach out to %Who? if you have any questions about PCI 4.0. We’ll be happy to help.

We use cookies to ensure the best experience. By accessing our site, you agree to our cookie policy.