Key Retirement and Replacement

PCI DSS 4.0.1 requires you to retire, replace, or destroy cryptographic keys whenever a key’s integrity is weakened, a key is suspected or known to be compromised, or the key reaches the end of its defined cryptoperiod (PCI DSS v4.0.1 Requirement 3.7.5). To operationalize it fast, you need a documented trigger-to-action playbook, owned workflows for rotation and revocation, and evidence that every affected system actually re-encrypts or re-wraps data with the new key.

Key takeaways:

• Define “cryptoperiod” per key type and system, then enforce rotation and retirement on schedule (PCI DSS v4.0.1 Requirement 3.7.5).
• Treat suspected compromise as an incident trigger: revoke, replace, and prove downstream re-encryption where applicable (PCI DSS v4.0.1 Requirement 3.7.5).
• Keep auditable artifacts: key inventories, rotation logs, approvals, and destruction records tied to tickets and change control (PCI DSS v4.0.1 Requirement 3.7.5).

“Key retirement and replacement” sounds like a narrow crypto requirement, but it becomes an operational control the moment you map it to real systems: payment applications, databases, backups, HSM/KMS platforms, tokenization services, and third-party payment flows. PCI’s expectation is simple: keys do not live forever, and keys that may be unsafe cannot remain in use. The hard part is proving you acted quickly, consistently, and completely across every place that key is used.

PCI DSS 4.0.1 Requirement 3.7.5 pushes you to formalize three things: (1) the conditions that force key retirement/replacement/destruction, (2) the mechanism that executes those actions safely, and (3) the evidence trail that shows you did it. Examiners will look past policy language and ask whether the rotation actually happened in production, whether old keys are disabled, and whether encrypted data, key-encryption-keys (KEKs), or wrapped keys were updated where necessary.

This page gives you requirement-level implementation guidance you can put into tickets, procedures, and audit binders quickly.

Regulatory text

PCI DSS 4.0.1 Requirement 3.7.5 states: “Key-management policies and procedures are implemented to include the retirement, replacement, or destruction of keys as deemed necessary when the integrity of the key has been weakened, keys are suspected of or known to be compromised, or upon reaching the end of the defined cryptoperiod.” (PCI DSS v4.0.1 Requirement 3.7.5)

Operator interpretation (what the assessor expects you to be able to show)

You must have implemented (not just written) key-management procedures that:

1. Define cryptoperiods for keys and enforce retirement/replacement at end-of-life.
2. Define compromise and weakness triggers (suspected/known compromise; weakened integrity) and execute retirement/replacement/destruction when those triggers occur.
3. Produce evidence that the key is no longer usable (retired/revoked), a new key is active, and impacted encryption/wrapping has been updated as required.

Plain-English interpretation of the requirement

If a key might be unsafe, or it’s old enough that it should no longer be trusted, you stop using it. You either:

• Retire it (remove from active use, keep only if needed for decryption under strict controls),
• Replace it (generate and put into service a new key, migrate usage), and/or
• Destroy it (securely eliminate it when no longer needed, with a record of destruction),

…and you do this based on defined triggers: weakened integrity, suspected/known compromise, or cryptoperiod expiration (PCI DSS v4.0.1 Requirement 3.7.5).

Who it applies to (entity and operational context)

Applies to: Merchants, service providers, and payment processors handling cardholder data environments where cryptographic keys protect account data (PCI DSS v4.0.1 Requirement 3.7.5).

Operationally, it applies anywhere you have keys, including:

• Database encryption keys (TDE, column-level, application-layer)
• Key-encryption-keys (KEKs) and data-encryption-keys (DEKs)
• HSM-managed keys and cloud KMS keys
• Tokenization vault keys (if you operate the vault)
• TLS private keys (if you terminate TLS in-scope)
• Backup encryption keys
• Keys managed by third parties on your behalf (you still need governance and evidence)

What you actually need to do (step-by-step)

Step 1: Build a key inventory that an auditor can reconcile

Create a living inventory with, at minimum:

• Key name/ID (from HSM/KMS), type (DEK/KEK/signing/TLS), algorithm, environment
• System(s) and data stores that use it (include backups and replicas)
• Owner (team) and operator (who can execute rotation)
• Cryptoperiod definition and next rotation/retirement date
• Escalation path for suspected compromise
• Dependencies (services, apps, batch jobs) that must be updated during rotation

