PCI DSS 4.0 Is Here: What Changed From 3.2.1

The PCI Security Standards Council (PCI SSC) published PCI DSS version 4.0 on March 31, 2022. It is the largest revision of the standard in years, but nobody has to switch overnight. PCI DSS 3.2.1 stays valid until March 31, 2024. Most of the genuinely new requirements are best practices until March 31, 2025, when they become mandatory. The headline changes are wider multi-factor authentication, longer passwords, risk analyses that let you set your own frequency for some tasks, tighter control of scripts on e-commerce payment pages, authenticated internal scanning, and a new "customized approach" for meeting requirements.

Below we cover why the Council made these changes, what's different from 3.2.1, and how to use the next two years well.

When does PCI DSS 4.0 take effect?

There are three dates to put in your calendar.

Until March 2024, you can be assessed against either version. Assessors have to complete v4.0 training before they can assess against the new version, so many organizations will use 3.2.1 for at least one more assessment cycle.

Future-dated requirements are marked in the standard as a best practice until March 31, 2025. You won't fail an assessment for lacking them before that date. Everything that isn't future-dated applies as soon as you're assessed against 4.0.

Why did the PCI SSC rewrite the standard?

The Council built version 4.0 around four goals:

• Continue to meet the security needs of the payments industry. Bring controls in line with current threats and technology.
• Promote security as a continuous process. Move away from treating compliance as a once-a-year event.
• Add flexibility for different methodologies. Allow organizations to reach the same security outcome in different ways.
• Enhance validation methods and procedures. Make assessment and reporting clearer and more transparent.

You can see these goals throughout the document. Each requirement now has a stated purpose, and several let you set your own frequency based on risk instead of following a fixed schedule. Each of the 12 principal requirements now opens with a sub-requirement that roles and responsibilities for that area are documented, assigned and understood. Those take effect immediately.

The Council's own summary is in its press release announcing v4.0.

What is the defined approach vs. the customized approach?

PCI DSS 4.0 gives you two ways to meet a requirement.

The defined approach is how PCI DSS has always worked. You implement the requirement as written, and your assessor checks it using the testing procedures in the standard. Compensating controls are still available here when a legitimate technical or business constraint stops you from meeting a requirement as stated.

The customized approach is new. Most requirements now include a customized approach objective, which describes the outcome the requirement is meant to achieve. Requirements without one can only be met the defined way. You can design your own control to meet that objective, document it in a controls matrix, and support it with a targeted risk analysis. The assessor then derives testing procedures to confirm the control works.

The customized approach is aimed at organizations with mature risk management and strong internal testing. Most small and mid-sized organizations will use the defined approach for nearly everything. We'll cover the customized approach in more depth in a separate post.

What are the biggest changes from PCI DSS 3.2.1?

The Summary of Changes sorts every change into three types: evolving requirements, clarifications or guidance, and structure or format changes. Many changes are wording and reorganization. The ones below are the most likely to create real work.

MFA for all access into the cardholder data environment

Under 3.2.1, multi-factor authentication (MFA) was required for administrators accessing the cardholder data environment (CDE) non-console, and for remote access into the network. Requirement 8.4.2 in 4.0 extends MFA to all access into the CDE, not only administrative access.

Requirement 8.5.1 adds rules for the MFA system itself. It must not be susceptible to replay attacks. It must not be bypassable by any user, including administrators, except where management has documented and authorized a time-limited exception. It must use at least two different types of factor, and every factor must succeed before access is granted. Both 8.4.2 and 8.5.1 are future-dated.

Longer passwords and stricter account management

Requirement 8.3.6 raises the minimum password length from seven characters to 12, or eight if a system can't support 12. Passwords must contain both letters and numbers. This is future-dated, so the seven-character minimum from 3.2.1 applies until March 31, 2025.

Some rules have loosened. Requirement 8.3.4 allows up to 10 failed login attempts before lockout, up from six. Requirement 8.3.9 still expects 90-day password changes where a password is the only factor. It now also allows an alternative: analyze each account's security posture dynamically and decide access in real time.

Application and system accounts get their own requirements (8.6.1 to 8.6.3). These cover controlling interactive logins, keeping passwords out of scripts and configuration files, and changing those passwords on a schedule set by risk analysis. All three are future-dated.

Targeted risk analysis

Targeted risk analysis is one of the biggest structural changes. Requirement 12.3.1 says that where a requirement lets you choose how often to do something, you back that choice with a documented analysis. It has to identify the assets being protected, the threats involved, and the factors that affect likelihood and impact, and it has to justify the frequency you chose. You review each analysis at least every 12 months. Requirement 12.3.1 is future-dated.

Examples of requirements that depend on it include:

• How often to review logs for lower-risk system components (10.4.2.1)
• How often to inspect point-of-interaction devices (9.5.1.2.1)
• How often to change passwords for application and system accounts (8.6.3)

