PCI DSS 3.6.1.2: Secret and private keys used to protect stored account data are stored in one (or more)
PCI DSS v4.0.1 control 3.6.1.2: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 3.6.
Requirement 3: Protect Stored Account Data › Section 3.6
Secret and private keys used to protect stored account data are stored in one (or more) of the following forms at all times:
- Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.
- Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device.
- As at least two full-length key components or key shares, in accordance with an industry-accepted method.
Summary
Secret and private keys exist in only one of three protected forms, at all times.
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.2.a | Examine documented procedures to verify it is defined that cryptographic keys used to encrypt/decrypt stored account data must exist only in one (or more) of the forms specified in this requirement. |
| 3.6.1.2.b | Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt stored account data exist in one (or more) of the forms specified in this requirement. |
| 3.6.1.2.c | Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify: • Key-encrypting keys are at least as strong as the data-encrypting keys they protect. • Key-encrypting keys are stored separately from data-encrypting keys. |
The words that make this strict are at all times and the fact that the three forms are an exhaustive list. A key protecting stored account data is either encrypted with a key-encrypting key at least as strong as the data-encrypting key and stored separately from it, or inside a secure cryptographic device such as an HSM or PTS-approved POI device, or split into at least two full-length key components or shares by an industry-accepted method. Anything else fails, including the common arrangement of a key in a configuration file protected by file permissions. Procedure 3.6.1.2.c is specific about the first form: wherever key-encrypting keys are used, it examines that they are at least as strong and stored separately, so a KEK weaker than what it protects, or sitting beside it, defeats the option that was chosen.
What to prepare
- Documented procedures stating the permitted forms, which 3.6.1.2.a examines.
- Every location a key exists, and which of the three forms applies there.
- For key-encrypting keys: their strength and their storage location relative to the key they protect.
- Evidence for the transient moments, such as during rotation or backup.
How to implement it
1. Pick one form per key and be able to name it. The control is a closed list, so "protected by permissions" is not an answer to which form is in use.
2. Check the key-encrypting key is genuinely separate. Two files in the same directory, or both in the same configuration store, is not separate storage.
3. Mind the phrase "at all times". Rotation, backup and disaster recovery are where a key briefly exists in cleartext, and those moments are in scope.
4. Use a managed service or an HSM where you can. It satisfies the second form outright and removes the argument about the first.
Where this commonly fails
- Keys in configuration files with file permissions offered as protection.
- A key-encrypting key weaker than the key it protects.
- KEK and DEK in the same store, so the separation element fails.
- Cleartext keys during backup or rotation, which "at all times" covers.
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.3 | Access to cleartext cryptographic key components is restricted to the fewest number… |
| 3.6.1.4 | Cryptographic keys are stored in the fewest possible locations |
← 3.6.1.1 · All controls · 3.6.1.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.