Certificate Lifecycle Guide: 47-Day TLS and Automation

Certificates are machine identities: they prove which server, service, device or code signer is on the other end. For years many organisations managed them in spreadsheets and calendar reminders, renewing once a year and occasionally suffering an outage when one expired. That approach is ending. Public TLS certificate lifetimes are being cut in stages to 47 days by 2029, internal service meshes already issue certificates that last hours, and the move to post-quantum cryptography means every certificate and key will eventually need replacing. This guide explains certificate-based machine identity, the lifecycle, the changes coming, and how to build automated certificate lifecycle management.

Key takeaways

Under CA/Browser Forum ballot SC-081v3, the maximum lifetime of public TLS certificates falls to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Domain validation reuse falls to 10 days by 2029.
At those lifetimes, manual renewal stops being viable. Automation through protocols such as ACME becomes essential.
Most certificates in an organisation are internal, issued by private CAs for services, devices and workloads. They need the same inventory, ownership and automation.
Private keys are the real secret. Protect them, and use short-lived certificates so a stolen key is useful only briefly.
Start preparing for post-quantum cryptography now: know where your certificates and keys are, and make your PKI crypto-agile.

How certificates act as machine identity

An X.509 certificate binds a public key to an identity, such as a domain name, service name or SPIFFE ID, and is signed by a certificate authority (CA) that others trust. The holder proves its identity by using the matching private key, for example in a TLS handshake. Certificates are used for:

Public websites and APIs (TLS server certificates from public CAs).
Internal service-to-service mutual TLS, often via service meshes.
Workload identity (SPIFFE X.509 SVIDs). See our guide to SPIFFE and SPIRE.
Client authentication for devices, IoT and partners.
Code and container signing.
OAuth client authentication and certificate-bound tokens (RFC 8705). See the NHI Authentication Guide.
SSH certificates for automation access to servers.

The certificate lifecycle

Request: generate a key pair (ideally where the key will be used, without exporting it) and a certificate signing request.
Validate and issue: the CA checks the requester is entitled to the identity and issues the certificate.
Deploy: install the certificate and key on the endpoint, load balancer, mesh or device.
Monitor: track expiry, configuration, algorithm strength and where it is deployed.
Renew: replace before expiry, ideally with a new key.
Revoke: invalidate if the key is compromised or the identity is no longer valid.
Retire: remove from endpoints and inventory.

The shrinking lifetime of public certificates

The CA/Browser Forum, which sets requirements for publicly trusted TLS certificates, passed ballot SC-081v3 in April 2025. It sets this schedule:

From	Maximum certificate validity	Domain validation reuse
Before 15 March 2026	398 days	398 days
15 March 2026	200 days	200 days
15 March 2027	100 days	100 days
15 March 2029	47 days	10 days

The practical effect is that renewals roughly double in frequency in 2026, again in 2027, and reach around eight or more a year per certificate from 2029. Any certificate still renewed by hand is an outage waiting to happen.

Common failure patterns

Expiry outages: a forgotten certificate expires and takes down a service or partner integration.
Unknown certificates: certificates issued by teams directly from public CAs or internal CAs outside central visibility.
Private key exposure: keys stored in code, shared file systems, container images or backups. The ASP.NET machine keys case shows how publicly exposed keys can be turned into code execution.
Signing key compromise: the Microsoft signing key incident showed the impact when a key used to sign tokens is stolen.
Weak or outdated algorithms and self-signed certificates trusted everywhere.
Wildcard certificates shared across many systems, so one compromise affects all.
Trust store sprawl: outdated or unnecessary CAs trusted by applications and devices.

Building certificate lifecycle management

1. Discover and inventory

Scan networks and cloud load balancers for TLS endpoints; import from CA issuance logs and public Certificate Transparency logs for your domains.
Inventory internal CAs, trust stores, SSH CAs and code signing keys.
Record owner, application, location, issuer, expiry, key algorithm and key size for each certificate.

2. Assign ownership and policy

Every certificate has an owning team; certificates without owners are investigated.
Define approved CAs, algorithms, key sizes, maximum lifetimes and key storage requirements.
Restrict wildcard certificates and require separate certificates per service.

3. Automate issuance and renewal

Use the ACME protocol (RFC 8555) with public and internal CAs wherever supported.
Use native integrations for cloud load balancers, Kubernetes (certificate controllers) and service meshes.
Renew well before expiry, with alerting when automation fails.
Generate a new key at each renewal.

4. Protect private keys

Generate keys on the endpoint and keep them there; avoid exporting them.
Use hardware security modules or cloud key management for CA keys, signing keys and high-value keys.
Never store private keys in source code, images or shared storage.

5. Go short-lived internally

Internal PKI does not have to follow public CA timelines. Service meshes and SPIFFE implementations commonly issue certificates valid for hours, rotated automatically, so a stolen key has little value and revocation matters less.

6. Plan for revocation

Revocation checking is unreliable in many clients, which is another reason to prefer short lifetimes. For high-value identities, test that revocation actually stops access.

Preparing for post-quantum cryptography

NIST published its first post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM) for key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. NIST has also proposed timelines for deprecating and then disallowing today's quantum-vulnerable algorithms such as RSA and elliptic curve cryptography. Organisations should:

Build a cryptographic inventory, starting from the certificate and key inventory above.
Prioritise long-lived secrets and data that must stay confidential for many years.
Make PKI and applications crypto-agile, able to change algorithms without redesign.
Track CA, browser and library support for post-quantum and hybrid certificates.

Practitioner checklist

Inventory all public and internal certificates, CAs, trust stores and signing keys, with owners.
Set policy for CAs, algorithms, key sizes, lifetimes and key storage.
Automate issuance and renewal with ACME and platform integrations before March 2027 at the latest.
Generate new keys on renewal and keep private keys on the endpoint or in HSM/KMS.
Use short-lived certificates for internal workload identity.
Monitor expiry, automation failures and Certificate Transparency logs for your domains.
Start a post-quantum readiness plan based on your cryptographic inventory.

Machine Identity, PKI and Certificate Lifecycle Guide