PCI DSS 3.6.1.2: Retire and Replace Cryptographic Keys
Cryptographic keys don't last forever—and neither should yours. PCI DSS 3.6.1.2 requires documented procedures for retiring or replacing keys that have reached end of cryptoperiod or been compromised. Failure to do so leaves cardholder data vulnerable to decryption attacks.
What this means
This control mandates that organizations establish and maintain formal procedures for the lifecycle management of cryptographic keys. When keys reach their maximum allowed usage period (cryptoperiod) or are suspected of compromise, they must be systematically retired and replaced with new keys. The procedures must address how keys are deactivated, archived, and destroyed—ensuring no orphaned or expired keys remain in production environments that could weaken encryption protections.
How to comply
- 1.Document cryptoperiod limits for each type of cryptographic key used in your environment
- 2.Establish a key rotation schedule based on key type, sensitivity level, and risk assessment
- 3.Create procedures for detecting and responding to key compromise or suspected unauthorized access
- 4.Implement automated alerts when keys approach end of cryptoperiod to trigger replacement
- 5.Define key deactivation steps: disable in production, archive securely, and schedule destruction
- 6.Test key retirement procedures in non-production environments before production deployment
- 7.Maintain audit logs of all key retirements, replacements, and destruction events
- 8.Train personnel responsible for key management on retirement procedures and security requirements
- 9.Conduct periodic reviews of retired keys to ensure none remain accessible or in use
Evidence auditors look for
- Key management policy documenting cryptoperiod limits by key type and classification
- Key rotation schedule or automated job logs showing scheduled key replacements
- Incident response procedures for handling key compromise scenarios
- Configuration settings or policy rules enforcing key expiration and rotation
- Key retirement checklists completed and signed by authorized personnel
- Archived or destroyed key documentation with dates and personnel approval
- System audit logs showing key deactivation, archival, and destruction timestamps
- Key management system reports tracking active vs. retired keys over time
- Training records demonstrating staff understanding of key retirement procedures
Frequently asked questions
When will FAQs be available?
The FAQ for this control is currently being prepared.
GRCWatch automates key rotation scheduling, sends expiration alerts before cryptoperiod limits, logs all retirement events for audit trails, and consolidates evidence from your key management systems—eliminating manual tracking and ensuring no keys slip through unretired.
See how GRCWatch handles this control automatically
Start free trial