PCI DSS 8.6.3: Passwords/passphrases for any application and system accounts are protected against misuse
PCI DSS v4.0.1 control 8.6.3: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 8.6.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.6
Passwords/passphrases for any application and system accounts are protected against misuse as follows:
- Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.
- Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.
Summary
Passwords for application and system accounts have to be changed on a schedule you have justified with a risk analysis, and whenever you suspect compromise, with complexity that matches how often they change.
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.6.3.a | Examine policies and procedures to verify that procedures are defined to protect passwords/passphrases for application or system accounts against misuse in accordance with all elements specified in this requirement. |
| 8.6.3.b | Examine the entity’s targeted risk analysis for the change frequency and complexity for passwords/passphrases for application and system accounts to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1 and addresses: • The frequency defined for periodic changes to application and system passwords/passphrases. • The complexity defined for passwords/passphrases and appropriateness of the complexity relative to the frequency of changes. |
| 8.6.3.c | Interview responsible personnel and examine system configuration settings to verify that passwords/passphrases for any application and system accounts are protected against misuse in accordance with all elements specified in this requirement. |
The service-account counterpart to 8.6.2, which forbids hardcoded passwords for accounts that can log in interactively. Two things here are commonly missed. First, the change frequency is genuinely yours to set, but only if you have done the targeted risk analysis under 12.3.1: without it there is no defensible frequency and the control fails, because the flexibility is the analysis rather than a free choice. Second, procedure 8.6.3.b tests the analysis for both the frequency and the complexity, and for whether the complexity is appropriate relative to the frequency. That is a trade the standard expects you to reason about out loud: change rarely and it expects more complexity.
What to prepare
- The targeted risk analysis covering these accounts, addressing frequency and complexity and the relationship between them.
- A list of application and system accounts, with where each credential is stored.
- System configuration evidence showing the complexity actually enforced.
- A record of the last change for a sample of accounts.
How to implement it
1. Write the risk analysis before setting the frequency, not after. It is the thing being examined, and one written to justify a decision already made usually reads that way.
2. Argue the trade explicitly. If the answer is that these credentials are long, random and vaulted so annual rotation is enough, say so in the analysis. That is a sound argument, and it only counts if it is written down.
3. Put them in a secrets manager. Rotation is the hard part of this control operationally, and a vault turns it into a scheduled job instead of a change window.
4. Cover compromise separately from the schedule. The second trigger is suspicion or confirmation of compromise, which is an incident-response step, not a calendar one.
Where this commonly fails
- A frequency chosen sensibly with no targeted risk analysis behind it, which fails on the evidence rather than on the decision.
- A risk analysis that addresses frequency and says nothing about complexity, when the procedure tests both.
- Service account passwords that have not changed since the system was built, because rotating them means a restart nobody will schedule.
- The analysis performed for interactive user passwords and assumed to cover application accounts, which are a separate population.
Related controls
This control refers to 12.3.1.
Others in section 8.6:
| Control | What it requires |
|---|---|
| 8.6.1 | If accounts used by systems or applications can be used for interactive login, they… |
| 8.6.2 | Passwords/passphrases for any application and system accounts that can be used for interactive… |
← 8.6.2 · All controls · 9.1.1 →
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.