PCI DSS 8.3.8: Authentication policies and procedures are documented and communicated to all users
PCI DSS v4.0.1 control 8.3.8: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 8.3.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.3
Authentication policies and procedures are documented and communicated to all users including:
- Guidance on selecting strong authentication factors.
- Guidance for how users should protect their authentication factors.
- Instructions not to reuse previously used passwords/passphrases.
- Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.
Summary
Write down your authentication policy, give it to every user, and make sure they actually know what is in it.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 8.3.8.a | Examine procedures and interview personnel to verify that authentication policies and procedures are distributed to all users. |
| 8.3.8.b | Review authentication policies and procedures that are distributed to users and verify they include the elements specified in this requirement. |
| 8.3.8.c | Interview users to verify that they are familiar with authentication policies and procedures. |
Three procedures, and the third is unlike anything else in Requirement 8: 8.3.8.c interviews users to verify they are familiar with the policy. This control is tested on the people, not on the document. 8.3.8.a tests distribution and 8.3.8.b tests that the document contains the four named elements, so a policy can be complete, distributed, and still fail because the users the assessor picks have never read it. Practically this belongs with the awareness programme in 12.6.1 and the annual training and acknowledgement in 12.6.3, because those are the mechanisms that make the third procedure survivable.
What to prepare
- The authentication policy, checked against the four elements one by one.
- Evidence of distribution to all users, not only to staff who joined recently.
- Users available for interview, drawn from across the business rather than from the security team.
- The reporting route for a suspected compromised password, since it is a named element.
How to implement it
1. Check the four elements individually. Guidance on choosing strong factors, guidance on protecting them, instructions not to reuse previous ones, and instructions to change on suspicion plus how to report it. The last element is the one most often absent, because it is a reporting instruction sitting in an authentication document.
2. Fold it into the awareness training rather than issuing it separately. 8.3.8.c asks users what they know, and training with an acknowledgement is the thing that produces both familiarity and evidence.
3. Make the reporting route specific. "Report to IT" is weaker than a named address or number that the interviewed user can actually recall.
4. Write it for the reader. A policy that is understood is the whole point of the third procedure, and length is the usual reason it is not.
Where this commonly fails
- A complete policy that users have never seen, which passes 8.3.8.b and fails 8.3.8.c.
- The compromise-reporting element missing, since it reads like an incident-response topic.
- Distributed at onboarding only, so long-serving staff were never given the current version.
- Interviewed users naming a different process than the document describes.
Related controls
Others in section 8.3:
| Control | What it requires |
|---|---|
| 8.3.1 | All user access to system components for users and administrators is authenticated via at least… |
| 8.3.2 | Strong cryptography is used to render all authentication factors unreadable during transmission… |
| 8.3.3 | User identity is verified before modifying any authentication factor |
| 8.3.4 | Invalid authentication attempts are limited… |
| 8.3.5 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user… |
| 8.3.6 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity… |
| 8.3.7 | Individuals are not allowed to submit a new password/passphrase that is the same as any… |
| 8.3.9 | If passwords/passphrases are used as the only authentication factor for user access… |
| 8.3.10 | Service providers: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users… |
| 8.3.10.1 | Service providers: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either… |
| 8.3.11 | Where authentication factors such as physical or logical security tokens, smart cards… |
← 8.3.7 · All controls · 8.3.9 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.