Certificate Management Best Practices: 7 Steps for 2026

Quick answer: Certificate management best practices for 2026 combine continuous discovery, centralized governance, and automated renewal to keep public TLS certificates valid under the CA/Browser Forum’s shrinking 200-day, 100-day, and 47-day limits. The seven steps below cover discovery, policy, automation, domain revalidation, monitoring, quantum readiness, and DevOps integration.

Certificate management is the practice of discovering, issuing, renewing, monitoring, and revoking the digital certificates that secure an organization’s systems and communications. It has moved from a routine administrative task to a core cybersecurity function. As organizations expand cloud footprints, adopt DevOps practices, and connect more services, the number of certificates deployed across the enterprise keeps growing, and shrinking validity periods are forcing teams to rethink how digital trust gets managed day to day.

The biggest driver of that change is the CA/Browser Forum‘s decision to shorten the maximum validity period for publicly trusted TLS certificates. Since March 15, 2026, these certificates have been issued for a maximum of 200 days, down from 398 days. The ceiling drops again to 100 days on March 15, 2027, and to just 47 days on March 15, 2029. Shorter lifetimes reduce exposure to compromised keys and outdated cryptography, but they also multiply how often every certificate needs to be touched.

The operational cost of getting this wrong is already visible. In DigiCert’s July 2025 Trust Pulse Survey of enterprise certificate practices, 45 percent of organizations reported service downtime tied to certificate-related incidents in the prior year, and 37.5 percent traced an outage specifically to an expired certificate. Among those affected, 31 percent reported losses of $50,000 to $250,000 and 18.5 percent lost more than $250,000. Organizations that still rely on spreadsheets, manual renewal reminders, and fragmented inventories will struggle to keep pace as renewal cycles compress further.

This article walks through seven certificate management best practices that help organizations adapt to shorter lifetimes while improving visibility, compliance, and security, then closes with a decision checklist and a team-by-team action matrix so PKI, security, platform, and compliance owners know exactly what to do next.

Key Takeaways

• Three pillars, not one tool: continuous discovery, centralized governance, and automated renewal together close the gaps that manual processes leave open.
• The clock is already running: public TLS validity dropped to 200 days on March 15, 2026, falls to 100 days in March 2027, and reaches 47 days in March 2029, per CA/Browser Forum Ballot SC-081v3.
• Manual renewal is a measured risk, not a hypothetical one: 45% of organizations reported certificate-related downtime in the past year, and 37.5% linked an outage directly to an expired certificate (DigiCert, July 2025).
• Renewal and domain revalidation are separate clocks: by 2029, certificates must be replaced roughly every 47 days while domain control must be reproven roughly every 10 days, so automating one without the other still leaves a gap.
• Private PKI is out of scope for CA/Browser Forum rules: internal certificates for VPNs, devices, and internal services can keep longer lifetimes, though shorter internal lifetimes remain good practice.
• Post-quantum planning should start now: NIST’s draft IR 8547 timeline points to deprecating RSA and ECDSA after 2030 and disallowing them after 2035, and a cryptographic inventory is the prerequisite for that migration.
• Ownership needs to be explicit: the decision checklist and action matrix later in this article assign specific responsibilities to PKI, security, platform, and compliance teams.

How Short Will TLS Certificates Get, and When

The schedule was set by Ballot SC-081v3, which the CA/Browser Forum approved on April 11, 2025, and which Sectigo (the ballot’s sponsor) confirmed publicly on April 14, 2025. It defines a phased reduction in both the maximum validity of publicly trusted TLS certificates and the period for which domain control validation (DCV) data can be reused. The first phase is already in effect: since March 15, 2026, no publicly trusted certificate authority issues a TLS certificate valid for more than 200 days. Certificates issued before that date under the 398-day maximum remain valid for their original term; the 200-day ceiling applies only to certificates issued on or after March 15, 2026.

Effective date	Maximum TLS certificate validity	Maximum DCV reuse period
Until March 14, 2026	398 days	398 days
From March 15, 2026	200 days	200 days
From March 15, 2027	100 days	100 days
From March 15, 2029	47 days	10 days

