What are 47-Day Certificates: What’s Changing, Why It Matters, and How to Get Ready

The Certification Authority/Browser (CA/B) Forum has officially approved a reduction in the maximum validity period for publicly trusted TLS certificates to just 47 days by 2029. This change represents a fundamental shift in how organizations must approach certificate lifecycle management (CLM). While the security benefits are clear, the operational implications are substantial. Organizations that rely on manual processes will find this new reality unsustainable, making automation and governance not just recommended practices but operational necessities. 

What are 47-day certificates and which certificates are impacted?

The 47-day certificate mandate specifically applies to publicly trusted TLS certificates—the digital credentials that secure websites, public-facing applications, and certain edge infrastructure. These certificates authenticate servers and encrypt data in transit, forming the backbone of secure internet communications. 

• Publicly trusted TLS certificates are issued by certificate authorities (CAs) that browsers and operating systems recognize by default. They enable secure HTTPS connections for external users without requiring manual trust configuration. The 47-day limitation applies exclusively to these certificates. 

• Private or internal certificates, issued by an organization’s own private PKI infrastructure, are not directly affected by this mandate. Organizations can continue issuing internal certificates with longer lifespans if their use cases warrant it. However, many security-conscious organizations choose to mirror public certificate best practices across their private PKI to maintain consistent security postures and operational processes. 

The rollout follows a phased approach rather than an immediate drop to 47 days: 

• March 2026: Maximum validity drops to 200 days 

• 2027: Further reduction to 100 days 

• 2029: Final step down to 47 days maximum validity 

These validity periods include built-in renewal windows. The 47-day certificate, for example, is designed with approximately 30 days of intended operational life plus a 17-day buffer for renewal activities. This structure means organizations will need to renew certificates roughly every month, resulting in 8-12 renewal cycles per year per certificate depending on how much buffer time they maintain. 

The certificates affected by this change are often among an organization’s most critical assets. They don’t live in isolation on a single web server. A typical deployment might include: 

• Web servers and application servers 

• Load balancers that terminate TLS connections 

• Cloud workloads and containerized applications 

• Edge infrastructure and content delivery networks 

• API gateways and microservices endpoints 

One certificate might be deployed to multiple locations simultaneously—a load balancer, several application servers, and backup systems. This multiplicity amplifies the operational challenge of frequent renewals. 

How did the industry move from 10-year certificates to 47 days?

The journey to 47-day certificates spans more than a decade of gradual reductions: 

• Pre-2012: Certificates could be valid for 10 years 

• 2012: Maximum validity reduced to 5 years 

• 2015: Further reduction to 3 years 

• 2018: Drop to 2 years (825 days) 

• 2020: Current standard of 398 days (approximately 13 months) 

• 2026-2029: Phased reduction to 47 days 

The 2020 transition to 398 days offers important lessons for the current change. Google initially proposed shorter certificate lifespans and brought the measure to a vote at the CA/B Forum. The proposal was voted down. However, Apple independently announced that its native browser, Safari, would not accept certificates with validity periods exceeding 398 days, effectively forcing the entire industry’s hand. CAs had no choice but to comply, and other browsers followed suit. 

The current move to 47-day certificates follows a different pattern. This time, the change is CA-driven through the formal ballot process rather than being unilaterally imposed by a browser vendor. Apple introduced Ballot SC081v3, which proposed the phased reduction schedule, and it passed through the CA/B Forum voting process. Because CAs will not issue certificates exceeding these new validity limits, organizations have no alternative path—they must adapt. 

The industry reaction has been mixed. While security vendors and certificate authorities generally support the change, system administrators and PKI teams express significant concerns. Online discussions reveal the tension between security ideals and operational realities. One administrator questioned whether the next logical step would be “one-second certificates,” highlighting frustration with the pace of change. Others pointed out that many legacy systems and current infrastructure don’t support automated renewal protocols out of the box, creating a substantial technical debt problem. 

Why Are browsers and CAs pushing for 47-day certificates?

The drive toward 47-day certificates stems from three interconnected objectives that extend beyond simple security improvements. 

Stronger Security and Smaller Blast Radius 

Shorter certificate lifespans directly reduce the window of opportunity for attackers to exploit compromised certificates or private keys. The security principle mirrors password rotation policies: the more frequently credentials change, the less time adversaries have to leverage stolen or compromised credentials. 

