PCI DSS v4.0: Forced Password Changes and Zero Trust Architecture

Under the old version 3.2.1, the PCI DSS mandated that all passwords must be changed at least every 90 days irrespective of the account, the access level, and other authentication systems – it simply stated that all passwords much be changed.

This has caused a great many discussions between PCI qualified security assessors (QSAs) and organisations over the years, as there are many security professionals who believe that the practice of forcing password changes is less secure due to the policy’s complexity and the inconvenience it imposes on users.  Also, many governmental advisory bodies have started to move away from this type of policy in recent times, leading to conflicts within organisations that need to meet several different security standards.  As such, a change to this requirement in the PCI DSS was necessary to bring it into line with current security standards and practices.

However, it’s not simply a matter of disabling the mandatory password changes, as the new Requirement 8.3.9 features two major changes: firstly, it now only applies to accounts using single-factor authentication, meaning that MFA accounts do not have to change their passwords at all, providing yet another reason to adopt MFA across the board.

Secondly, the Requirement now has two options for the remaining single-factor authentication accounts: mandatory password changes every 90 days, or ‘the security posture of accounts is dynamically analysed, and real-time access to resources is automatically determined accordingly.’  This second option is also known as zero-trust architecture, and the principle is detailed in one of the National Institute of Standards and Technology (NIST) Special Publications (SP 800-207), as are many of the security principles that the PCI DSS draws upon.

Whilst the intricacies of zero-trust can get very technical, the underlying principle is relatively simple.  Essentially, you start from a baseline of no person or system is allowed access to anything i.e. ‘trust no-one’, then each individual access request is dynamically analysed in real-time to determine whether access should be granted for that request.

This analysis will take in a wide range of data points to make its determination, including considerations such as: the device being accessed, the location of the access request, the user or systems requesting access, the time of the access request, the resources being accessed, the route taken from the request to the device, and the frequency of similar requests.  This allows each access request to be analysed based on its own merits and granted accordingly and, if a request is unusual, it could be an indicator that the account has been compromised and access will be denied by default.

Zero-trust architecture may initially seem like an ideal option to adopt as it could be managed by a large autonomous system, however it is important to note that such an architecture requires the deployment of an application or service that is capable of providing an effective zero-trust access architecture, and these services are not particularly cheap or easy to configure.  These services also require a level of ongoing resourcing to ensure they continue to operate effectively, which could impact your IT department’s day-to-day costs and available time.   Meanwhile, you would need to account for these access systems within your disaster recovery and business continuity plans.

All of which is not to say that these types of zero-trust systems are not effective at securing access in a way that traditional access control cannot achieve, but to make you aware that there are a great number of considerations that should guide your decision to use such systems. Zero-trust systems are not for everyone, and some organisations will unfortunately still have to mandate periodic password changes because after all: sometimes the simplest solution is the best one.