Short-Lived vs Long-Lived Certificates: Choosing Lifetimes by Risk and Automation

Every certificate lifetime is a bet: a long one bets that the private key will never leak and that revocation will work if it does, a short one bets that automation will never stop. Public TLS lifetimes are being forced down towards 47 days, Let's Encrypt now issues certificates valid for about six days, and service meshes and workload identity platforms rotate certificates in hours. At the same time, device certificates, code signing certificates, vendor integration certificates and CA certificates still run for years. This guide compares short-lived and long-lived certificates as two risk models: what each protects against, how each fails, what revocation still does for each, how much automation each demands, and how to decide and migrate per use case. It is written for PKI owners, platform and site reliability engineers and identity architects who manage certificates as machine identities.

Key takeaways

• Short lifetimes replace revocation with expiry. A certificate that lives for days limits the damage of a leaked key without relying on clients to check CRLs or OCSP, which the CA/Browser Forum now reflects by excluding short-lived certificates from its 24-hour and 5-day revocation deadlines.
• Short lifetimes turn the CA into a runtime dependency. If issuance or deployment stops, a fleet of short-lived certificates expires in days or hours, so renewal timing must leave room for an outage.
• Long lifetimes concentrate risk in the key and the revocation path. A stolen long-lived key stays useful for its whole validity and sometimes beyond, as the leaked expired code signing certificates in the NVIDIA case showed.
• Choose by use case, not by policy slogan. Workload mTLS and public TLS suit short lifetimes; roots, offline intermediates, some device identities and signing certificates stay long-lived with stronger key protection.
• Migrate by renewal path. Prove fully automated renewal and deployment for a service before cutting its lifetime, then cut in steps while measuring renewal failures.

The short answer

Use the shortest lifetime your renewal and deployment automation can reliably sustain with a safety margin, and no shorter. For public TLS the CA/Browser Forum schedule sets the ceiling anyway (see the Certificate Expiry Outages and 47-Day TLS Certificates Guide for the dates). For service-to-service mTLS inside platforms you control, lifetimes of hours to a day are normal when issuance is automatic. Keep long lifetimes only where the certificate cannot be renewed automatically or where it anchors trust (roots and offline intermediates), and compensate with hardware key protection, inventory, tested revocation and a replacement plan. A long-lived certificate you cannot replace quickly is a risk to record, not a design choice to defend.

What counts as short-lived and long-lived

There is no single cut-off. The Baseline Requirements define a Short-lived Subscriber Certificate as one with a validity period of 7 days (604,800 seconds) or less for certificates issued on or after 15 March 2026 (10 days before that). In practice, lifetimes fall into bands with different operating models.

The two models side by side

Short-lived certificates: threat model, architecture and failure modes

Threat model: short lifetimes address key theft and mis-issuance, the threats that revocation was meant to handle. Let's Encrypt explained its six-day certificates on exactly this basis: shorter lifetimes shrink the window in which a compromised key can be misused, revocation does not work very well in practice, and short lifetimes in effect require automation. ATT&CK tracks theft of certificates as T1649 Steal or Forge Authentication Certificates; a stolen certificate that expires in hours is worth far less to an attacker.

Architecture in words: a client beside the workload generates a key pair, proves its identity to an issuer (an ACME challenge for public certificates; a platform attestation, service account token or node identity for internal ones), receives a certificate and installs it without a restart. For public TLS, ACME clients use the ACME Renewal Information extension (RFC 9773, Standards Track, June 2025), which returns a suggested renewal window and a Retry-After value. In a service mesh, a local agent sends a certificate signing request to the mesh CA and hands the result to the proxy through an API; Istio's documentation describes the agent generating the key and CSR, istiod signing it, and the process repeating periodically for rotation. See the ACME and Automated Certificate Management Guide and the SPIFFE and SPIRE Guide.

Failure modes:

• Issuer outage becomes a service outage: if the CA, the ACME endpoint, DNS validation or the internal signing service is down for longer than the remaining lifetime of the oldest certificate, services start failing.
• Clock skew: with lifetimes measured in hours, a few minutes of clock drift on clients or servers causes "not yet valid" and "expired" errors. Time synchronisation becomes part of the PKI.
• Renewal storms: many clients renewing at the same moment hit rate limits; ARI randomises within a window for this reason.
• Bootstrap credential risk: the credential used to request certificates (ACME account key, DNS API token, node attestation) becomes the real long-lived secret. Protect it as you would the certificate it replaces.
• Pinning and caching: clients that pin a leaf certificate, or appliances that cache one, break on every rotation. See Certificate Pinning.

