3.7.4 Cryptographic key changes for expired keys
Defined Approach Requirements
3.7.4 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.
Customized Approach Objective
Cryptographic keys are not used beyond their defined cryptoperiod.
Defined Approach Testing Procedures
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).
Purpose
Changing encryption keys when they reach the end of their cryptoperiod is imperative to minimize the risk of someone obtaining the encryption keys and using them to decrypt data.
Definitions
A cryptoperiod is the time span during which a cryptographic key can be used for its defined purpose. Cryptoperiods are often defined in terms of the period for which the key is active and/or the amount of cipher-text that has been produced by the key. Considerations for defining the cryptoperiod include, but are not limited to, the strength of the underlying algorithm, size or length of the key, risk of key compromise, and the sensitivity of the data being encrypted.
Further Information
NIST SP 800-57 Part 1, Revision 5, Section 5.3 Cryptoperiods – provides guidance for establishing the time span during which a specific key is authorized for use by legitimate entities, or the keys for a given system will remain in effect. See Table 1 of SP 800-57 Part 1 for suggested cryptoperiods for different key types.
purpose
Verify that deletion of account data is successful and complete.
compliance strategies
- Deletion verification audits
- Automated deletion logs
typical policies
- Data Deletion Verification Policy
common pitfalls
- No verification of deletion
- Data remains after deletion
type
Process Control
difficulty
Moderate
key risks
- Data exposure due to failed deletion
recommendations
- Audit deletion logs and results
Eligible SAQ
- SAQ-D MERCHANT
- SAQ-D SERVICE PROVIDER
Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below. Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy