Certificate Lifecycle Management in the 47-Day Era

A digital certificate is a file that proves who a website or system is and lets connections to it be encrypted. Certificate lifecycle management (CLM) is the practice of finding, requesting, issuing, deploying, monitoring, renewing, and retiring digital certificates in a controlled and mostly automated way. It matters more every year because publicly trusted TLS certificates are getting shorter lives. The maximum is already 200 days (since 15 March 2026), drops to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029, under CA/Browser Forum ballot SC-081v3. At 47 days, renewing by hand is no longer realistic.

What a certificate does, and what happens when it expires

Browsers and other software check a certificate on every connection. When it expires, those checks fail: browsers show a security warning, and apps and services that rely on the certificate can stop working. So every certificate needs someone to renew it before the expiry date, and renewing means getting a new certificate to replace the old one. The shorter the lifetime, the more often this has to happen.

What is changing, and when

The Baseline Requirements of the CA/Browser Forum set the schedule for publicly trusted TLS server certificates. Each step below applies to certificates issued on or after the date. Before issuing any certificate, the CA makes you prove you control the domain (domain validation), and that proof may be reused for a limited time, so each step also lists how long it can be reused:

• From 15 March 2026: maximum certificate validity of 200 days, and domain validation data may be reused for up to 200 days
• From 15 March 2027: maximum validity of 100 days, and reuse of domain validation data up to 100 days
• From 15 March 2029: maximum validity of 47 days, and reuse of domain validation data up to only 10 days

The ballot was approved in April 2025: 25 certificate issuers voted yes, none voted no, and 5 abstained, and all four browser vendors that voted (Apple, Google, Microsoft, and Mozilla) voted yes. These rules cover publicly trusted TLS certificates, the ones browsers must accept. Certificates you issue yourself from your own internal CA (not a browser-trusted CA) are not bound by these dates, but they gain the same benefits from automation. Your CA may also shorten lifetimes earlier than the Forum's dates, so read its announcements.

Why the industry is doing this

According to the ballot, shorter validity brings several benefits:

• Fresher information: certificate data stays closer to reality, so there are fewer stale certificates
• Less harm from mistakes: a wrongly issued certificate, or one whose private key (the secret file that goes with the certificate) was stolen, stops working sooner
• Revocation alone is not enough: the ballot says revocation services such as CRLs and OCSP have limits in scalability, reliability, and impact on users
• Faster cryptography changes: shorter lifetimes make it easier to move away from deprecated algorithms
• More automation: the ballot names the push toward automated lifecycle management as a side benefit

What 47 days means in numbers

Before 15 March 2026 the maximum was 398 days, so a certificate was replaced about once a year. Today's 200-day maximum means about 1.8 replacements a year, 100 days means about 3.7, and 47 days means at least 7.8 (365 divided by the lifetime). Let's Encrypt advises renewing about two thirds of the way through a certificate's life, which for 47 days is about every 31 days, or roughly 11.6 times a year (365 divided by 31.3). For 1,000 certificates, that is about 900 renewals a year at 398 days, about 1,800 at 200 days, about 7,800 at 47 days, and nearer 11,600 if you renew at two thirds of the lifetime. These figures are our own arithmetic, not a published estimate. With domain validation data reusable for only 10 days, nearly every issuance also needs a fresh proof of domain control.

The certificate lifecycle

• Discover: find every certificate in use, including ones nobody remembers requesting
• Assign an owner: each certificate has a named owner and a backup
• Request and validate: ask the CA and prove control of the domain
• Issue and deploy: install the certificate and key on the right systems
• Monitor: alert before expiry and on failed renewals
• Renew or rotate: replace the certificate, and the key when policy requires
• Revoke and retire: cancel certificates that are compromised or no longer needed, and remove them from systems

What to automate, and how

