What’s new in PCI DSS V4.0

(Last updated on May 24, 2022)

Organizations that store, process, or transmit cardholder data fall under the compliance framework known as PCI-DSS (Payment Card Industry Data Security Standard). It helps protect cardholders and businesses dealing with cardholder data from cyber attacks and breaches. The PCI Security Standards Council (PCI SSC) recently released version 4.0 of PCI DSS on March 31, 2022. What changes are included with PCI DSS v4.0?

What is PCI DSS?

The PCI DSS compliance framework has been a staple in the cybersecurity realm for businesses handling credit card transactions. The Payment Card Industry Data Security Standard was developed to encourage and enhance payment card account data security. It helps define consistent security measures to bolster payment card data security, processing, and storage. PCI DSS is not a government-created institution but rather is a collaboration of the major credit card companies, forming the PCI Security Standards Council. However, PCI DSS enforcement, in part, comes from the Federal Trade Commission (FTC).

It establishes core security requirements set to enhance and protect the security of payments. These include the following:

  1. Install and maintain network security controls
  2. Apply secure configurations to all system components
  3. Protect stored account data
  4. Protect cardholder data with strong cryptography during transmission over open, public networks
  5. Protect all systems and networks from malicious software
  6. Develop and maintain secure systems and software
  7. Restrict access to system components and cardholder data
  8. Identify users and authenticate access to system components
  9. Restrict physical access to cardholder data
  10. Log and monitor all access to system components and cardholder data
  11. Test security of systems and networks regularly
  12. Support information security with organizational policies and programs

In addition, it is worth noting that PCI DSS establishes a minimum baseline of technical and operational requirements for entities to protect account data and help prevent data breaches or other cyberattacks that can compromise the payment system workflow. So, it is not an end-all-be-all. There may be additional security measures on top of the guidelines established by PCI DSS that can enhance cardholder data security.

PCI DSS fines

Are there penalties for PCI DSS non-compliance? The PCI compliance framework has “teeth” in that it can lead to real-world fines for businesses required to comply but who are found to be non-compliant.

These fines can range from $5000 to $100,000 a month (4,000 to 80,000 GBP). Also, other penalties and consequences can affect businesses monetarily, such as higher bank transaction fees or possibly even termination of the relationship with the bank altogether.

Who falls under PCI DSS compliance?

There are specific entities that directly come under PCI DSS compliance. For example, the PCI DSS requirements apply to entities with environments where cardholder data is stored, processed, or transmitted and entities with environments that can impact the security of the cardholder data environment (CDE).

It is essential to understand that there are some cases where PCI DSS requirements also apply to entities outside of those that store, process, or transmit account data. For example, organizations that outsource payment operations or manage their CDE are still required to comply with some PCI DSS requirements.

What’s new in PCI DSS in 4.0?

In general, it is worth noting the twelve core tenant concepts of PCI DSS did not change with version 4.0 of the standard. These core standards are the framework’s pillars and still apply to organizations complying with PCI DSS. PCI DSS v4.0 is built on the concept of zero-trust, which is increasingly recognized as the best practice moving forward. However, interestingly with PCI DSS v4.0, there is an interesting new option for organizations meeting PCI DSS regulations — the customized approach to satisfying PCI requirements. Organizations can now choose between the defined approach and the customized approach.

With the customized approach, businesses can design their own security controls and standards to satisfy the PCI DSS v4.0 standard requirements and even modify the implementation procedures and meet the needs set forth. In addition, it allows businesses to demonstrate how they are meeting the security intent of each PCI DSS requirement. Companies may use new security approaches different from those outlined by traditional PCI requirements, providing an alternative way to meet the PCI DSS framework’s requirements.

It is worth noting when using the customized approach, a qualified security assessor (QSA) must review and determine if the custom controls defined by the customer are acceptable to comply with the requirements as outlined. However, this brings advantages for the customer and the ability to verify meeting the requirements satisfactorily.

