WithPCI Logo
WithPCI.com

3.7.4 Cryptographic key changes for expired keys

Original requirement from PCI DSS v4.0.1

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