PCI DSS 3.7.4: Decide how long each type of key may be used, write that down, and change keys when the time is up.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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 has to exist before the second can be tested: 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, though unlike 8.6.3 for application and system account passwords, no targeted risk analysis is required, only a period grounded in industry best practices and guidelines. 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 the key change before you need it. At the end of the period a new data-encrypting key takes over encryption. Data under the old key is either re-encrypted or left under the old key, which is then kept decrypt-only and securely archived under 3.7.5. Envelope encryption turns key-encrypting key changes into rewrapping, but the data-encrypting keys still need their own changes.
4. Give each key type its own entry. A single line covering "all keys" makes it hard to show that each key type in use has a defined period 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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 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.