In 2006, the Payment Card Industry Security Standard Council (PCI SSC) launched a set of requirements to ensure that organizations that are processing, storing, or transmitting credit card information maintain a secure environment to help prevent card payment fraud.
Last week PCI DSS 4.0 was released, and the newest standards place significant emphasis on multi-factor authentication. Some changes don’t really seem like they’ll have an impact, but others have major change implications for call centers that are trying to stay PCI compliant. Here, we’re going to run through some of the major changes around identity security specifically that will impact IT teams and require major implementation changes. Let’s break down what is new, what has changed, and how this could impact your organization between now and when it takes effect.
Now that the updated PCI documentation has been released, organizations will have an extended transition period of 18 months to adjust from PCI DSS 3.2.1 to PCI DSS 4.0. This extended period will give organizations time to familiarize themselves with the changes, update their internal processes and documentation, and plan for and implement changes to meet updated requirements. PCI DSS 3.2.1 will be retired on March 31, 2024, and 4.0 will become the only active version of the standard at that time.
What Is New In PCI DSS 4.0
One of the most notable changes in the requirements update is the clear alignment PCI SSC has made with NIST SP 800-63B Digital Identity Guidelines. PCI DSS 4.0 focuses heavily on fostering stronger authentication requirements around NIST Zero Trust Architecture guidelines. This includes mandating that multi-factor authentication (MFA) must be used for all accounts that have access to the cardholder data, not just administrators accessing the cardholder data environment (CDE).
Password complexity has become stricter in PCI 4.0 but rotation requirements have relaxed.
The new password policy requirements are as follows:
8.3.6 If passwords/passphrases are used as authentication factors, they meet the following minimum level of complexity:
- A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
- Contain both numeric and alphabetic characters.
8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:
“ Best practices are to consider password changes at least once a year, a password/passphrase length of at least 15 characters, and complexity for the passwords/passphrase of alphanumeric characters, with upper- and lower-case letters, and special characters.”
What this means is that you’ll need to enforce at least 12 but probably 15 character alphanumeric passwords. These will rotate once a year, rather than once a quarter.
If you’re not already implementing complex passwords, this is probably going to be a major lift to get all your systems to implement the change, and then also, have all your users reset their credentials to meet the new standards. The bad news is that this process will almost certainly result in a heavy IT workload over the following few weeks with spiking credential resets as users struggle to adapt. The good news, however, is that once the initial flood of helpdesk tickets dies down, the relaxed rotation period of one year will probably result in a 75% reduction in credential resets at the helpdesk over time. If you stagger the rotation period across your users, you can avoid another huge peak in ticket loads next year when everyone’s credentials reset at the same time and the new complex passwords drive up locked accounts again. Our recommendation is therefore to get started on this early and roll it out to users' tranches evenly over a year.
For outsourced call centers and business process outsourcing (BPOs) specifically, there is an extra sub-requirement for credentials:
126.96.36.199 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either:
- Passwords/passphrases are changed at least once every 90 days, OR
- The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
What this means is that, in those environments where BPO agents are authentication into customer infrastructure with a username and password only, things will be tricky. The Password requirements remain the same, complex, but they will also need to be rotated. This change will also almost certainly be painful for both BPOs and BPO customers as credential resets mount. There is, however, a way around this, by implementing a dynamic Zero Trust security posture. If you can show auditors that you’re dynamically assessing identity risk, in real-time, you’ll be allowed to relax rotation to once a year. Most BPOs have high employee turnover, so you might end up almost never needing to rotate a password if you can thread this needle right.
These credential resets are a real headache. For IT, that reset needs to involve verifying the user’s identity, for example with a phone call, which is workload:
8.3.3 User identity is verified before modifying any authentication factor. Methods to verify a user’s identity include a secret question/answer, knowledge-based information, and calling the user back at a known and previously established phone number.
We’ve seen credential resets hover around 1%-3% of total headcount per day so this can really hurt. But PCI 4.0 has also given guidance on how to implement a self-service credential reset portal with knowledge-based authentication. The trick here is that it needs to be really easy to use. If it’s not, users will rather take a bunch of guesses, and here’s why that’s bad:
8.3.4 Invalid authentication attempts are limited by:
- Locking out the user ID after not more than 10 attempts.
- Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed.
If there’s one guess too many, that user will be locked out for 30 minutes of fully-loaded cost, and require extra time from IT for an unlock as well. While this new requirement will have an impact on credential resets, it was really designed to prevent MFA “prompt bombing” where an attacker with user credentials sends the authorized user repeated 2-factor challenges until they click yes out of exasperation.
Speaking of MFA, there are a lot of changes in 4.0 on that front.
PCI 4.0 doubles down on the importance of multi-factor authentication as protection for potential compromises. Security practices must evolve as threats change. The updated guidance is designed to address a variety of potential threats such as prompt bombing and social engineering. Authentication requirements are unchanged from PCI 3.2.1, where MFA requires two out of three distinct approved factors:
- Something you know, such as a password or passphrase.
- Something you have, such as a token device or smart card.
- Something you are, such as a biometric element.
Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication.
However, how MFA must be used has changed quite a bit. Previously, connecting work-at-home agents (WAHA) to the cardholder data environment (CDE) through a VPN, and requiring MFA to connect to the VPN was enough to pass muster with auditors. That one MFA challenge in the morning was all it took. 4.0 is explicitly changing that:
8.4.2 MFA is implemented for all access into the CDE.
“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,”
8.4.1 Administrative access to the CDE cannot be obtained by the use of a single authentication factor.
This requirement clearly states MFA is implemented for all access into the cardholder data environment, and step-up MFA is required. Previously, MFA was required for individual non-console administrative access and all remote access to the cardholder data environment, and network access as well. Furthermore, what was previously a suggestion based on NIST guidance about session timeouts is now a requirement:
8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
This means that you will need to challenge your users for MFA far more often. Also, all the apps that agents log into will each need to be protected with MFA as well. This is challenging from an implementation perspective, but also, will impact the bottom line. For every hundred agents, 1000’s of minutes each month will be spent on MFA challenges instead of calls. Single Sign-On (SSO) will need to become a priority since it will be far cheaper in the long run than integrating MFA into every single application. A 15-minute coffee break will result in an MFA-protected SSO reauthentication and save you the hassle of having to integrate your 2-factor tool into all your applications and reduce MFA challenges.
What PCI DSS 4.0 Means For The Future
The release of updated guidance means there are 18 months to review, plan, and implement updated security policies and procedures. With stronger authentication requirements being at the core of PCI DSS 4.0, it is critical that organizations review the section 8 requirements and develop a plan to meet them.
If you’re struggling to bring your organization’s identity security up to PCI DSS 4.0 compliance, Twosense can help. We provide Continuous Multi-Factor Authentication that’s a software-only biometric authenticator built specifically for Contact Centers that doesn’t require a mobile phone. Authentication is automatic and instantaneous, so there’s no delay, saving time and money. We can help with authentication on endpoints, web, and Single Sign-on, getting you PCI DSS 4.0 compliant with MFA everywhere and all the time with a deployment in a single afternoon.
As recent breaches against call centers have informed the new PCI guidance, strict adherence to PCI 4.0 is an organization’s best bet to protect against sophisticated threat actors and the tools they most commonly use.