This becomes particularly relevant in the context of “harvest now, decrypt later” attacks. Adversaries with sufficient resources can intercept and store encrypted traffic today, betting that they’ll eventually obtain the decryption keys or that quantum computers will make current encryption algorithms vulnerable. More frequent key rotation makes this strategy significantly harder to execute successfully. Each new certificate uses a fresh key pair, limiting the amount of historical traffic that any single compromised key can decrypt. 

When certificates do get compromised—through server breaches, misconfigurations, or supply chain attacks—shorter lifespans limit the damage. A compromised certificate with 47 days of validity poses a much smaller risk than one valid for a year. 

Forcing the Move to Automation and Modern PKI Practices 

Apple and Google are explicitly using certificate lifespan reductions as a mechanism to push the industry toward automated CLM. Manual renewal processes that might be tolerable with annual certificates become completely untenable when certificates must be renewed every few weeks. 

This forcing function is intentional. Manual certificate management at scale introduces human error, creates operational bottlenecks, and leaves organizations vulnerable to outages from expired certificates. By making manual processes operationally impossible, the industry effectively mandates that organizations adopt modern automation practices. 

The transition benefits extend beyond just preventing outages. Automated certificate management enables: 

• Consistent policy enforcement across all certificates 

• Reduced operational overhead and team burnout 

• Better visibility into certificate inventory and usage 

• Faster response to security incidents requiring certificate replacement 

• Foundation for handling future cryptographic transitions 

Preparing for Post-Quantum and Crypto-Agility 

The timing of the 2029 deadline is not coincidental. NIST has established a timeline for transitioning to post-quantum cryptography (PQC), with 2030 marked as the year when current algorithms like RSA and ECC will begin deprecation in favor of quantum-resistant alternatives. 

Organizations that have automated CLM by 2029 will be far better positioned to handle the post-quantum transition. Swapping cryptographic algorithms across thousands or millions of certificates requires the same automation infrastructure needed for frequent renewals. The 47-day certificate mandate essentially gives organizations a five-year runway to build the automation capabilities they’ll need for the quantum transition. 

Crypto-agility—the ability to quickly change cryptographic algorithms and key types across an entire infrastructure—becomes a competitive advantage and a security necessity. Organizations that wait until 2030 to address automation will face a chaotic scramble to replace algorithms while simultaneously managing short-lived certificates. 

What will 47-day certificates change for PKI and sysadmin teams day to day?

The operational impact of 47-day certificates extends far beyond simply renewing certificates more frequently. The change affects workflows, team dynamics, validation processes, and infrastructure management in fundamental ways. 

Renewal Frequency Explodes 

The most obvious change is the dramatic increase in renewal frequency. Organizations currently renewing certificates annually will shift to renewals every few weeks. A certificate that previously required attention once per year will now demand 8-12 renewal cycles annually. 

Gartner research indicates that end-to-end certificate renewal—from generating the key pair through final verification of deployment—typically requires 3-6 hours of human effort when performed manually. This includes: 

• Generating the key pair on the target system 

• Creating and submitting the certificate signing request (CSR) 

• Obtaining approval from the appropriate stakeholders 

• Waiting for CA validation and issuance 

• Downloading and installing the new certificate 

• Verifying proper installation and functionality 

• Potentially restarting services to activate the new certificate 

Multiply those 3-6 hours by 8-12 renewal cycles per certificate, then multiply by the total number of publicly trusted certificates in your environment. For organizations with hundreds or thousands of public certificates, the math becomes untenable without automation. 

Operational Burden and Burnout Risk 

Certificate management rarely falls solely on the PKI team. The end-to-end process typically involves: 

• PKI or security teams managing CA relationships and policies 

• Application owners who understand service dependencies 

• Infrastructure teams who manage servers and load balancers 

• Network teams who handle DNS validation 

• Change management teams who coordinate maintenance windows 

Each renewal cycle requires coordination across these groups. The multi-step nature of certificate renewal—key generation, CSR creation, CA validation, issuance, deployment, verification, and potential service restarts—creates multiple points where delays or errors can occur. 

The human cost extends beyond just time spent on renewals. Constant context switching, urgent renewal requests, and the stress of preventing outages contribute to team burnout. When certificate renewal becomes a weekly or bi-weekly task rather than an annual event, it can dominate team bandwidth and prevent work on strategic initiatives. 

Validation Window Shrinks 

