It depends on your version. In cert-manager 1.18.0 and later, the default rotationPolicy is Always, so each reissue generates a new private key. In earlier versions the default was Never, so the same key was reused. Check your version, and set the field explicitly if anything pins the key.
What rotationPolicy does
The cert-manager documentation describes issuance behaviour for the private key. With rotationPolicy set to Always, the private key held in the Secret for a Certificate can be rotated as soon as the Certificate is reissued. cert-manager waits until the new certificate is correctly signed before overwriting the key file in the Secret, so a failed issuance does not leave you without a key.
The default change is stated plainly in the documentation. In versions at or above 1.18.0 the default is Always. In versions below 1.18.0 the default is Never, so the key was not rotated automatically.
Why rotating keys is generally good
A key reused across renewals means a stolen key stays useful for as long as you keep renewing. Fresh keys per renewal limit that window. The trade is discussed in reusing a private key on renewal.
What can break after an upgrade
If you upgraded across 1.18.0 and never set the field, your behaviour changed without a manifest edit. Check for anything that expects a stable key.
| Dependency | Problem with a new key each renewal |
|---|---|
| Public key pinning in clients | Pin no longer matches after renewal |
| TLSA or similar DNS records for the key | Record must be updated per renewal |
| Allowlists of client certificate keys in a partner system | Partner must accept the new key |
| Cached key fingerprints in config management | Drift reports on every renewal |
Pinning the leaf public key is generally discouraged for exactly this reason. See pinning guidance for ACME intermediates and certificate pinning on Android.
Steps to take
- Find your cert-manager version in the cluster.
- List Certificates that omit rotationPolicy. These follow the default for your version.
- Decide per Certificate whether a new key is wanted. For most server certificates, it is.
- For ones with pins or partner allowlists, either set Never temporarily and plan a migration, or update the consumer first.
- Set the field explicitly in manifests, so a future default change does not surprise you.
- After one renewal, confirm the public key in the new certificate differs when you expect it to.
spec:
privateKey:
rotationPolicy: Always
mTLS considerations
For client certificates used between services, key rotation is usually harmless because the peer validates against a CA, not a stored key. It becomes a problem only where the peer stored the specific key or certificate. Prefer trusting the issuing CA. See mTLS between services.
Where Safeguard fits
Safeguard does not manage keys or certificates. It provides SBOM and dependency scanning and policies and gates over manifests and code changes. Free scan: gold.safeguard.sh/scan.
Quick check
Which version changed the default?
cert-manager 1.18.0, according to the Certificate documentation.
Is the old key deleted before the new certificate is signed?
No. cert-manager waits until the Certificate is correctly signed before overwriting the key in the Secret.
Should I set the policy explicitly?
Yes. Explicit values protect you from default changes in later versions.
Sources
Last reviewed: 19 October 2026.
