PCI DSS 3.6.1.4: Cryptographic keys are stored in the fewest possible locations
PCI DSS v4.0.1 control 3.6.1.4: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 3.6.
Requirement 3: Protect Stored Account Data › Section 3.6
Cryptographic keys are stored in the fewest possible locations.
Summary
Keys exist in as few places as possible.
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 | |
|---|---|
| 3.6.1.4 | Examine key storage locations and observe processes to verify that keys are stored in the fewest possible locations. |
The locations counterpart to 3.6.1.3, which limits the people. Every additional copy is another place to secure, to include in rotation, to destroy on retirement, and to lose track of, so the control is about copies rather than about the primary store. The procedure examines key storage locations and observes processes, which is the important part: copies are usually created by a process rather than by a decision. Backups, disaster recovery replicas, escrow arrangements, configuration management systems, container images, and the machine of whoever performed the last migration are all locations, and none of them felt like a decision to store a key. It pairs directly with 3.7.3, whose usual finding is that the primary store is correct and a second copy is somewhere ordinary.
What to prepare
- An inventory of every location a key or component exists, including copies.
- The processes that create copies: backup, replication, deployment, escrow.
- The justification for each location that remains.
- Evidence of removal where a location was eliminated.
How to implement it
1. Enumerate by following the processes, not by listing the stores. Copies are made by backup and deployment, so tracing those finds locations an inventory of stores does not.
2. Search source control history and build artefacts. A key committed once remains in history after the file is deleted.
3. Reduce before you document. Each location removed is one fewer to secure, rotate and destroy, and the shortest list is the easiest to defend.
4. Record why each remaining location exists. Fewest possible is a judgement, and the reasoning is what makes it assessable.
Where this commonly fails
- Backups holding keys alongside the data they protect.
- Keys in source control history after deletion from the working tree.
- Copies on engineer machines from a migration nobody cleaned up.
- Escrow or disaster recovery copies outside the inventory entirely.
Related controls
Others in section 3.6:
| Control | What it requires |
|---|---|
| 3.6.1 | Procedures are defined and implemented to protect cryptographic keys used to protect stored… |
| 3.6.1.1 | Service providers: A documented description of the cryptographic architecture is maintained… |
| 3.6.1.2 | Secret and private keys used to protect stored account data are stored in one (or more)… |
| 3.6.1.3 | Access to cleartext cryptographic key components is restricted to the fewest number… |
← 3.6.1.3 · All controls · 3.7.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.