Requirement 12.3.2 is a separate risk analysis for each requirement met through the customized approach. It applies immediately to anyone using that approach.

E-commerce payment page scripts

Two new requirements focus on the scripts that run in a customer's browser on your payment page:

• 6.4.3: Every payment page script that is loaded and executed in the consumer's browser must be authorized and have its integrity assured. Each one must also appear in an inventory with a written justification.
• 11.6.1: A change- and tamper-detection mechanism must alert personnel to unauthorized changes to the HTTP headers and contents of payment pages as the consumer's browser receives them. It must run at least once every seven days, or at a frequency set by targeted risk analysis.

Both are future-dated. Modern payment pages often load scripts from several third parties, so if one supplier is compromised, card data can leak from a page you never touched. Web standards such as Content Security Policy and Subresource Integrity can help with parts of this. The requirements themselves don't prescribe a technology.

Authenticated internal vulnerability scanning

Requirement 11.3.1.2 requires internal vulnerability scans to run with credentials. That lets the scanner check installed software versions and configuration rather than only what's visible over the network. Systems that can't accept credentials must be documented. Scanning accounts that allow interactive login must be managed like any other privileged account.

This is future-dated. Unauthenticated scans routinely overlook missing patches that only show up after a login, so expect more findings when you switch. Build time to work through them into your plan.

Other changes worth knowing about

• Requirement 1 now talks about "network security controls" instead of firewalls and routers, which reflects cloud security groups and virtual appliances.
• Requirement 12.5.2 asks you to document and confirm your PCI DSS scope at least once every 12 months and after significant changes. Service providers must do this every six months under 12.5.2.1, which is future-dated.
• Hashes used to render stored card numbers unreadable must be keyed cryptographic hashes (3.5.1.1, future-dated).
• Disk-level encryption on its own will no longer be enough to protect stored card numbers on non-removable media (3.5.1.2, future-dated).
• Public-facing web applications will need an automated technical solution that continually detects and prevents web-based attacks (6.4.2, future-dated).
• Audit log reviews must use automated mechanisms (10.4.1.1, future-dated).
• You'll need an inventory of bespoke and custom software and the third-party components built into it (6.3.2, future-dated).

What should you do now?

The transition period is generous, but the future-dated requirements are where most of the effort sits. A practical sequence looks like this:

1. Read the Summary of Changes first. It's shorter than the standard, and it shows you where to look. Then download PCI DSS 4.0 from the PCI SSC document library.
2. Agree on timing with your acquirer or assessor. Decide which version your next assessment will use, and when you'll make the switch.
3. Gap-assess the requirements that apply immediately. Roles and responsibilities, scope confirmation and the many clarified requirements all apply as soon as you assess against 4.0.
4. Build a roadmap for the future-dated requirements. MFA for all CDE access, authenticated scanning and payment page script controls may need budget, new tooling and process changes. Plan them into the next two budget cycles rather than leaving them until early 2025.
5. List where you'll need a targeted risk analysis. Find every requirement that lets you set a frequency, name an owner for each, and start drafting.
6. Confirm your scope. Map where account data is stored, processed and transmitted, including cloud services and third parties. Everything else in 4.0 builds on this.
7. Decide whether the customized approach is relevant to you. For most organizations, the answer will be "not yet". It's still worth knowing where it could help.

Frequently asked questions

Do we have to move to PCI DSS 4.0 right away?

No. PCI DSS 3.2.1 remains valid until March 31, 2024, and you can be assessed against either version until then. Use the time to plan the move rather than rush it.

Are the future-dated requirements optional until 2025?

They're best practices until March 31, 2025, so they won't count against you before then. Several of them involve new tooling or process changes that take months to roll out. If you treat 2025 as the start date, you'll probably miss it.

Does PCI DSS 4.0 change what is in scope?

The basic scoping principles haven't changed. Anything that stores, processes or transmits account data, or could affect its security, is in scope. What's new is that 4.0 expects you to formally confirm your scope every year and after significant changes.

Does the customized approach make compliance easier?

Usually not. It gives mature organizations flexibility, but it adds documentation, risk analysis and assessor work for every requirement you customize. For most small and mid-sized organizations, the defined approach will be simpler and cheaper.

Key takeaways

• PCI DSS 4.0 was published on March 31, 2022. Version 3.2.1 retires on March 31, 2024.
• Future-dated requirements become mandatory on March 31, 2025. Treat that as a finish line, not a start date.
• The changes most likely to create work are MFA for all CDE access, 12-character passwords, targeted risk analyses, payment page script controls and authenticated internal scanning.
• Start with the Summary of Changes, a scope review and a gap assessment. Then turn the future-dated requirements into a funded roadmap.