Cryptoperiod
PCIComplianceHubLast updated
The defined period during which a specific cryptographic key is authorised for use, after which it must be retired and replaced. PCI DSS requires a cryptoperiod to be defined for every key protecting account data, and requires keys to be changed at the end of it. The length is set by the organization, based on how much data the key protects, how exposed it is and the strength of the algorithm, and the reasoning must be documented rather than assumed. A shorter cryptoperiod limits how much data a single compromised key can expose.
Applies to. Requirement 3.7.4 applies to every key type used to protect stored account data: the key-management policy must state a cryptoperiod for each type and a process for changing the key when that period ends, and the assessor checks key storage locations to confirm changes happen. 3.7.5 then requires the expired key to be retired, replaced or destroyed and never used again for encryption. Service providers record each key's expiry date in the cryptographic architecture document under 3.6.1.1.
Example. A merchant sets a two-year cryptoperiod for its data-encrypting keys and a longer one for the key-encrypting key that wraps them, and records where the figures came from in its key-management policy. A calendar entry triggers the change before expiry; the old key is kept only for decrypting archived records until they are re-encrypted, then destroyed.
Limits. The standard does not set a number: 3.7.4 defers to the application vendor or key owner and to industry guidance, so the figure must trace to one of those rather than being picked arbitrarily. The cryptoperiod is a ceiling, not the only trigger: 3.7.5 also requires a key change when someone with knowledge of a key component leaves or a key is suspected of compromise. It applies to keys protecting stored account data; certificate validity under 4.2.1 and wireless key changes under 2.3.2 are separate obligations.