The 47-day certificate cycle is coming. Here's how to get ready before it hits.

Many organisations still manage TLS certificate renewals through a combination of spreadsheets, calendar reminders, and institutional knowledge held by one or two individuals. For annual renewal cycles, that approach was fragile but survivable. At 47-day cycles, it is not.

In April 2025, the CA/Browser Forum passed Ballot SC-081v3 with 25 votes in favour and none against (5 abstentions). Every major browser vendor (Apple, Google, Mozilla, and Microsoft) voted in favour. The vote mandates a phased reduction of the maximum validity period for publicly trusted TLS certificates, culminating in a 47-day maximum by March 2029. The first milestone, a reduction to 200 days, took effect on 15 March 2026.

This isn't a rumour or a proposal still under discussion. It's done. The timeline is fixed. The question is whether your organisation is building toward it or still treating it as a future problem.

Why are certificate lifespans getting shorter?

The reduction is driven by two structural problems with the current model.

The revocation problem

Certificate revocation mechanisms are not sufficient as a standalone safety net.

Due to limitations such as OCSP soft-fail behaviour, browsers may accept certificates even when revocation status cannot be reliably verified.

As a result, long-lived certificates (e.g. 200 days) create a large window of exposure if a private key is compromised.

By reducing certificate validity to 47 days, this exposure window is significantly minimized, even without relying on revocation mechanisms.

Crypto-agility and the path to post-quantum readiness

The longer-term driver is the need to build the operational capability to rotate cryptographic material quickly. As quantum computing advances, current asymmetric algorithms (RSA, ECDSA) will eventually need to be replaced.

Organisations that have automated certificate lifecycle management will be able to transition to post-quantum cryptography (PQC) algorithms without a disruptive manual effort.

While the primary goal of the 47-day requirement is to reduce risk and improve security, it also supports this transition by driving the adoption of automation and increasing crypto agility - capabilities that will be essential when algorithm changes become mandatory.

The phased transition timeline: what you need to know

The CA/B Forum deliberately defined a phased transition to give organisations time to adapt. These milestones apply to all publicly trusted CAs and are already in force.

March 15, 2026

Maximum 200 days (current)

A 50% reduction in certificate lifespan. Teams that were managing renewals annually now face approximately double the renewal volume. Manual processes start showing serious strain here.

March 15, 2027

Maximum 100 days

Renewal frequency increases to roughly four times the pre-2026 baseline.

March 15, 2029

Final: 47-day maximum

The final state. A maximum certificate validity of 47 days means approximately 7-8 renewals per certificate per year, compared to the roughly one renewal per year that applied before 2026.

At this stage, automation is no longer an option, it becomes a prerequisite.

What this means in practice: the numbers

Abstract timelines are easy to dismiss. The numbers are harder to ignore.

~ 100 renewals/yearfor 100 TLS certificates under the pre-2026 baseline

~8x more renewals per TLS certificate compared to pre-2026 baseline

~2 h average engineer time per manual renewal

Run that last one through:

For a team managing 100 TLS certificates, that translates into around 800 renewals per year. At ~2 hours per renewal, that is roughly 1600 engineering hours annually spent just on certificate renewal. That's not a workload. That's the equivalent of a full-time role dedicated to nothing else.

The math is simple: at 47-day cycles, manual certificate management doesn't scale. It simply stops working.

How to prepare for 47-day certificate lifespan: a practical checklist

Organisations that adapt smoothly will be those that invested in automation early. The 200-day phase is already here, but the move to 100 days in March 2027 is where the pressure really starts to show, particularly for teams still relying on manual processes.

1.      Audit your full certificate inventory

You can't automate what you can't see. Start by discovering every certificate across every environment. This includes public endpoints, internal services, load balancers, application servers, and network devices, including the ones nobody's touched in years. Certiligent’s discovery agent scans your infrastructure automatically and builds a centralised inventory with expiry timelines and ownership metadata, surfacing certificates that would otherwise stay hidden until they expire.

2.      Standardise certificate deployment

Automated renewal produces little benefit if certificate deployment remains manual. Deployment standardisation means ensuring that renewed certificates can be pushed to their targets through a consistent, automatable mechanism.

3.      Implement a certificate lifecycle management platform

A dedicated platform handles the full renewal workflow: monitoring expiry dates, triggering renewal requests, managing CA interaction and deploying renewed certificates without manual intervention for routine operations. Certiligent covers this end-to-end: from certificate discovery and issuance through to renewal, revocation, and audit logging, across heterogeneous environments and multiple CAs, via a centralised administration portal. The 47-day cycle runs in the background without anyone needing to manage it.