Controls: renew at no later than half of the lifetime for very short certificates so that an outage of up to half the lifetime is survivable; monitor issuance success rate as a service level; run the issuer with redundancy and consider a second issuer for public TLS; synchronise time on every host; and keep the issuing credentials in a secrets manager with narrow scope.

Long-lived certificates: threat model, architecture and failure modes

Threat model: a long-lived certificate is safe only while its key stays secret and its relying parties can be told to stop trusting it. Both assumptions weaken over time. The key is copied into backups, images and build systems; the revocation path depends on every client fetching and honouring status information. In the NVIDIA code signing certificate theft, two leaked certificates had already expired, yet Windows still accepted them for driver signing, and signed malware appeared within about a day; revoking them would also have broken legitimate drivers. Expiry did not retire them and revocation was not a clean option.

Architecture in words: an administrator or a lifecycle manager requests a certificate from an enterprise or public CA, installs it with its key on a server, appliance or device, and records the expiry somewhere. Renewal is an event, often a ticket, sometimes years away. Revocation is published through CRLs and, where still offered, OCSP. See the Certificate Revocation Guide.

Failure modes:

• Forgotten expiry: the owner leaves, the reminder goes to a dead mailbox, and the service stops on a date nobody tracked.
• Shared trust across many customers: in the Mimecast certificate compromise, one vendor-issued certificate used by many customers to connect to Microsoft 365 was compromised, and every affected customer had to delete the connection and set up a new one with a replacement certificate.
• Revocation not checked: many non-browser clients do not check revocation, or fail open when status is unavailable.
• Algorithm and CA lock-in: a long-lived certificate keeps an old key size, hash or root in service for years, which slows CA migrations and post-quantum planning.
• Key copies: the same key exported to load balancers, CDNs and backups multiplies the places it can leak. See Leaked TLS Private Key Response.

Controls: generate and keep keys in an HSM, TPM or managed key service where the platform allows it; record an owner team and replacement procedure for every certificate; test revocation end to end with the actual clients; segment trust so one certificate serves one customer, product or environment; and set a maximum lifetime per class in the Certificate Management Policy Template.

Revocation: where it still matters

Revocation is moving from the main control to a backstop. Three changes show the direction:

• Baseline Requirements: section 4.9.1.1 requires CAs to revoke within 24 hours or 5 days depending on the reason, with the exception of Short-lived Subscriber Certificates, for which the CA MAY support revocation.
• OCSP retirement: Let's Encrypt removed OCSP URLs from its certificates on 7 May 2025 and turned its OCSP responders off on 6 August 2025, citing privacy and cost, and warned that some non-browser software such as VPN clients might be affected.
• CRLs remain: as of November 2026 the Let's Encrypt profiles page lists CRL revocation information for its classic, tlsserver and shortlived profiles, so even six-day certificates carry a revocation pointer.

For long-lived certificates, revocation stays essential and must be tested with each client type. For short-lived certificates, plan incident response around stopping issuance and rotating the issuing intermediate if it is the thing compromised. For mass revocation events at a public CA, ARI lets the CA ask clients to renew early, which only helps if your clients support it.

Automation dependency and outage risk

Shorter lifetimes do not create new failure causes; they make existing ones happen more often and faster. A manual renewal step that fails once a year on a 398-day certificate fails several times a year at 47 days and every week at six days. The real question is the outage budget: how long can the issuer or the pipeline be down before the first certificate expires?

The figures are simple arithmetic and assume renewal is attempted at the stated point; follow the issuer's ARI window where one is offered. The trade-off is the core of this comparison: long lifetimes give a large outage budget and a large compromise window; short lifetimes give the reverse. Automation quality decides which risk you can carry.

Decision criteria by use case

Small organisations: use the managed certificate services of your cloud and CDN providers and an ACME client for anything else; avoid running a private CA unless you need one. Large organisations: separate issuers per environment, run a lifecycle manager for the long tail, and set lifetime targets per class. Compare options in Private PKI vs Public PKI.

Migration plan from long-lived to short-lived

1. Inventory and classify: list every certificate with issuer, lifetime, owner, endpoints and renewal path (ACME, platform-managed, connector, manual). Use the Certificate Inventory Register Template.
2. Fix the bootstrap credentials first: move ACME account keys, DNS API tokens and CLM service accounts into a secrets manager with per-environment scope.
3. Automate deployment, not only issuance: every renewal must reach all copies (load balancer, CDN, keystore) and reload the service, then verify the served serial number.
4. Pilot with an aggressive profile: run a low-risk service on the shortest profile available (for example a six-day or 45-day public profile, or a 24-hour internal profile) to expose weak spots early.
5. Step lifetimes down in rings: internal tools, then customer services, then regulated and high-traffic services; halve the lifetime at each step only after a full cycle without renewal failures.
6. Set the outage budget: agree how long the issuer may be down, set renewal timing to match, and alert on issuance failure rate, not only on days remaining.
7. Rollback: keep the previous certificate and key until the new one is confirmed in service, and keep the ability to issue a longer-lived certificate from the same issuer for a service whose automation breaks, recorded as a time-limited exception.
8. Retire the leftovers: anything still manual by March 2027, when public TLS drops to 100 days, needs a connector, a replacement platform or a documented exception.