If you cannot map “key → where it’s used,” you cannot prove retirement is complete.

Step 2: Define cryptoperiods and the three trigger categories

Write down what “end of cryptoperiod” means for each key class and platform, and how it’s enforced (PCI DSS v4.0.1 Requirement 3.7.5). Also define two additional trigger buckets:

• Integrity weakened: examples include policy-driven re-hardening events (configuration exposure, control failure, key stored outside approved boundary, access control drift).
• Suspected/known compromise: incident-driven triggers (alerts, confirmed exfiltration, unauthorized access to KMS/HSM, leaked private key, compromised admin account).

Keep definitions operational. “Weak integrity” must map to specific events your teams recognize and can ticket.

Step 3: Create a rotation/retirement runbook per platform (KMS/HSM/app)

For each platform, document:

• How to generate a replacement key (and required approvals)
• How to activate it for encryption or wrapping
• How to migrate workloads (re-wrap DEKs, re-encrypt data where applicable)
• How to disable the old key from new encryption operations
• Under what conditions the old key is retained for decryption only, and for how long (your policy decision)
• Rollback steps and validation checks

Assessors look for “implemented procedures.” A runbook that can be executed by on-call staff matters more than a high-level policy.

Step 4: Implement an event-to-action workflow (tickets + change control)

You need a reliable mechanism that turns triggers into action:

• Scheduled cryptoperiod rotations should auto-create tickets/change requests.
• Suspected compromise should open an incident and a linked emergency change.
• Weakened integrity should open a security exception or incident (your choice), but it must still force key action.

In practice, map each trigger to:

• Severity/priority
• Required approvers (Security, CCO/GRC for exceptions, system owner)
• Execution owner (SRE/Platform, Security Engineering)
• Evidence checklist (see below)

If you use Daydream to manage compliance operations, this is where it fits naturally: as the system of record that ties key inventory entries to tickets, approvals, and evidence uploads so you can answer assessor questions without rebuilding the story during the audit.

Step 5: Execute replacement and prove downstream effect

Replacement is not complete when the new key exists. You must show:

• New key is in active use for the intended operation (encrypt/wrap/sign/serve TLS).
• Old key is retired (cannot be used for new encryption) or destroyed if eligible.
• Data or wrapped keys were migrated where required.

Practical validation examples:

• KMS/HSM logs show encrypt operations moved to the new key.
• Application config references updated key alias/ID.
• Sample decrypt/encrypt tests confirm correct behavior.
• For TLS: certificate/key deployment updated and old private key removed from endpoints.

Step 6: Retire vs destroy: make it a deliberate decision

Set a rule: keys required to decrypt historical data may need retirement (decryption allowed, encryption disallowed). Keys with no remaining dependency should be destroyed with a record (PCI DSS v4.0.1 Requirement 3.7.5).

Common control: “decrypt-only” state (where supported), plus a documented retention rationale and restricted access.

Step 7: Add monitoring and periodic reconciliation

You need a control to catch drift:

• Reconcile key inventory against KMS/HSM key lists.
• Identify keys past cryptoperiod or keys still used after a retirement event.
• Review privileged access to key-management systems because compromise triggers often start there.

Required evidence and artifacts to retain

Keep evidence mapped to each trigger type and each key event:

Foundational artifacts

• Key management policy and procedures covering retirement/replacement/destruction (PCI DSS v4.0.1 Requirement 3.7.5)
• Key inventory (current, versioned)
• Cryptoperiod definitions by key class/platform

Per rotation/retirement/destruction event

• Ticket/change record showing trigger (scheduled cryptoperiod, weakened integrity, suspected/known compromise)
• Approvals (change approval, emergency approval where applicable)
• KMS/HSM logs or screenshots: key creation, key state change (enabled/disabled), scheduled deletion, destruction confirmation where supported
• Implementation records: config PRs, deployment notes, runbook checklist
• Validation evidence: logs showing new key usage, test results, post-change monitoring notes
• Exception record if you deferred rotation (with risk acceptance and a compensating control)

Common exam/audit questions and hangups

• “Show me your cryptoperiods and where they’re defined.” (PCI DSS v4.0.1 Requirement 3.7.5)
• “How do you know a suspected compromise triggers key replacement?” (PCI DSS v4.0.1 Requirement 3.7.5)
• “Prove the old key cannot be used for new encryption.”
• “Which systems still depend on the retired key for decryption?”
• “Show evidence for the last key replacement event end-to-end: trigger, approval, execution, validation.”

