They should rotate keys before renewal whenever possible, and they should not rely on renewal to clean up exposure. If the old key remains valid, renewal only adds another certificate to the estate while leaving the compromised trust material in place.
Why key rotation should happen before certificate renewal
Certificate renewal and private key rotation solve different problems. Renewal extends trust for the same key pair, while rotation replaces the key material that could already be exposed, copied, or embedded in dependent systems. If the private key is the thing at risk, renewing the certificate first can preserve the exposure instead of reducing it.
That distinction matters because the certificate is only the signed wrapper around the key pair. When the key remains unchanged, the old trust relationship continues unless you deliberately retire it. Teams that treat renewal as a cleanup event often miss the real issue: the compromise or sprawl may already be in the private key, not the certificate expiry date.
For certificate lifecycle handling, use the rotation event to force a fresh trust anchor path, then reissue the certificate against the new key. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is a useful reference for how key protection and certificate lifecycle automation fit together in practice.
What changes when the old key is already exposed
Once a private key may have been copied, the question is no longer administrative convenience. Reissuing the certificate without replacing the key leaves the attacker with a still-valid authenticator for as long as that key is accepted. That is why renewal alone is insufficient when the key itself is the asset at risk.
This is especially true for long-lived keys used in automation, infrastructure, or service-to-service trust. The exposure may not be obvious from certificate status alone, and the estate can accumulate multiple valid certificates tied to one compromised key if renewal is handled mechanically. In that situation, the safer sequence is to rotate the key, then renew or reissue the certificate against the new material.
Key-management guidance supports the same order of operations: protect the key lifecycle first, then manage certificate continuity around it. NIST SP 800-57 Key Management is the clearest authority for treating cryptographic key lifecycle as distinct from certificate validity.
How to decide in production: rotation, renewal, or both
In normal operations, the right move is usually key rotation before renewal when the key pair can be replaced without breaking service. If the platform supports ACME, automated issuance, or seamless trust bundle updates, you should design the process so the new key is generated first, then the certificate is requested for that new key.
Use renewal-only only when the key is known to be protected, short-lived, and not the subject of the problem you are fixing. Even then, renewal should be viewed as continuity maintenance, not exposure remediation. If the objective is to reduce blast radius, shorten trust lifetime, or retire a suspected compromise path, the key must change first.
For practitioners dealing with service identities, the same principle appears repeatedly in incident response and lifecycle governance. NHIMG’s Guide to NHI Rotation Challenges explains why rotation planning must account for dependencies, and NHI Lifecycle Management Guide covers the broader lifecycle controls that keep renewal from becoming a false sense of cleanup.
Risk and Threat Considerations
The main risk is treating certificate renewal as a substitute for secret retirement. That leaves the same private key valid in the field, which means compromise, leakage, or unauthorized copying can survive the renewal event and continue to authenticate.
Failure mechanism: a renewed certificate is issued for the existing key pair, so any attacker or downstream system already holding the private key can keep using the same trust material until the key itself is revoked, replaced, or rendered unusable.
Impact: exposure persists across systems that trust that key, extending unauthorized access, delaying incident containment, and increasing the chance that multiple renewed certificates will be tied to the same compromised credential material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Key rotation and cryptoperiods are central to this certificate-and-key lifecycle decision. |
| Recommendation — Rotate the key before renewal when exposure is possible, then reissue the certificate for the new key. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Private key lifecycle is part of managing authenticators and their replacement. |
| Recommendation — Replace compromised key material before extending certificate-based access. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The question concerns cryptographic key handling and certificate-backed trust. |
| Recommendation — Manage key replacement as a distinct cryptographic control, not as a byproduct of renewal. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential lifecycle discipline underpins timely rotation of trust material. |
| Recommendation — Enforce lifecycle processes that retire exposed key material before refreshing certificates. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Renewal without rotation leaves long-lived secret material in place. |
| Recommendation — Shorten trust lifetime by rotating secrets before issuing replacement certificates. | ||
Practitioner Guidance
What to verify: confirm whether the renewal workflow generates a new key pair or only renews the certificate for an existing one. If the process does not replace the key, treat it as continuity only, not remediation.
Decision rule: if there is any credible chance the key has been exposed, copied, or embedded broadly, rotate first and renew second. If the certificate must be renewed before the cutover for operational reasons, schedule it as part of a controlled replacement sequence, not as the final step.
What good looks like: the estate ends with one retired key, one new key, and a certificate issued specifically for the new key, with the old trust material revoked or otherwise made unusable.
Practitioner takeaway: renewal preserves trust continuity; rotation reduces exposure. When the private key is the security problem, the correct sequence is to replace the key material before you extend the certificate that would otherwise keep it alive.
Related resources from NHI Mgmt Group
- Should organisations reuse private keys across certificate renewals?
- Should organisations rotate passwords, keys, and webhook URLs together after a breach?
- When should organisations rotate credentials after a supply chain incident?
- Should organisations enforce least privilege for AI agents before or after deployment?