PCI DSS 3.7.4: Key management policies and procedures are implemented for cryptographic key changes for keys
PCI DSS v4.0.1 control 3.7.4: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.7.
Requirement 3: Protect Stored Account Data › Section 3.7
Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following:
- A defined cryptoperiod for each key type in use.
- A process for key changes at the end of the defined cryptoperiod.
Summary
Decide how long each type of key may be used, write that down, and change keys when the time is up.
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.7.4.a | Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define changes to cryptographic keys that have reached the end of their cryptoperiod and include all elements specified in this requirement. |
| 3.7.4.b | Interview personnel, examine documentation, and observe key storage locations to verify that keys are changed at the end of the defined cryptoperiod(s). |
Two elements, and the first is where most entities fail before reaching the second: a defined cryptoperiod for each key type in use. The standard does not supply a number. It says the period is set by the application vendor or the key owner, based on industry best practices, which makes it your decision and your justification, in the same way 8.6.3 works for service-account passwords. An entity that has never written a cryptoperiod down fails 3.7.4.a on element one regardless of how often it happens to rotate. "Each key type" means the data-encrypting key and the key-encrypting key have their own periods, and so does anything else in use. Procedure 3.7.4.b observes key storage locations to check the changes actually happened.
What to prepare
- The cryptoperiod for each key type, written down, with the reasoning or the vendor reference behind it.
- The change process for each type, including what happens to data encrypted under the old key.
- Evidence of the last change per key type, with dates that can be compared to the period.
How to implement it
1. Write the number down first. It is the element that fails on its own, and it is an afternoon of work. Vendor documentation and published guidance give you a defensible basis; asserting a period with nothing behind it does not.
2. Set a period you can actually meet. A twelve-month cryptoperiod that has not been honoured is worse evidence than a longer one that has, because the gap between the document and the storage location is exactly what 3.7.4.b compares.
3. Plan re-encryption before you need it. Changing a data-encrypting key means re-encrypting the data, which is the reason key changes get deferred. Envelope encryption, where a data key is wrapped by a key-encrypting key, turns most rotations into rewrapping instead.
4. Give each key type its own entry. One period covering "all keys" does not meet the first element and hides the fact that the two types have very different practical constraints.
Where this commonly fails
- No cryptoperiod defined anywhere, which fails the first element before rotation is even discussed.
- A period defined and never reached, discovered when the assessor compares the document to the key store.
- One period asserted for every key type.
- Rotation deferred indefinitely because it requires re-encrypting the data, with no envelope scheme to avoid it.
Related controls
Others in section 3.7:
| Control | What it requires |
|---|---|
| 3.7.1 | Key-management policies and procedures are implemented to include generation of strong… |
| 3.7.2 | Key-management policies and procedures are implemented to include secure distribution… |
| 3.7.3 | Key-management policies and procedures are implemented to include secure storage… |
| 3.7.5 | Key management policies procedures are implemented to include the retirement, replacement… |
| 3.7.6 | Where manual cleartext cryptographic key-management operations are performed by personnel… |
| 3.7.7 | Key management policies and procedures are implemented to include the prevention… |
| 3.7.8 | Key management policies and procedures are implemented to include that cryptographic key… |
| 3.7.9 | Service providers: Where a service provider shares cryptographic keys with its customers for transmission… |
← 3.7.3 · All controls · 3.7.5 →
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.