The defined approach with PCI-DSS 4.0 remains relatively unchanged from prior versions. It is a detailed control statement and related testing the QSA must complete confirming the control is in place. Compensating controls are still a viable option and can be used when needed. The defined approach is ideal for organizations at the beginning stages of their cybersecurity and compliance initiatives, have budget constraints, or already have compensating controls in place that align with PCI-DSS requirements.

PCI DSS v4.0 has upped the level of protection for digital identities. Since many payment services and payment services processors and entities have moved to use cloud computing, more robust security and compensating controls are needed for securing authentication mechanisms. The new requirements, as outlined, more closely align with NIST best practices for accounts.

With PCI DSS v4.0, the following new additions have been made:

  • While general user accounts minimum password has been defined at 12 characters, with service accounts used by applications, services, and systems passwords, the recommendation is a password with at least 15 characters for complexity requirements, including alphanumeric characters, and that is checked against breached and other bad password lists
  • Organizations must implement more than just vendor defaults and think more about secure configurations across the board
  • Multi-factor authentication is required for all accounts that have access to in-scope PCI cardholder data environments
  • Companies must review access privileges at least every six months
  • Third-party accounts only need to be enabled when these are required for use and disabled otherwise. Proper account monitoring is necessary for these third-party accounts.
  • Otherwise, if a second factor is required, this specific expiry requirement has been removed

When are organizations required to implement PCI DSS v4.0?

There will be a transition period from PCI DSS v3.2.1 to the new v4.0 standard. Organizations will be required to be fully compliant by March 31, 2025. However, it will be prudent for businesses to start working towards making the transitions needed to comply fully by 2025.

PCI DSS v4.0 resources

Note the following official resources for PCI DSS v4.0:

Gaining visibility and protecting against weak and breached passwords

Notably, compromised accounts lead to cyberattacks, data leaks, and compliance violations such as those found in PCI DSS. With the more stringent account and password standards found in the new PCI DSS v4.0 framework, organizations do well to implement the technical requirements needed to protect against weak and breached passwords.

Many entities who must comply with PCI DSS compliance regulations use Active Directory as their Identity and Access Management (IAM) solution. Unfortunately, Active Directory contains no built-in capabilities to check for breached and other dangerous password types, including:

  • Reused passwords
  • Breached passwords
  • Well-known and easily guessed passwords
  • Incremental passwords
  • Leetspeak derived passwords
  • Others

Specops Password Policy with Breached Password Protection provides organizations with the tools needed to comply with PCI DSS v4.0 and other compliance framework requirements to protect account passwords. Specops Password Policy with Breached Password Protection offers the following benefits:

  • You can create custom dictionaries to protect against dangerous passwords for your business
  • Protect against billions of breached passwords
  • Gain visibility to weak or breached passwords already in your environment
  • Intuitive end-user messaging to help users create compliant passwords for their accounts
  • Dynamic user feedback during password change
  • Length-based password expiration with customizable email notifications
  • Block user names, display names, specific words, consecutive characters, incremental passwords, and password reuse
  • It integrates with existing Group Policy Objects to align with policies already in place in Active Directory
  • Support for passphrases
  • Multi-language support
  • Use regular expressions to create dynamically blocked password lists
specops password policy with breach password protection
Specops Password Policy with Breach Password Protection

Specops Password Policy with Breached Password Protection helps organizations satisfy the requirements of ensuring account passwords are protected against many of the typical weak and dangerous passwords often created by end-users.

Learn more about Specops Password Policy with Breached Password Protection here: Active Directory Password Filter – Specops Password Policy (specopssoft.com)

Three interesting points about the article

  • PCI DSS v4.0 keeps many of the same core concepts of v3.2.1 in place. However, it strengthens the requirements of account passwords and other areas around authentication and authorization
  • Organizations must be fully compliant with PCI DSS v4.0 by March 31, 2025
  • PCI DSS requirements apply to entities with environments where cardholder data is stored, processed, or transmitted and entities with environments that can impact the security of the cardholder data environment (CDE)

brandon lee writer

Written by

Brandon Lee

Brandon Lee has been in the industry 20+ years, is a prolific blogger focusing on networking, virtualization, storage, security & cloud, and contributes to the community through various blog posts and technical documentation primarily at Virtualizationhowto.com.

Back to Blog