Domain validation (DV) requirements are also tightening alongside certificate lifespans. Currently, domain ownership validation typically remains valid for a year. Under the new framework, DV validity drops to approximately 10 days. 

This means organizations must manage DNS TXT records or HTTP validation files far more frequently. For organizations with large domain portfolios, this creates a continuous validation campaign rather than an annual event. The validation process must be automated or it becomes another unsustainable manual task. 

Legacy and Multi-Hop Deployments Get Exposed 

Many certificate deployments are more complex than they appear. A single certificate might need to be installed on: 

• A load balancer that terminates TLS 

• Multiple application servers behind the load balancer 

• Backup or failover systems 

• Development and staging environments that mirror production 

Partial renewals—where a certificate gets updated on 9 out of 10 servers—create hidden outage risks. The tenth server continues using the old certificate until it expires, then fails. With annual renewals, these partial deployments might go unnoticed for months. With monthly renewals, the probability of partial deployments and resulting outages increases dramatically. 

The 47-day mandate will expose these complex, multi-hop deployment patterns and force organizations to document and automate them properly. 

What are the biggest risks if you don’t adapt? 

Organizations that fail to prepare for 47-day certificates face several categories of risk, ranging from operational disruptions to strategic vulnerabilities. 

Outages from Expired or Partially Renewed Certificates 

Certificate expiration outages follow a predictable pattern: a critical system stops working, users can’t connect, revenue is lost, and teams scramble to identify the cause. Eventually, someone discovers an expired certificate. By that point, everyone involved in the incident response has wasted hours, and the organization has suffered reputational and financial damage. 

The “certificate outage blame game” has become a running joke in IT circles—when a system goes down, everyone hides while trying to determine who’s responsible. Inevitably, the PKI team gets blamed, even when the root cause was lack of process, poor documentation, or unclear ownership. 

With 47-day certificates, the frequency of potential outages increases proportionally if processes remain manual. The certificates that matter most—those securing customer-facing services and critical business applications—are the ones most likely to cause visible, costly outages when they expire. 

Shadow IT and Unsanctioned Public Certificate Purchases 

When official certificate procurement processes are slow or cumbersome, business units often bypass them entirely. Application owners who “can’t wait for the PKI team” go directly to a public CA and purchase certificates using corporate credit cards. 

These shadow certificates exist outside official inventory and management systems. They’re subject to the same 47-day validity limits as officially managed certificates, but they have zero automation or visibility. When they expire, no one receives alerts, and no renewal process exists. 

The 47-day mandate will likely increase shadow IT certificate purchases initially, as teams look for quick solutions to frequent renewal requirements. Organizations must make official certificate procurement fast and easy, or they’ll lose visibility into significant portions of their certificate inventory. 

Wildcard Certificates as Single Points of Failure 

Wildcard certificates—which secure all subdomains under a domain (*.example.com)—are operationally convenient but create concentrated risk. A single wildcard certificate might be deployed across hundreds of servers and services. 

When a wildcard certificate expires, every system using it fails simultaneously. One gaming provider documented their experience with a wildcard certificate expiration that took down their entire backend infrastructure, affecting thousands of users. The incident became a public case study in what not to do with wildcard certificates. 

The 47-day mandate amplifies wildcard certificate risk. The more frequently a certificate must be renewed, the more opportunities exist for renewal failures. A wildcard deployed to 100 locations must be successfully renewed and deployed to all 100 locations every month. Miss even one, and you have a partial deployment waiting to cause an outage. 

Post-Quantum Scramble in 2030 

Organizations that haven’t implemented certificate lifecycle automation by 2029 will face a crisis in 2030 when post-quantum cryptography transitions begin. Replacing thousands of certificates with new algorithms while simultaneously managing 47-day lifespans manually is simply not feasible. 

The organizations that invest in automation now will treat the post-quantum transition as a configuration change—update the algorithm parameters, and let automation handle the rollout. Organizations without automation will face a multi-year project to manually replace every certificate while also trying to implement the automation they should have built years earlier. 

Where Are Most Organizations Starting From Today? 

Understanding the current state of certificate management in most organizations helps contextualize the challenge ahead. Despite advances in PKI technology, many organizations still rely on outdated approaches. 

Fragmented Tools and Visibility Gaps 

Typical certificate management environments consist of: 

• Spreadsheets tracking certificate inventory (often outdated) 

• Ad hoc databases maintained by individual teams 

• Network scanning tools that discover certificates on the wire 