4.      Implement centralised alerting and audit logging

Even with automation, you want full visibility. Centralised dashboards, proactive alerts for anything that needs human attention, and audit logs for compliance. These are the guardrails that let you trust the system is working.

5.      Break up knowledge silos before they break you

If certificate management lives in one person's head, start codifying it now. Document processes, train the team, and make sure renewal knowledge is shared, not held. When that person goes on holiday in 2027, you don't want to find out the hard way.

Ready to see the difference for yourself?

Apply for a free trial, and we'll walk you through Certiligent with your own certificate setup.

Book Free Trial

Is this only a large enterprise problem?

The assumption that certificate automation is only relevant for organisations managing hundreds of certificates does not hold under 47-day cycles.

A SaaS platform managing TLS certificates for customer-facing subdomains, a financial services company operating a moderate number of APIs and web services under DORA, a DevOps team managing certificates across multiple Kubernetes clusters and environments, all of these feel the 47-day change. The absolute certificate count may be lower than a large enterprise, but the proportional impact on a team with no dedicated security operations capacity is often higher.

Teams that rely on manual processes and reactive monitoring will feel the impact of the 2027 milestone first. Starting the transition now, while still operating under the 200-day validity period, provides enough runway to implement and properly test automation before increased renewal frequency starts to make delays costly.

The case for acting now, not in 2027

The phased timeline exists for a reason: to give organisations time to adapt. The risk is that "phased" gets interpreted as "we can wait." The first mandatory milestone, the 200-day cap, has already been in effect since March 2026. That means that this thing is already in motion.

Building an automated foundation takes time. It means time to standardise deployments, integrate the right tools and make sure everything works reliably before you depend on it.

Teams that start now will have this foundation in place well ahead of the next milestones. Teams that wait until 2027 will be building under pressure, with shorter validity periods making every delay more visible and harder to absorb.

From an operational perspective, 47-day certificates are not more complex than annual ones, the same process just runs more frequently.

The real challenge is building the foundation that can support that frequency. That is the work to focus on now.

Ready to build that foundation?

Certiligent supports the full certificate lifecycle: discovery, issuance, renewal, revocation, audit logging across heterogeneous environments and multiple CAs, via a centralised administration portal and ACME v2-compatible server. For organisations preparing for the 2027 and 2029 milestones, contact the Certiligent team to discuss your current certificate estate and automation readiness.

Book Free Trial

One Persistent ID, Three Problems Solved: Fraud, Licensing, and Reinstall Abuse

Get that answer reliably, and a surprising amount of downstream work gets simpler. App Protector's new Get Device Identifier method exists to answer exactly that question. This article talks about a persistent, unique device identifier that survives app reinstalls, on both iOS and Android.

Why the obvious identifiers don't work

Most teams already have some form of device signal, they just don't have one that holds up. A few reasons why:

The result: most apps have a device identity that lasts exactly as long as the user wants it to. For fraud detection, licensing, and abuse prevention, that's close to useless.

Three problems, one underlying fix

Fraud detection

Mobile fraud increasingly relies on device churn. This includes uninstalling, resetting, or spoofing identifiers to look like a fresh, low-risk device on every attempt. A persistent identifier breaks that pattern: a device that's already been flagged, or that's associated with prior fraudulent sessions, stays recognizable even after a reinstall, a factory-reset-adjacent cleanup, or an attempt to appear new.

Licensing

For enterprise and B2B mobile apps, license enforcement usually assumes one install equals one seat. Without a persistent identifier, that assumption breaks the moment a user reinstalls, and it becomes trivially easy to share a single license across devices by uninstalling and reinstalling with different accounts. A stable device ID lets licensing logic tell the difference between "the same licensed device, reinstalled" and "a new device trying to claim the same seat."

Reinstall abuse.

Promotions, referral bonuses, and trial periods are usually scoped per device, which only works if a device can't simply erase its history by uninstalling. Reinstall abuse, claiming the same welcome bonus or trial repeatedly from one physical device, is a direct, measurable revenue leak for consumer and fintech apps alike, and it's specifically what a reinstall-resistant identifier is built to close off.

Where this fits with regulation, not just fraud teams

For regulated industries, this isn't only a fraud-ops nice-to-have. DORA already treats ICT risk controls, including fraud detection capability, as part of a financial entity's operational resilience posture, subject to supervisory scrutiny. And the incoming PSD3/PSR package is going to shift more fraud liability onto payment service providers directly, which raises the value of any signal that improves fraud detection accuracy before a transaction completes, not after. A persistent device identifier is exactly that kind of signal: it doesn't replace behavioral fraud detection, but it removes one of the easiest ways to defeat it.

