PCI DSS 8.6.2: Passwords/passphrases for any application and system accounts that can be used for interactive
PCI DSS v4.0.1 control 8.6.2: the requirement in full, the 2 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 that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.
Summary
No passwords in scripts, configuration files or source code for accounts that can log in interactively.
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.2.a | Interview personnel and examine system development procedures to verify that processes are defined for application and system accounts that can be used for interactive login, specifying that passwords/passphrases are not hard coded in scripts, configuration/property files, or bespoke and custom source code. |
| 8.6.2.b | Examine scripts, configuration/property files, and bespoke and custom source code for application and system accounts that can be used for interactive login, to verify passwords/passphrases for those accounts are not present. |
The control that turns a leaked repository into a breach. It is scoped to application and system accounts that can be used for interactive login, which is the pairing with 8.6.1: that control governs when such accounts may be used interactively at all, and this one governs where their credentials may live. The failure mode is not usually carelessness but history: a credential removed from the working tree remains in the commit that added it, and rotating is the only fix once it has been committed.
What to prepare
- Evidence of where such credentials are held instead: a secrets manager, a vault, or an injected environment.
- The scanning in place over source and configuration, and its results.
- Rotation records for anything found, since removal alone is not remediation.
How to implement it
1. Scan history, not the working tree. Anything ever committed is still retrievable, so the search that matters covers every commit and the fix is rotation rather than deletion.
2. Inject at deploy time. A secrets manager or the platform's own mechanism keeps the value out of the artefact entirely, which is a stronger answer than encrypting a file that ships with the code.
3. Include the places that are not source. Container images, CI configuration, infrastructure-as-code variables and build logs all carry credentials and are all searchable by whoever obtains them.
4. Make it a pipeline gate. Detection after the fact is a cleanup task; a pre-commit or pipeline check is what stops the next one, and it is cheap.
Where this commonly fails
- A credential removed in a later commit and still present in history, treated as resolved.
- Secrets in CI variables or container images, outside whatever scans the repository.
- Rotation skipped after a finding, so the exposed value is still valid.
- Only the application repository scanned, while infrastructure and deployment repositories are not.
Related controls
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.3 | Passwords/passphrases for any application and system accounts are protected against misuse… |
← 8.6.1 · All controls · 8.6.3 →
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.