Two details matter most for planning. First, certificate validity and DCV reuse run on separate timelines. By 2029, a certificate will need to be replaced approximately every 47 days, while domain ownership must be revalidated roughly every ten days, so automating renewal alone will not be enough if domain validation still depends on a person. Second, some certificate authorities issue slightly below each ceiling to stay clear of edge cases at the boundary, so build renewal cadences with a comfortable buffer instead of aiming for the limit.

One point gets misread often. The schedule applies only to certificates that authenticate servers reachable on the public internet. Certificates issued from an organization’s own private PKI, used for internal services, device authentication, VPN access, and similar cases, are not governed by these CA/Browser Forum rules. Internal certificates can keep longer lifetimes where that makes sense, although shorter private lifetimes are still a sound security practice. Understanding this boundary helps teams scope the work correctly instead of either over-engineering internal PKI or overlooking parts of the public-facing estate.

Seven Certificate Management Best Practices

1. Establish Continuous Certificate Discovery Across All Environments

Effective certificate management starts with visibility. An organization cannot secure or renew a certificate it does not know exists, and inventories are often incomplete because modern infrastructure is dynamic: certificates get created, deployed, replaced, and retired across cloud platforms, containers, APIs, development environments, and third-party services on their own schedules.

Many teams still rely on periodic audits or a manually maintained spreadsheet. Those methods held up when certificate estates were small and changed slowly. In cloud-native environments, where resources provision automatically and short-lived workloads can exist for minutes, a spreadsheet is out of date the moment it is saved.

Continuous certificate discovery gives an organization a live inventory of every certificate across its environment. Beyond simply locating certificates, discovery should capture expiration dates, issuing authorities, deployment locations, certificate types, ownership, and cryptographic details such as key size and signature algorithm. That metadata is what lets security teams identify risk, assign accountability, and prepare renewals well ahead of expiry, rather than reacting once something has already broken.

As validity periods shrink, an accurate, continuously updated inventory is the difference between a planned renewal and an unplanned outage.

2. Implement Unified Governance Across the Certificate Lifecycle

Visibility alone does not guarantee control. Organizations also need governance policies that define how certificates are requested, approved, issued, renewed, and revoked.

Without centralized governance, certificate sprawl is almost inevitable. Different teams acquire and manage certificates on their own, processes drift apart, and shadow PKI certificates emerge outside the view of security. Over time, ownership becomes unclear and policy enforcement fragments across the organization.

A mature governance framework sets consistent standards across every certificate operation: who can request certificates, which approval workflows apply, how requests get validated, and which cryptographic requirements must be met before deployment. Governance should also fold in role-based access controls tied to enterprise identity systems, so only authorized personnel can perform certificate-related actions in the first place.

A comprehensive audit trail matters just as much. Every issuance, renewal, modification, and revocation should be logged automatically to support compliance reviews and security investigations. Centralized governance reduces operational risk and keeps certificate practices aligned with security policy and regulatory obligations.

Encryption Consulting’s CertSecure Manager is built around the same three pillars this article describes. It performs network, cloud, and endpoint discovery to maintain a live inventory, enforces request and approval policy with role-based access and audit logging, and automates issuance, renewal, and provisioning across multiple certificate authorities using protocols such as ACME.

3. Automate Certificate Renewal and Lifecycle Operations

Shorter validity periods have changed the economics of certificate management. A task that used to happen once a year will soon recur several times a year for every single certificate.

For organizations managing hundreds or thousands of certificates, manual renewal simply does not scale. Even capable teams struggle to track expirations, coordinate renewals, secure approvals, and deploy updated certificates on time. A single web certificate that an administrator renews by hand is a minor task at an annual cadence; at a six-week cadence, that same task becomes a recurring source of error across the whole estate.

Certificate automation is now a requirement rather than a convenience. Lifecycle management platforms integrate directly with certificate authorities and support protocols such as ACME, letting certificates be requested, renewed, deployed, and rotated without manual intervention. Policy-driven workflows replace reminder emails and manual tickets entirely.