Hangup to expect: teams show key creation evidence but cannot prove migration. If encryption stayed on the old key alias, the control fails in practice.

Frequent implementation mistakes and how to avoid them

1. Policy-only compliance. Fix: require a runnable runbook and at least one executed rotation with full evidence (PCI DSS v4.0.1 Requirement 3.7.5).
2. No cryptoperiod per key type. Fix: define cryptoperiods per class (TLS vs DEK vs KEK) and enforce via automation where possible.
3. Rotation without dependency mapping. Fix: tie each key to systems and owners; block rotations without an impact list.
4. Retired keys still encrypt. Fix: enforce “encrypt disabled” controls, remove permissions, and validate with logs.
5. Third-party managed keys ignored. Fix: require contract/SOC evidence or shared responsibility documentation showing how the third party handles retirement and replacement; keep it with your PCI evidence set.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific cases. Practically, the risk is straightforward: if compromised or stale keys remain active, encrypted account data and authentication channels can become readable or impersonable, and incident scope expands because you cannot credibly limit which data was protected by trustworthy keys (PCI DSS v4.0.1 Requirement 3.7.5).

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Establish key inventory ownership and minimum fields.
• Document cryptoperiods for the highest-risk keys in-scope for account data.
• Draft and publish the trigger-to-action procedure for weakened integrity and suspected/known compromise (PCI DSS v4.0.1 Requirement 3.7.5).
• Run one tabletop for “suspected KMS admin compromise” and confirm the replacement workflow produces evidence.

By 60 days (Operationalize and automate)

• Build rotation runbooks per platform (cloud KMS, HSM, application-managed keys).
• Integrate scheduled rotations into ticketing/change management.
• Implement “retire vs destroy” decision rules and approval gates.
• Perform at least one planned cryptoperiod-driven rotation end-to-end and store all artifacts.

By 90 days (Coverage and audit readiness)

• Expand inventory to remaining key types (backups, TLS termination, batch encryption).
• Add reconciliation checks between inventory and KMS/HSM key lists.
• Review access control to key-management systems and tighten where needed.
• Package an “assessor-ready” evidence binder: policy, inventory, last rotation evidence, and a compromise-response key replacement example (even if from a drill).

Frequently Asked Questions

What’s the difference between retiring a key and destroying a key?

Retirement removes a key from active use (typically preventing new encryption) while possibly retaining it to decrypt historical data. Destruction permanently removes the key so data encrypted under it cannot be decrypted; you only do this when you are sure nothing still depends on it (PCI DSS v4.0.1 Requirement 3.7.5).

Do we have to replace a key if compromise is only “suspected”?

Yes, the requirement explicitly includes keys “suspected of or known to be compromised” (PCI DSS v4.0.1 Requirement 3.7.5). Your procedure can include triage steps, but your control must show you can execute replacement promptly when suspicion is credible.

What evidence is strongest for auditors?

A linked chain: trigger ticket → approval → KMS/HSM key event logs → deployment/config change → validation showing the new key is used and the old key is not. Screenshots help, but exported logs and change records are easier to defend (PCI DSS v4.0.1 Requirement 3.7.5).

How do we handle keys managed by a third party (for example, a payment service provider)?

Treat it as shared responsibility: document which keys they manage, what triggers cause rotation, and what evidence you receive (reports, attestations, contract clauses). Keep those artifacts with your PCI evidence to show the requirement is implemented for that outsourced function (PCI DSS v4.0.1 Requirement 3.7.5).

If we rotate a KEK, do we need to re-encrypt all data?

Often you re-wrap DEKs rather than re-encrypting the underlying data, but it depends on your architecture. Your runbook must state what changes (re-wrap vs re-encrypt) and include validation evidence that the new KEK is now protecting the relevant DEKs (PCI DSS v4.0.1 Requirement 3.7.5).

We missed a scheduled rotation. Is that automatically a failure?

It becomes a likely audit issue unless you have a documented exception with risk acceptance, compensating controls, and a committed remediation plan. Expect the assessor to ask how you prevented continued encryption under an expired cryptoperiod (PCI DSS v4.0.1 Requirement 3.7.5).