Worked scenario

A payments company runs 4,000 certificates: public TLS on 397-day certificates renewed by tickets, internal mTLS on two-year certificates from an enterprise CA, and a partner API secured by one long-lived client certificate shared by 30 partners. A developer laptop is compromised and the internal mTLS key for a ledger service is copied. The security team revokes the certificate, then finds that three internal clients never check the CRL. The key remains usable for the 20 months left on the certificate unless every client is reconfigured.

The remediation plan follows this page. Internal mTLS moves to a mesh issuing 24-hour certificates, with the issuer run as tier-one infrastructure and renewal at 50% of lifetime. Public TLS moves to ACME with ARI on 90-day certificates now and the 45-day profile after one clean quarter. The shared partner certificate is replaced by one certificate per partner, each with a one-year lifetime held in partner HSMs, so one partner's leak no longer forces 30 reconnections. The root and offline intermediate remain long-lived. Six months later, a repeat laptop compromise would expose a key valid for less than a day.

Where identity fits

Certificates are machine identities, and shortening their lives shifts trust onto the identity that requests them. A workload attestation, ACME account key or node credential that can obtain certificates on demand is now the most valuable secret in the chain. Govern it like privileged access: owner, narrow scope, logging and rotation. See the Machine Identity, PKI and Certificate Lifecycle Guide and Static vs Dynamic Secrets.

Detection and measurement

• Median certificate lifetime per class: trending down towards the target for each use case.
• Issuance success rate: successful renewals divided by attempts, per issuer, with alerts below an agreed threshold.
• Renewals overdue: certificates past their renewal point and not yet replaced; target zero for more than one renewal interval.
• Long-lived exceptions: count of certificates above the class maximum, each with an owner and review date.
• Revocation coverage: share of client types tested to reject a revoked certificate, for classes that rely on revocation.
• Expiry incidents per quarter: target zero.

Log every issuance and renewal with requester identity, and compare served certificates found by scanning and Certificate Transparency against issuance records to catch certificates obtained outside the pipeline (ATT&CK T1588.004 Digital Certificates covers adversaries acquiring certificates).

Framework mapping

Common failure patterns

• Cutting lifetimes before automating deployment: renewal succeeds, the load balancer keeps serving the old certificate, and the outage arrives sooner than before.
• Treating expiry as retirement: platforms that accept expired certificates for some purposes, as in the NVIDIA case, keep a stolen key useful.
• One certificate for many tenants: a shared long-lived certificate turns one theft into a mass replacement, as Mimecast customers experienced.
• Ignoring the issuing credential: short certificates obtained with a long-lived, unscoped ACME key or DNS token move the risk rather than reduce it.
• Hard-coded renewal intervals: scripts that renew every 60 days break on 45-day or six-day certificates; renew by percentage of lifetime or ARI.
• Relying on OCSP in non-browser clients: VPN and embedded clients configured to require OCSP fail when CAs stop offering it.

Practitioner checklist

• Set a maximum lifetime per certificate class (public TLS, internal mTLS, device, signing, CA) in policy.
• Classify every certificate by renewal path and move manual ones to ACME, platform issuance or a connector.
• Automate deployment and reload, and verify the served serial number after each renewal.
• Agree an outage budget per issuer and renew at a point that leaves that margin.
• Run issuers as tier-one services with monitoring of issuance success rate.
• Protect long-lived keys in HSMs, TPMs or managed key services, and segment them per customer or product.
• Test revocation with each client type for classes that still rely on it, and remove dependence on OCSP.
• Store ACME account keys, DNS tokens and CLM credentials in a secrets manager with narrow scope.
• Enable ARI in ACME clients so CA-requested early renewal works.

Standards and references

• CA/Browser Forum: Baseline Requirements for TLS Server Certificates
• IETF: RFC 9773 ACME Renewal Information (ARI) Extension
• Let's Encrypt: Profiles
• Let's Encrypt: Six-day and IP address certificates
• Let's Encrypt: Ending OCSP support
• Istio: Security concepts
• Kubernetes: Configure Certificate Rotation for the Kubelet

Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · PKI and Certificate Lifecycle Maturity Model · Certificate Lifecycle Management RFP Template · SSH Keys vs SSH Certificates