The benefits go beyond saved time. Automation ensures certificates get replaced consistently and on schedule, reduces the chance of outages, and lets certificate operations scale without a proportional increase in headcount. As lifetimes fall toward 47 days, automation becomes the defining trait of a workable program, since manual renewal every few weeks is not sustainable at enterprise scale.

4. Solve the Domain Revalidation Problem, Not Just Renewal

Renewal automation covers only half of what 47-day TLS certificates will demand. The shrinking DCV reuse period means domain ownership has to be proven far more often, reaching roughly every ten days by 2029.

This is where wildcard and multi-domain certificates create friction. Automated issuance with ACME validates control per domain, and wildcard certificates generally require DNS-based validation with programmatic access to the DNS provider. A multi-domain certificate also concentrates risk, since one validation or revocation event can affect every name on the certificate. Teams that lean heavily on wildcards to reduce certificate counts may find that choice works against them as validation frequency rises.

The practical fix is to make domain validation itself automated, typically through DNS integration or an ACME workflow that revalidates without a human in the loop. Reserve wildcards for cases where they genuinely help, such as edge proxies, and prefer dedicated certificates where per-domain automation is cleaner to run.

Building these workflows now, while the cadence is still 200 days, avoids a scramble when the window narrows further.

5. Strengthen Monitoring and Risk-Based Prioritization

Strong discovery and automation still need continuous monitoring on top. Teams need real-time visibility into certificate health and risk exposure so problems get caught before they reach production.

Monitoring should surface expiration status, deployment health, cryptographic strength, validation status, and ownership. Together, these signals let issues get addressed before they affect critical services rather than after.

As estates grow, many organizations move to a risk-based approach instead of treating every certificate the same. Remediation gets prioritized by business impact, internet exposure, application criticality, and compliance relevance. A certificate protecting a customer-facing payment service warrants closer attention than one on an internal development environment.

Monitoring strategy should reflect shorter lifetimes too. Thresholds calibrated for annual renewals will not leave enough response time once certificates expire every few months, so alerting needs to trigger earlier and route to a clearly accountable owner.

6. Begin Preparing for Post-Quantum Cryptography

Alongside shorter lifetimes, organizations need to prepare for a transformation that will reshape PKI: the move to post-quantum cryptography.

Advances in quantum computing threaten the public-key algorithms that underpin today’s PKI and digital certificates, including RSA and ECC. Large-scale quantum attacks are not yet practical, but the planning horizon is already taking shape. NIST’s draft transition roadmap, NIST IR 8547, still an Initial Public Draft as of its November 2024 release, proposes that quantum-vulnerable algorithms such as RSA and ECDSA be deprecated after 2030 and disallowed after 2035.

Those dates bind the federal systems within IR 8547’s scope, but the report has become the reference point industry uses to plan its own PQC migration. As defined in NIST SP 800-131A, deprecated means an algorithm may still be used, but its use carries some security risk that the data owner must assess and accept, while disallowed means it may no longer be used for the stated purpose at all.

Harvest-now-decrypt-later collection, where encrypted data is captured today for decryption once quantum hardware matures, makes this timeline relevant for long-lived data now, not later.

Preparation starts with understanding cryptographic dependencies. Organizations should inventory the algorithms in use, identify business-critical systems that rely on them, and assess whether their certificate authorities, applications, and tools are ready to support the quantum-resistant standards NIST finalized on August 13, 2024:

• ML-KEM for key encapsulation, standardized from the CRYSTALS-Kyber submission (FIPS 203).
• ML-DSA for digital signatures, standardized from the CRYSTALS-Dilithium submission (FIPS 204).
• SLH-DSA, a stateless hash-based signature option standardized from the SPHINCS+ submission (FIPS 205).

