A certificate that is renewed but keeps the same private key, or a stolen key that stays valid until its certificate expires, gives an attacker as long as the certificate lives. D3-CERO Certificate Rotation is the MITRE D3FEND countermeasure that D3FEND defines as replacing "digital certificates and their private keys to maintain cryptographic integrity and trust, mitigating key compromise risks and ensuring continuous secure communications." It sits in the Harden tactic under Credential Rotation, itself a child of Credential Hardening, and D3FEND models it as a technique that regenerates a Certificate. This card covers what rotation hardens, which ATT&CK techniques D3FEND relates it to, where rotation is implemented, how to verify it and where it fails. It is written for PKI owners, platform engineers and NHI programme leads. For lifecycle management as a whole, see the Machine Identity, PKI and Certificate Lifecycle Guide.
Key takeaways
- Rotation means a new key, not only a new expiry date. D3FEND's definition covers certificates and their private keys; renewing with the same key leaves a stolen key useful.
- D3FEND lists four triggers. Expiry, a CA substitution needing a new root, new or changed certificate constraints, and a security breach.
- The ATT&CK links are inferred and broad. They come through the shared Credential artefact; for most rows rotation only shortens how long stolen material works.
- Automation is the control, not the calendar. D3FEND notes that enterprise rotation is complex and automated solutions should be considered; public TLS lifetimes falling to 47 days by March 2029 make manual rotation unworkable.
- Verify by watching the key change and the old one die. A rotation is complete when every consumer uses the new key and the old certificate is revoked or expired and nowhere in use.
D3-CERO at a glance
| Field | D3-CERO Certificate Rotation |
|---|---|
| D3FEND ID | D3-CERO |
| Tactic | Harden |
| Parent technique | Credential Rotation (sibling: Password Rotation), under Credential Hardening |
| Digital artefact | Certificate (D3FEND: the technique "regenerates" a Certificate); D3FEND also shows it hardening Credential |
| Triggers D3FEND lists | Certificate expiry; substitution of a new CA requiring a replacement root; new or modified constraints; a security breach |
| Typical implementation points | ACME clients and certificate managers, cloud certificate services, Kubernetes and service mesh issuers, AD CS autoenrolment, IoT enrolment protocols, OAuth client certificate registration |
| D3FEND reference | SSH: Password and Key Rotation; Couchbase server certificate rotation documentation (see also) |
| Main limitation | Rotation does not revoke: a stolen key remains valid until the old certificate is revoked or expires |
What rotation actually changes
Three operations are often called "rotation" and give different protection:
| Operation | New key? | Protects against a stolen key? | Typical use |
|---|---|---|---|
| Renewal with the same key | No | No: the old key still matches the new certificate | Keeping a pinned public key stable |
| Rekey (new key pair, new certificate) | Yes | Only after the old certificate is revoked or expires | Scheduled rotation; the D3FEND definition |
| Rekey plus revocation of the old certificate | Yes | Yes, once relying parties check revocation | Rotation after suspected compromise |
| CA or root rotation | Yes, at the issuer | Yes for issuer compromise, if the old root is removed from trust stores | CA substitution or distrust; see the CA Compromise and Mass Certificate Replacement Playbook |
NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management, treats rotation as one of a set of certificate policies alongside inventory, ownership, automation, revocation and private key security, and includes rekey or rotation upon reassignment or termination of the people who had access to keys. Rotation without an inventory misses certificates; rotation without revocation leaves the old key live.
Where identity and NHIs fit
Most certificates in an organisation identify machines: servers, services, devices, workloads and agents. Each is a non-human identity whose private key often sits in a file, a secret store or a container image. Short-lived workload certificates issued automatically, as in SPIFFE-based systems, turn rotation from a project into a property of the platform. Kubernetes is an example: its documentation states kubelet client certificates are issued with a one-year expiry, and when rotation is enabled the kubelet generates a new key and requests a new certificate from the API as the current one approaches expiry. For the credential-wide view, see D3-CRO Credential Rotation and Credential Rotation at Scale.
ATT&CK techniques D3FEND relates to D3-CERO
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CERO; every row below is inferred through a shared digital artefact and D3FEND labels these mappings experimental (checked November 2026).
D3FEND relates D3-CERO to techniques that act on a Certificate or on Credential and its sub-artefacts (passwords, Kerberos tickets, session cookies, access tokens). Rows are grouped by tactic. D3FEND also lists Keychain under an ID ATT&CK has since revoked; its ATT&CK v20 successor is T1555.001. Each ID was checked against ATT&CK v20. The last column is NHI Mgmt Group's assessment, not part of D3FEND: for most rows certificate rotation has little direct effect.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What certificate rotation changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| Credential Access | |||
| T1649 | Steal or Forge Authentication Certificates | Certificate | Strong for stolen keys: limits how long a stolen certificate and key work, fully only with revocation. Little effect on forgery through a misconfigured CA |
| T1558.001 | Golden Ticket | Sub-artefact: Kerberos Ticket Granting Ticket | None: Kerberos keys, not certificates, are what need rotating |
| T1110.001, T1110.002, T1110.003 | Password Guessing, Password Cracking, Password Spraying | Sub-artefact: Password | None directly; relevant only where certificates replace passwords |
| T1003.003, T1003.005, T1003.008 | NTDS, Cached Domain Credentials, /etc/passwd and /etc/shadow | Sub-artefact: Encrypted Credential | None directly |
| T1555.001 | Keychain | Sub-artefact: Encrypted Credential | Partial: certificate keys stored in a keychain stop working after rekey and revocation |
| T1539, T1528, T1606.001 | Steal Web Session Cookie, Steal Application Access Token, Web Cookies | Sub-artefacts: Session Cookie, Access Token | Minimal: tokens are rotated by their own lifetimes, though rotating a token-signing certificate invalidates tokens it signed where verifiers stop trusting the old key |
| T1552 | Unsecured Credentials | Same artefact: Credential | Partial: private keys left in files lose value once rekeyed and the old certificate is revoked |
| Lateral Movement | |||
| T1550.001, T1550.004 | Application Access Token, Web Session Cookie (Use Alternate Authentication Material) | Sub-artefacts: Access Token, Session Cookie | Minimal, as above |
| Privilege Escalation and Stealth | |||
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Sub-artefact: Access Token | None: local access tokens are unrelated to certificate lifetime |
| Persistence | |||
| T1098.001 | Additional Cloud Credentials | Same artefact: creates Credential | Partial: a rotation process that reconciles registered certificates against the inventory finds extra certificates an attacker added to an application |
See the MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide and the MITRE ATT&CK T1098.001 Account Manipulation.
Where it is implemented
| Platform class | Rotation mechanism | What to check |
|---|---|---|
| Public TLS endpoints | ACME clients or managed certificate services renewing automatically. See the ACME and Automated Certificate Management Guide | Whether the client generates a new key on renewal or reuses it |
| Kubernetes and service mesh | Kubelet certificate rotation, cluster issuers such as cert-manager, mesh certificate authorities with short lifetimes. See the cert-manager security guide | Pending certificate signing requests that stall rotation; workloads that cache the old certificate |
| Windows and AD CS | Autoenrolment and template-driven renewal | Templates that allow key reuse; certificates issued outside autoenrolment |
| Cloud applications and service principals | New certificate credential registered, consumers switched, old one removed | Old credentials left registered. See How to find expiring app secrets and certificates in Entra ID |
| Devices and IoT | Re-enrolment over EST or SCEP. See the IoT and Device Certificate Provisioning (EST, SCEP) Guide | Devices offline at renewal time |
| Signing keys (tokens, code) | Publish the next key, switch signing, retire the old key after tokens or signatures expire. See the JSON Web Key Sets (JWKS) and Signing Key Rotation Guide | Verifiers that cache keys beyond the overlap window |
Implementation steps
- Build the inventory. Every certificate, its key location, issuer, expiry, owner and consumers. Use the Certificate Inventory Register Template as a starting structure.
- Set lifetimes and rekey rules by class. For example (illustrative values, not a standard): workload certificates in hours or days, internal servers in months, public TLS following the CA/Browser Forum maximum. Require a new key at each renewal unless a pin or registration depends on the key.
- Automate issuance and deployment together. Rotation fails most often in the last step, reloading the service. Test that each consumer picks up the new certificate without a manual restart.
- Use overlap, then retire. Deploy the new certificate, confirm traffic uses it, then revoke or remove the old one. For pinned clients, ship the new pin first; see D3-CP Certificate Pinning.
- Write the emergency path. Rotation after compromise is a different procedure: rekey, revoke, check every relying party, and look for use of the old key. See the Leaked TLS Private Key Response and D3-CR Credential Revocation.
- Rehearse. Rotate a representative certificate of each class on a schedule in a pilot environment, with a documented rollback to the previous certificate (still valid during the overlap window).
How to verify it works
- Key change check: compare the public key hash before and after a scheduled rotation. Same hash means renewal, not rotation.
- Consumer check: after rotation, confirm every endpoint serves the new certificate (scan by serial number) and every client authenticating with a certificate presents the new one.
- Retirement check: confirm the old certificate is revoked or removed from each relying party's registration, and that no authentication succeeds with it.
- Emergency drill: time a full rotation of a sample service certificate from decision to last consumer switched.
| Metric (example targets) | What it shows | Target direction |
|---|---|---|
| Share of certificates renewed by automation | Dependence on manual work | Rising toward 100% |
| Share of renewals that generated a new key | Whether rotation is real | Near 100% outside documented pin exceptions |
| Certificates past their policy lifetime or within 7 days of expiry without a renewal job | Rotation backlog and outage risk | Zero |
| Old certificates still registered or trusted after rotation | Incomplete retirement | Zero |
| Time to rotate a compromised certificate across all consumers | Emergency readiness | Falling with each drill |
Limits, bypasses and failure patterns
- Shared certificate, slow replacement: in the Mimecast certificate compromise, the stolen certificate was used by many customer tenants, so rotation needed each customer to delete and recreate the connection, and Microsoft blocked the certificate at Mimecast's request. One certificate per customer or per workload keeps rotation and blast radius small.
- Every client holds the old key: the GitHub RSA SSH host key exposure forced a global host key rotation that broke clients and automation which had stored the old key until they were updated.
- Renewal without rekey: scheduled renewal reuses the key, so a key copied last year still works.
- Rotation without retirement: the new certificate is added but the old one stays registered on an application or trusted by a relying party; see Incomplete rotation breaches.
- Expiry-driven outages: NIST SP 1800-16 lists outages caused by expired certificates as a primary TLS certificate risk, and the intermediate in the chain can expire even when the leaf was renewed. See the Expired Certificate Outage Troubleshooting Guide.
- Unknown certificates: certificates issued outside the managed process are never rotated because nobody knows they exist.
Framework mapping
| Framework | Reference | Relationship to D3-CERO |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management; IA-5(2) Public Key-based Authentication | Changing and refreshing authenticators, including certificates and keys |
| NIST SP 800-53 Rev 5 | SC-12 Cryptographic Key Establishment and Management; SC-17 Public Key Infrastructure Certificates | Key lifecycle and certificate issuance |
| NIST CSF 2.0 | PR.AA-01 | Identities and credentials for users, services and hardware are managed |
| NIST SP 1800-16 | TLS Server Certificate Management | Inventory, ownership, automation, rekey and revocation practices |
| CA/Browser Forum | Ballot SC081v3 | Maximum public TLS certificate validity falling from 398 to 47 days between March 2026 and March 2029 |
Related countermeasures
- Parent and sibling: D3-CRO Credential Rotation and D3-PR Password Rotation.
- Eviction: D3-CR Credential Revocation finishes what rotation starts after a compromise.
- Detection: D3-CA Certificate Analysis flags expiring and misconfigured certificates and chains.
- Authentication: D3-CBAN Certificate-based Authentication depends on rotation to keep client certificates short-lived.
Practitioner checklist
- Keep an inventory of every certificate with key location, owner and consumers.
- Require a new key on every renewal unless a documented pin or registration needs the old one.
- Automate issuance, deployment and service reload together.
- Retire the old certificate after each rotation: revoke it or remove its registration.
- Use one certificate per workload or customer rather than shared certificates.
- Keep a separate, rehearsed procedure for rotation after compromise.
- Plan for 47-day public TLS lifetimes now.
- Report automation share, rekey share and old-certificate leftovers every month.
Standards and references
- MITRE D3FEND: Certificate Rotation (D3-CERO)
- NIST: SP 1800-16 Securing Web Transactions, TLS Server Certificate Management
- CA/Browser Forum: Ballot SC081v3
- Kubernetes: Configure Certificate Rotation for the Kubelet
- MITRE ATT&CK: T1649 Steal or Forge Authentication Certificates
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Certificate Expiry Outages and 47-Day TLS Certificates Guide · Certificate Renewal Runbook Template · MITRE D3FEND Guide