Frequently Asked Questions

Get Device Identifier is a method in the App Protector SDK, available for iOS and Android, that returns a persistent, unique identifier for a device, one that remains consistent even after the app uninstall and reinstall.

Advertising identifiers are user-resettable, and app-generated UUIDs are wiped on uninstall. Get Device Identifier persists through reinstalls, which is what makes it useful for fraud detection, licensing, and reinstall-abuse prevention.

There are three main use cases for Get Device Identifier:

  • fraud detection (recognizing a device across sessions or reinstalls),
  • license enforcement (tying entitlements to a device rather than a resettable identifier),
  • reinstall abuse prevention (stopping repeated claims of per-device promotions or trials).

It should be governed like any persistent identifier. This includes documented purpose, proportionate retention, and use limited to the stated fraud/licensing/abuse-prevention purposes. It's a device signal, not a personal profiling tool, but that distinction should be clear in your data documentation.

Apply for Your Free 30-Day App Protector Trial

Get full access to advanced mobile security for 30 days, featuring both App Hardening to make your app tamper-proof and App Shielding to actively detect and block attacks in real time. Explore a user-friendly portal and see how your app stays protected at every stage. No upfront payment needed.

Protect My App Now

How to Manage TLS Certificate Renewals — Before It Becomes a Crisis

The reduction of TLS certificate validity to 47 days by March 2029 will significantly increase operational demands and risks for organisations that depend on the high availability of their digital services. While 2029 may seem distant, the process of shortening certificate lifespans has already begun, gradually reshaping how IT systems are managed.

"For large systems with tens or hundreds of certificates, moving to a 47-day validity period means a significant increase in operational load and risk of error. Certificate management is no longer an administrative activity, it's a critical operational function that directly affects the availability of digital services." — Marijana Mišić Mikulić, Product Manager, ASEE Croatia

The change particularly affects banks and financial institutions, e-commerce platforms, healthcare systems, telecoms operators, public sector bodies, and large enterprise organisations. In these environments, even a brief certificate expiry can cause service outages, security incidents, and serious financial and reputational consequences.

The Hidden Risks of Managing TLS Certificate Renewals Manually

Where organisations previously renewed certificates once or twice a year, from March 2029 they will face significantly more frequent renewal cycles. This accounts for every certificate across every system. In environments with a large number of certificates, this represents a shift from an occasional task to a permanent operational responsibility requiring continuous monitoring and management.

Without an automated process, every renewal means a manual intervention. At this scale, that is simply not sustainable.

What Are TLS Certificates and Why Do They Expire?

TLS certificates remain the cornerstone of digital service security. They enable encrypted communication, identity verification, and protection of sensitive data. Their expiry leads to application downtime, browser security warnings, and disruptions to business processes.

Visibility Is the Real Problem

In many organisations, certificate management is still treated as a technical task rather than a business continuity concern. But as renewal cycles compress, that perception is becoming a liability.

According to cybersecurity experts at ASEE, the biggest challenge organisations face is not the renewal itself, it's the lack of complete visibility across complex IT environments. Certificates are distributed across different systems, applications, and infrastructure components, which without automation creates significant room for oversight.

"The biggest challenge we see with clients isn't the certificate renewal itself. It's the lack of full visibility across complex IT environments. Certificates are spread across different systems, applications, and equipment, which without automation creates room for gaps." — Marijana Mišić Mikulić

Automation eliminates manual processes and reduces the possibility of human error, while continuous monitoring enables timely intervention before an incident occurs. Centralised visibility also simplifies infrastructure management and increases overall control.

How to Start Managing TLS Certificate Renewals Before It's Too Late

The organisations best positioned for the 2029 transition are those that start building the right processes and tooling now. Introducing automation and centralised certificate management takes time. Particularly in enterprise environments where systems are complex and change processes are governed carefully.

"Organisations with complex IT systems and large numbers of certificates should start preparing now. Those that ensure full certificate visibility and automate their processes in time will have a clear advantage in preserving the stability and continuity of their digital services." — Marijana Mišić Mikulić

ASEE has been developing cybersecurity solutions for the financial sector, public institutions, and enterprise systems for decades. Certiligent offers centralised oversight and automated lifecycle management for TLS certificates. It provides a unified view of all certificates, continuous monitoring, policy-based management, and automated renewal with timely expiry alerts. The group's solutions are used across 24 countries worldwide.

Ready to see the difference for yourself?

Apply for a free trial, and we'll walk you through Certiligent with your own certificate setup.

Book Free Trial