These are final standards, unlike the IR 8547 transition timeline, which is still in draft. A cryptographic inventory is a prerequisite for all of this, since an algorithm nobody can see is an algorithm nobody can migrate. Building that inventory is what Encryption Consulting calls a cryptographic bill of materials (CBOM), and the discipline of updating it as systems change is a form of crypto agility that pays off well beyond the initial PQC transition.

The transition itself is expected to happen gradually through hybrid deployments that combine classical and quantum-resistant algorithms, which makes algorithm agility and large-scale testing essential. Organizations in regulated or national security contexts should also track NSA’s CNSA 2.0 guidance, which sets earlier adoption expectations than the civilian IR 8547 timeline and specifies parameter sets such as ML-KEM-1024 and ML-DSA-87.

Under CNSA 2.0, new national security systems must support quantum-resistant algorithms starting January 2027, with category-specific exclusive-use deadlines spanning 2030 to 2033 and full migration expected by 2035. Teams that want a structured starting point can review Encryption Consulting’s PQC readiness guidance and the CBOM inventory-to-intelligence approach for turning a raw cryptographic inventory into a prioritized migration plan. The same disciplines that make short-lived certificates manageable, a complete inventory, automated deployment, and policy enforcement, are exactly the disciplines a PQC migration requires.

7. Integrate Certificate Management with Cloud and DevOps Ecosystems

Modern infrastructure is built for speed. Applications ship through CI/CD pipelines, containers get created and destroyed dynamically, and cloud resources scale on demand. Certificate management needs to operate inside these workflows rather than sit beside them as a separate process.

Integration with cloud and DevOps platforms lets certificates become part of automated provisioning. Whether resources deploy through Kubernetes, Terraform, cloud-native services, or other infrastructure-as-code frameworks, certificate issuance and renewal should happen automatically as services come online. Native integration with cloud key stores and tools such as cert-manager keeps this consistent across environments instead of ad hoc per team.

Without that integration, blind spots form where certificates exist outside centralized management. Those unmanaged certificates raise security risk, complicate compliance reporting, and increase the odds of an unexpected outage.

Embedding certificate management into cloud and DevOps workflows improves visibility, increases operational efficiency, and keeps certificates aligned with infrastructure that never stops changing.

Common Mistakes That Lead to Certificate Outages

Despite greater awareness, outages caused by expired or mismanaged certificates remain common across industries. DigiCert’s July 2025 survey found that manual renewal reminders, incomplete inventories, and unclear ownership are still the norm at nearly half the organizations it surveyed.

Other recurring mistakes include failing to plan for shorter validity periods, overlooking certificates in cloud environments, using self-signed certificates in production, and delaying renewals until certificates are close to expiry. These issues often look minor until they cause a service disruption, a customer-facing outage, or a compliance finding.

The consequences are well documented. In July 2024, the Bank of England reported a 91-minute disruption to CHAPS settlement caused by an expired certificate within its infrastructure, affecting a system that settles high-value sterling payments. The risk is not limited to availability.

In the 2017 Equifax breach, a network monitoring device had been inactive for around 19 months because of an expired certificate, which let intruders operate undetected for 76 days and exfiltrate data on roughly 147 million people, an incident that later led to a settlement of up to 700 million dollars. Preventing outcomes like these requires the same foundation of visibility, governance, and automation described throughout this article.

Security Best Practices for Long-Term Success

Strong certificate management extends beyond renewal. Organizations should protect private keys using Hardware Security Modules, enforce least-privilege access controls, conduct regular audits, and continuously scan for unmanaged certificates across the environment. For high-assurance use cases, look for HSMs validated to FIPS 140-3, with the validation level matched to the sensitivity of the keys being protected.

Clear policies for development and testing environments help prevent production key reuse and remove unnecessary risk. Where public certificates have been repurposed for internal authentication, replacing them with certificates from a managed private PKI is usually the better long-term choice.

These practices reduce the likelihood of certificate compromise while supporting compliance and operational resilience at the same time.

Certificate Management Decision and Ownership Matrix