• ACME for public TLS certificates: ACME (RFC 8555) lets software request, validate, and renew certificates without a person. It is the standard way to automate public certificates
• ARI (ACME Renewal Information, RFC 9773): the CA tells the client when to renew, which helps avoid mass renewals at the same moment
• Renewal timing: Let's Encrypt says a fixed 60-day renewal schedule will not be enough once certificates last 45 days, because the certificate expires before the next run, and that renewing about two thirds of the way through is acceptable (45 days is the lifetime Let's Encrypt plans to use; 47 days is the Forum's maximum)
• Domain validation: DNS is the system that maps domain names to machines, and one way to prove control of a domain is a DNS record (a value set in DNS). Let's Encrypt described a new DNS-based method (DNS-PERSIST-01) in December 2025 that would let a DNS record be set once, and expected it in 2026 (as announced then), so check its current status
• Kubernetes and cloud: tools such as cert-manager, and the certificate services of cloud providers, handle renewals inside clusters and load balancers
• Devices on an internal CA: protocols such as EST (RFC 7030) let devices enroll for certificates automatically
• Monitoring: alert when a certificate is not renewed on time; do not rely on someone noticing

Where automation breaks

• Load balancers and appliances: older devices may not support ACME and need a vendor integration or a front proxy
• IoT and OT devices: limited software, hard-to-reach, and long lifetimes make renewals difficult
• SaaS with your own domain: the vendor may issue the certificate, so you must know who renews it
• Pinned certificates: apps that pin a certificate or key break when it changes
• DNS access held by another team: validation stalls if the team that controls DNS is not part of the process
• One certificate shared by many servers: a single renewal must reach all of them at once

Organize it: ownership and policy

• Central inventory: build it from several sources, such as network scans, public Certificate Transparency logs, cloud load balancers, and your CA accounts
• Policy: which CAs are allowed, key types and sizes, maximum lifetime, naming rules, and who may approve exceptions
• Key protection: keep private keys in a secrets manager or hardware module, never in shared folders
• Alert thresholds: set them as a share of the lifetime, because a fixed 30-day warning on a 47-day certificate would fire when the certificate is only 17 days old
• Link to identity: certificates are machine identities, so manage them with your other non-human identities, see Service Accounts and Non-human Identities: The Overlooked Risk
• Crypto agility: automated rotation is also what lets you change algorithms later, see PQC: Risks and How to Respond

NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management (June 2020), gives best practices for a certificate management program and an automated proof of concept for preventing, detecting, and recovering from certificate incidents. It remains a useful reference even though it predates these dates.

Start today

• Find your public certificates: search public Certificate Transparency logs for your domains and compare with your own list
• Mark the manual ones: list which certificates are renewed by hand today
• Choose an automation path for each type: ACME for web servers and cloud, an integration for appliances, and a plan for devices
• Test in a non-production system with a short-lifetime profile; Let's Encrypt offers an opt-in 45-day profile and an optional 6-day profile
• Set monitoring and a failure runbook: who is called, and what is the manual fallback
• Rehearse a failed renewal, see Network and Cyber Security Simulators: Types and Uses

To see how certificate management fits your wider identity and encryption controls, try the self-assessment.

Common mistakes

• Calendar reminders: a reminder to renew by hand does not scale to a certificate every few weeks
• No owner: nobody is responsible when a certificate expires, especially after staff changes
• Hard-coded renewal intervals: a script that renews every 60 days fails with 45-day certificates
• Ignoring non-web certificates: VPN, mail, device, and internal service certificates also expire
• Treating the Forum's date as your date: your CA may shorten lifetimes before that date
• Wildcards everywhere: one stolen key then exposes many sites, and it may hide who owns what

Scope and accuracy

The dates come from the CA/Browser Forum Baseline Requirements (Relevant Dates, as read on 21 October 2026) and the ballot SC-081v3 page. Let's Encrypt dates are from its December 2025 announcement. Confirm the current values with your CA and the latest Baseline Requirements before planning, since rules and CA schedules can change.

DKIM keys also need an owner and a replacement plan, like certificates. For how email keys are handled, see DMARC, SPF and DKIM: How to Set Them Up Correctly.

The private key behind a certificate is also an encryption key that needs an owner and a rotation plan. See Encryption Key Management: KMS, HSM and BYOK.

References and further reading

• CA/Browser Forum Baseline Requirements: the schedule under Relevant Dates, sections 4.2.1 and 6.3.2
• Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods: the vote and stated reasons
• Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days: rollout dates and advice for subscribers
• Let's Encrypt: Certificate Lifetime Rationale and Plans
• RFC 8555: ACME
• RFC 9773: ACME Renewal Information (ARI) Extension
• RFC 7030: Enrollment over Secure Transport (EST)
• cert-manager: certificate automation for Kubernetes
• NIST SP 1800-16: TLS Server Certificate Management