• Multiple CA portals for different certificate providers 

• Custom scripts for specific use cases 

None of these tools provide complete, real-time visibility. The certificates that matter most—the ones securing critical services—are often the ones missing from official inventory. As one practitioner put it: “The certs that matter most are the ones not in your spreadsheet.” 

No Clear Ownership or Accountability 

In many organizations, certificate responsibility is diffused across multiple teams with no clear ownership. The PKI team might manage CA relationships, but application teams request and install certificates, infrastructure teams manage servers, and security teams set policies. 

This diffusion of responsibility creates a tragedy of the commons: if everyone owns certificates, no one owns certificates. When something goes wrong, finger-pointing becomes the default response rather than systematic problem-solving. 

Manual, Inconsistent Processes 

Even organizations with defined certificate processes often rely heavily on manual steps: 

• Application owners manually generate CSRs with inconsistent information 

• Approval workflows involve email chains and spreadsheet updates 

• Certificate installation requires manual SSH sessions or RDP connections 

• Verification depends on administrators manually testing services 

• Renewals are tracked in calendars and reminder systems 

Human error in CSR creation—typos in domain names, incorrect key sizes, missing subject alternative names—creates delays and rework. Manual processes are also slow, creating friction between security teams trying to enforce policy and application teams trying to deploy services quickly. 

Over-Reliance on Public Certs Where Private PKI Would Do 

Many organizations default to using publicly trusted certificates for internal services that never face the public internet. This happens for several reasons: 

• Private PKI infrastructure wasn’t available or was difficult to use 

• Application teams needed certificates quickly and went to public CAs 

• Lack of understanding about when public trust is actually necessary 

• Historical decisions that were never revisited 

Using public certificates for internal services creates unnecessary cost, operational overhead, and now, more frequent renewals than needed. The 47-day mandate provides an opportunity to reassess which services actually require public trust and move appropriate workloads to private PKI with longer lifespans. 

What Does a Modern 47-Day-Ready Certificate Lifecycle Look Like? 

Building readiness for 47-day certificates requires rethinking certificate management as an integrated system rather than a collection of manual tasks. The target state encompasses several key capabilities. 

Complete, Real-Time Inventory and Visibility 

Effective certificate management starts with knowing what certificates exist, where they’re deployed, and when they expire. This requires multiple discovery mechanisms: 

• CA integrations that pull certificate issuance data directly from public and private certificate authorities provide the authoritative source for what certificates have been issued. 

• Network discovery solutions scan TLS endpoints across the infrastructure, identifying certificates in active use. This catches certificates that might have been issued outside official channels or deployed without proper documentation. 

• Direct keystore and device discovery examines certificate stores, load balancers, cloud services, and applications directly. This approach finds certificates that might not be actively serving TLS connections but are still present in the environment. 

Combining these discovery angles provides comprehensive visibility. No single method catches everything, but together they create a complete picture. 

Defined Governance, Ownership, and Policy 

Clear ownership and accountability prevent the finger-pointing that typically follows certificate incidents. Effective governance includes: 

Defined owners for each certificate or category of certificates who are responsible for renewals, updates, and incident response. 

• Role-based workflows that route certificate requests, approvals, and renewals to the appropriate teams based on the certificate’s purpose and risk level. 

• Standardized profiles that define acceptable key sizes, algorithms, lifetimes, naming conventions, and wildcard policies. Standardization reduces errors and ensures consistency. 

• Policy enforcement that prevents issuance of certificates that don’t meet organizational standards, catching problems before certificates are deployed. 

Automation Across the Full Lifecycle, Not Just Enrollment 

True automation extends beyond just requesting and receiving certificates. It encompasses: 

• ACME and similar protocols for automated enrollment where they fit. ACME works well for web servers and Kubernetes environments but doesn’t solve every use case. 

• Cert-manager for Kubernetes environments, with appropriate integrations to certificate authorities.  

• Infrastructure-as-code integration with tools like Terraform, allowing certificate provisioning to be part of automated infrastructure deployment. 

• Certificate lifecycle management (CLM) and orchestration for complex, multi-hop deployments and legacy systems that don’t support modern protocols. Orchestration solutions can deploy certificates to diverse targets including load balancers, application servers, certificate stores, and remote file systems. 

• Alerting and confirmation that certificates aren’t just issued but actually deployed and active. Issuance without deployment creates a false sense of security. 