The seven practices above translate differently depending on what kind of certificate is involved and which team is closest to it. The two tables below give a quick reference: one for deciding how to treat a given class of certificate, and one for assigning ownership across PKI, security, platform, and compliance teams.

Decision Checklist by Use Case

Use case	Recommendation	Operational owner	Expected outcome
Public-facing TLS certificates	Automate issuance and renewal via ACME against the 200/100/47-day schedule	Platform / DevOps	No manual renewal touchpoints; no expiry-driven outages
Wildcard or multi-domain certificates	Automate DNS-based DCV; limit wildcard use to edge proxies	PKI team	Domain revalidation keeps pace with shrinking DCV reuse windows
Internal or private PKI certificates	Set internal lifetimes deliberately; do not assume CA/Browser Forum limits apply	PKI team	Right-sized validity for internal risk, without unnecessary churn
Legacy or agentless systems	Deploy lightweight agents or proxy-based automation instead of manual renewal	Platform / Security	Legacy systems stay on the same automated cadence as modern ones
Cryptographic algorithm inventory	Build and maintain a CBOM covering all certificate-dependent systems	Security / Compliance	Migration-ready visibility ahead of the post-quantum transition

Owner and Action Matrix by Team

Team	Primary responsibility	What to do next
PKI team	Certificate issuance policy, discovery accuracy, wildcard and domain strategy	Confirm every public certificate authority path supports ACME; document which domains still rely on wildcard certificates and plan their reduction
Security team	Risk prioritization, key protection, cryptographic inventory	Stand up or review the CBOM; flag business-critical systems still on RSA or ECC for the PQC roadmap
Platform / DevOps team	CI/CD and infrastructure integration, automated deployment	Wire certificate issuance into Kubernetes, Terraform, or existing infrastructure-as-code pipelines rather than handling it as a side task
Compliance team	Audit trail, regulatory alignment, exception tracking	Confirm audit logging captures every issuance, renewal, and revocation, and update internal policy documents to reflect the 2026 to 2029 validity schedule

How Encryption Consulting Can Help

The seven practices in this article map to a single operating model built on discovery, governance, and automation. Encryption Consulting delivers that model through a combination of platform capability and advisory expertise, so organizations can move from fragmented, manual processes to a managed program before shorter validity periods take full effect.

CertSecure Manager is the certificate lifecycle management platform that performs continuous discovery across network endpoints, cloud platforms, and local certificate stores to maintain a live inventory, capturing expiration dates, issuing authorities, key sizes, and signature algorithms for every certificate it finds. This closes the visibility gap that makes both renewal automation and post-quantum planning impossible without it.

On the governance side, CertSecure Manager enforces policy at the point of request. It defines which authorities and certificate profiles are permitted for each use case, applies role-based access controls tied to enterprise identity, routes requests through approval workflows, and records every issuance, renewal, and revocation in a tamper-evident audit trail. Non-compliant requests get blocked rather than corrected after the fact, which keeps shadow PKI from forming in the first place.

For automation, the platform integrates directly with multiple certificate authorities and supports protocols such as ACME, so issuance, renewal, provisioning, and revocation can run without manual steps. It connects to cloud key stores and DevOps tooling, letting certificates deploy as part of normal provisioning rather than as a separate task. Lightweight agents extend the same automation to legacy systems that do not speak modern protocols, which is what makes a 47-day renewal cadence operationally realistic rather than aspirational.

Private PKI runs on your own rules rather than the CA/Browser Forum schedule, but it still needs structure. EC’s PKI-as-a-Service provides a managed private trust hierarchy for internal services, device and user authentication, and workload identity, while HSM-as-a-Service protects the underlying private keys in dedicated hardware. Together, they bring the same discipline to internal certificates that this article recommends for public ones.

For the longer transition ahead, CBOM Secure builds a cryptographic bill of materials that records which algorithms are in use across the estate, the algorithm-level visibility any post-quantum migration depends on. From there, EC’s PQC Advisory Services and the PQC Center of Excellence translate that inventory into a phased migration plan, including where hybrid classical and quantum-resistant deployments make sense during the transition.

For organizations that are unsure where they stand today, EC’s Encryption Advisory Services can assess the certificate estate, quantify the operational impact of shorter lifetimes, and define a roadmap toward discovery, governance, and automation, so the program scales with renewal cycles instead of reacting to each new deadline under pressure.

Conclusion

The certificate management landscape is changing quickly. With publicly trusted TLS validity already capped at 200 days and continuing to fall toward 47 days by 2029, manual processes and fragmented visibility no longer keep an organization safe, and the data backs that up: nearly half of enterprises surveyed by DigiCert in mid-2025 had already experienced certificate-related downtime.

Success now depends on a strategy built on continuous discovery, strong governance, and comprehensive automation, with domain validation automated alongside renewal rather than left as an afterthought. Organizations that put these foundations in place will be ready for more frequent renewals, will avoid costly outages, and will be positioned for the longer transition to post-quantum cryptography.

The shift to short-lived certificates is already underway. A practical first step is to build a complete, continuously updated inventory of every certificate you hold, then use that visibility to prioritize automation where renewal frequency and business impact are highest. To assess where your certificate program stands today and what shorter lifetimes will require, reach out to the team at Encryption Consulting.

Frequently Asked Questions

What is the main takeaway from Certificate Management Best Practices: 7 Steps for 2026?

Certificate management now rests on three pillars working together: continuous discovery to know what certificates exist, centralized governance to control how they are issued and approved, and automation to handle renewal at a pace manual processes cannot match. As public TLS validity falls from 200 days toward 47 days by 2029, treating any one pillar as optional puts the other two at risk.

Why does this matter for enterprise certificate lifecycle management?

Shorter validity periods multiply how often every certificate in an estate needs to be renewed and revalidated. An organization managing thousands of certificates on a 47-day cycle instead of an annual one is running a fundamentally different operation, and programs built for the old cadence will fall behind without a change in tooling and process.

What teams are responsible for acting on this guidance?

PKI, security, platform or DevOps, and compliance teams each own a piece of this. PKI teams handle issuance policy and domain strategy, security teams own risk prioritization and the cryptographic inventory, platform teams integrate certificates into CI/CD and infrastructure pipelines, and compliance teams maintain the audit trail and regulatory alignment. The ownership matrix earlier in this article breaks down specific next steps for each group.

What risks increase if this topic is handled manually?

Manual renewal raises the odds of missed expirations, inconsistent approvals, and shadow PKI certificates that sit outside centralized visibility. DigiCert’s July 2025 survey found that 45% of organizations experienced certificate-related downtime in the prior year, with 37.5% of incidents tied specifically to an expired certificate, and roughly a third of affected organizations reported financial losses of $50,000 or more.

How does automation reduce certificate outage risk?

Automation replaces manual tracking and reminder-driven renewal with policy-driven workflows that request, renew, deploy, and rotate certificates on schedule using protocols such as ACME. That consistency removes the human error that causes most expiry-related outages, and it lets certificate operations scale without adding headcount as validity periods shrink.

What metrics should teams track after implementation?

Track certificate inventory completeness (percentage of certificates under active management), time-to-renewal versus days remaining before expiry, the number of certificates renewed manually versus automatically, domain control validation success rate, and audit trail completeness for every issuance, renewal, and revocation event.

How does this connect to 47-day TLS certificate readiness?

The 200-day limit in effect since March 2026 is the first of three steps toward the 47-day maximum arriving in March 2029, with an interim 100-day step in March 2027. Every practice in this article, from discovery through domain revalidation automation, is groundwork for operating comfortably at that final cadence rather than scrambling to meet it in 2029.

How should this be handled in multi-cloud or hybrid PKI environments?

Multi-cloud and hybrid environments need discovery and automation that work identically across every platform rather than a separate process per cloud provider. That means integrating certificate issuance with each provider’s native tooling and with orchestration layers such as Kubernetes and Terraform, while keeping one centralized inventory and one governance policy so certificates issued in different clouds do not drift into inconsistent standards.