Separation of Concerns for Restarts and Change Control 

Some CLM tools offer the ability to automatically restart services after certificate deployment. While this sounds convenient, it introduces risk. Automatically restarting production services without proper change control can cause unplanned outages. 

A better approach separates certificate deployment from service restarts: 

• Automation solutions handle certificate renewal and deployment 

• The system notifies change management that a new certificate is in place 

• Change management coordinates service restarts during approved maintenance windows 

• Proper monitoring and alerting catch any issues with the restart process 

This separation ensures that certificate renewals happen on the necessary timeline while service restarts follow appropriate change control procedures. 

How Does Keyfactor Fit into the Shift to 47-Day Certificates? 

Although the move to 47-day certificates is driven by public CAs and browsers, organizations—not the CAs—bear the operational burden of frequent renewals. Keyfactor’s role is to help them manage this change effectively. 

Keyfactor Centralizes Visibility Across All Certificates 

Keyfactor Command provides full discovery across CA-issued certificates, network endpoints, and certificate stores. This multi-angle approach helps organizations identify unknown or unmanaged certificates that pose outage risks. The platform supports both public and private PKI environments, giving teams a single source of truth for their entire certificate inventory regardless of where certificates originated or how they’re deployed. 

CA-Agnostic Management Simplifies Operations 

Organizations often rely on multiple CAs—different providers for different use cases, legacy relationships, or geographic requirements. Managing each CA separately becomes unmanageable with short-lived certificates. Keyfactor allows teams to standardize processes and policies across all CAs in one platform. This eliminates the inconsistencies and inefficiencies of juggling multiple portals, each with different interfaces and workflows. 

Automating the Complete Renewal Workflow 

Short lifetimes require more than ACME enrollment; organizations must ensure deployment, verification, and continuous monitoring. Keyfactor automates end-to-end lifecycle tasks, reducing the 3-6 hour manual renewal process to a scalable workflow. The platform’s orchestration capabilities ensure certificates actually reach every endpoint in a multi-system deployment, not just the first server in a chain. 

Discovering Cryptography Across the Enterprise 

Beyond certificates, organizations need visibility into cryptographic algorithms, keys, and dependencies. Keyfactor’s crypto discovery solutions help teams understand where cryptography is used and whether it is outdated or vulnerable. This is critical preparation for future transitions such as post-quantum cryptography. Teams can identify which systems use which algorithms, assess the scope of required changes, and plan migration strategies before the 2030 deadline. 

Laying the Foundation for Crypto-Agility 

Organizations that automate certificate management now will be better prepared for upcoming industry shifts. Keyfactor provides the infrastructure and automation needed to replace certificates or algorithms at scale. When post-quantum algorithms become mandatory, organizations with mature CLM can treat the transition as a configuration change rather than a multi-year crisis project. 

How Should Organizations Start Preparing Now? 

Preparing for 47-day certificates doesn’t require implementing everything at once, but it does require starting now. Organizations have a multi-year runway to build capabilities before the 2029 deadline. 

• Start with visibility and inventory. Before you can automate certificate management, you need to know what certificates exist. Implement discovery across public and private CAs, network endpoints, and certificate stores. Document shadow IT certificates and wildcard deployments. Understanding your current state is the foundation for everything else. 

• Classify certificates by risk, environment, and automation feasibility. Not all certificates are equal. Customer-facing web services require different treatment than internal development systems. Identify which certificates are most critical to business operations and which are easiest to automate. This classification guides prioritization. 

• Standardize policies and clean up obvious issues. Before automating bad practices, fix them. Eliminate unnecessary wildcard certificates, move internal services to private PKI where appropriate, standardize key sizes and algorithms, and establish clear naming conventions. Clean up your certificate environment before you automate it. 

• Pilot automation in a contained domain. Choose a well-defined subset of your certificate inventory for initial automation—perhaps web front-end servers or a specific application stack. Implement end-to-end automation for that domain, learn from the experience, and document what works. Then expand to additional domains incrementally. 

• Use the 47-day change as a catalyst to modernize both public and private PKI. While the mandate only affects public certificates, the automation and governance capabilities you build will benefit your entire PKI infrastructure. Organizations that treat this as a holistic modernization effort rather than just a compliance checkbox will realize broader benefits. 

The transition to 47-day certificates is inevitable. The organizations that start preparing now will experience it as a managed evolution. Those that wait will face a crisis.