Certificate Lifecycle Management Requirements

Certificate lifecycle management requirements in 2026 come down to four capabilities. A CLM platform has to keep a live inventory of every certificate and its owner, renew and deploy certificates without manual steps, enforce policy at issuance, and change CAs or algorithms in bulk. Each requirement traces to a dated rule, starting with the 100-day TLS limit on March 15, 2027, and each one can be tested in a proof of concept before you buy.

Requirements set today need to hold through March 2029, when public TLS certificates max out at 47 days, and into the post-quantum deadlines that follow. They also need to satisfy PCI DSS and DORA auditors, who expect a current inventory of every certificate in scope.

Key takeaways

• A CLM requirement belongs on the list when it traces to a dated rule and passes a test in your own environment. In 2026 that means full discovery, renewal through deployment, policy at issuance, and bulk CA or algorithm changes.
• Maximum public TLS certificate validity is 200 days today, drops to 100 days on March 15, 2027, and reaches 47 days on March 15, 2029, when domain control validation (DCV) reuse falls to 10 days.
• March 2027 is the harder deadline in practice. Renewal volume doubles that day, and under Chrome Root Program Policy 1.8, public certificates issued from then on can carry only server authentication.
• Automate in deadline order, with internet-facing public TLS and DCV first, private PKI and Kubernetes certificates next, and SSH and code-signing keys last.

What sets CLM requirements in 2026?

CLM requirements are increasingly set outside the organization. Browser root programs, standards bodies, and regulators publish rules with fixed dates. Together, they require a current certificate inventory that drives automated renewal and produces audit evidence.

CA/Browser Forum Ballot SC-081v3, adopted in April 2025, cuts maximum public TLS validity from 398 days to 47 by March 2029. It cuts domain validation reuse alongside it, from 398 days to 10. At 47 days, every public certificate turns over roughly eight times a year.

Chrome Root Program Policy 1.8, updated February 5, 2026, finishes the move to TLS hierarchies dedicated to server authentication. Public TLS certificates issued on or after March 15, 2027 can assert only server authentication, so client authentication and mTLS certificates need a separate issuer, typically private PKI. An inventory that records extended key usage shows which certificates have to move.

PCI DSS v4.0.1 Requirement 4.2.1.1 has required an inventory of trusted keys and certificates protecting cardholder data in transit since March 31, 2025. For EU financial entities, the DORA technical standards in Commission Delegated Regulation (EU) 2024/1774 require a current register of certificates and certificate-storing devices, plus renewal before expiry. Both turn the certificate inventory into a control that assessors and supervisors can check.

NIST finalized its first PQC standards, FIPS 203, 204, and 205, in August 2024. Its draft guidance, NIST IR 8547, proposes deprecating quantum-vulnerable public-key algorithms after 2030 and disallowing them after 2035. Executive Order 14412, signed June 22, 2026, directs federal agencies to move high-value assets and high-impact systems to post-quantum key establishment by December 31, 2030, and to post-quantum signatures by December 31, 2031. Planning for that window starts with knowing which certificates rely on RSA and ECC today.

Driver	Date	Requirement it creates
DORA RTS (EU) 2024/1774, Art. 7	January 17, 2025	A current certificate register and renewal before expiry
PCI DSS v4.0.1, Req. 4.2.1.1	March 31, 2025	An inventory of trusted keys and certificates for cardholder data in transit
SC-081v3, phase 1	March 15, 2026	Roughly two renewals a year per certificate and 200-day DCV reuse
SC-081v3, phase 2	March 15, 2027	Roughly four renewals a year and 100-day DCV reuse
Chrome Root Program Policy 1.8	March 15, 2027	Server-authentication-only public certificates and a private PKI path for client-auth certificates
SC-081v3, phase 3	March 15, 2029	Roughly eight renewals a year and 10-day DCV reuse
Executive Order 14412	December 31, 2030 and 2031	Post-quantum key establishment, then signatures, on federal high-value and high-impact systems
NIST IR 8547 (draft)	After 2030 and 2035	Algorithm and key-size reporting and bulk re-issuance

Compiled from CA/Browser Forum Ballot SC-081v3, Chrome Root Program Policy 1.8, PCI DSS v4.0.1, Regulation (EU) 2024/1774, Executive Order 14412, and NIST IR 8547 (draft).

What should certificate discovery cover?

Renewal automation, policy enforcement, and algorithm migration can act only on certificates the platform knows about. That’s why discovery coverage sets the coverage of every other control.

NIST’s practice guide for TLS server certificate management, SP 1800-16, reports that TLS server certificates have grown to many thousands in some enterprises. Its recommended practices include a central inventory with an assigned owner for each certificate. A discovery requirement should name the sources it covers:

• Network scans across internal ranges and the external attack surface
• CA account imports from every public and private issuer in use
• Cloud provider certificate services
• Load balancers, ADCs, web servers, and network devices, including where each certificate is bound
• Kubernetes clusters and containers
• Keystores and HSM-backed key containers

Each record needs an owner, issuing CA, key algorithm and size, extended key usage, expiry date, and every endpoint where the certificate is bound. PCI DSS guidance for its inventory requirement names several of these fields, including key strength, key custodian, and expiry. Bindings tell renewal automation where to deploy each replacement.

How to test a discovery claim

Discovery coverage depends on network topology, which makes your own environment the place to test it.

Before the proof of concept, seed a known set of certificates across representative locations, such as a load balancer partition, a cloud account, a Kubernetes namespace, a legacy application server, and a certificate from a CA the vendor has not been told about. Then run the vendor’s discovery scan and score it on coverage, duplicate handling, speed, and record accuracy.

• Find rate against the seeded list, broken out by location
• Deduplication of a single certificate bound to several endpoints
• Time from scan start to a usable inventory
• Accuracy of owner and binding data on each record

Run a second scan a week later, after adding new certificates. A platform built for continuous discovery should pick up the changes on the next scheduled scan, with no manual rerun.

Certificate automation must reach the endpoint

A complete certificate renewal runs as a closed loop that generates the key, requests the certificate, deploys it to every bound endpoint, confirms the new certificate is serving, and rolls back if it is not.

Protocol coverage determines how much of the estate that loop can reach. The ACME protocol, standardized in RFC 8555, suits web servers and platforms that run an ACME client. EST (RFC 7030) and SCEP (RFC 8894) cover devices, network equipment, and mobile endpoints. REST APIs and native integrations extend coverage to load balancers, cloud services, and ITSM workflows.

Expect both agent-based and agentless connection options, since some endpoints accept remote API calls and others need a local client. Write the requirement by endpoint class, then verify each class in the proof of concept.

Certificate renewal volume at 200, 100, and 47 days

Minimum yearly replacements equal the number of certificates multiplied by 365, divided by the maximum validity. Say a team manages 1,000 public TLS certificates, a hypothetical estate. It faces at least 917 renewals a year at 398-day validity, 3,650 at 100 days, and 7,766 at 47 days, or about 21 a day. Renewing ahead of expiry pushes the real count higher, and any step that needs a person, from a change ticket to a manual binding check, becomes a daily backlog at that rate.

Domain control validation moves into the pipeline

Through 2027, domain validation reuse matches certificate validity, so one validation can still cover a renewal. From March 2029, reuse drops to 10 days while validity stays at 47, and a certificate renewed every few weeks needs fresh proof of domain control at nearly every issuance.

Figure 1. Domain validation reuse drops below certificate validity in 2029. Source: CA/Browser Forum Ballot SC-081v3.

DNS integration becomes a requirement. The platform should create and clean up DNS TXT records through the APIs of the DNS providers you run, and log each validation event alongside the issuance it supports.

Certificate policy belongs at issuance

Checking policy at request time stops a noncompliant certificate before it reaches an endpoint. NIST SP 1800-16 recommends defining TLS server certificate policies within the first 30 days of a certificate management program, and the CLM platform turns those policies into checks on every request.

Certificate policy at issuance covers the following controls:

• CA allow lists by environment and certificate type
• Approved key algorithms and minimum key sizes, aligned to the security strength guidance in NIST SP 800-57 Part 1
• Validity limits for private certificates, set by internal policy
• Role-based access control scoped to teams, applications, and certificate groups
• Self-service requests, with approval workflows for exceptions
• Revocation and replacement workflows that cover every endpoint where a certificate is bound
• Audit logs for every request, approval, issuance, and deployment

Enforcing policy at issuance makes self-service safe to offer. Application teams get certificates without waiting in a ticket queue, every request passes the same checks, and the PKI team owns the rules. The resulting log shows who requested each certificate, who approved it, and where it was deployed, which gives PCI DSS assessors and DORA supervisors a trail they can review.

Crypto-agility is an architecture requirement

Crypto-agility lets a team swap a CA, key, or algorithm across the whole certificate estate in one planned change, on its own schedule. A CLM platform supports that with three properties.

• CA independence to ensure issuance, renewal, and inventory work the same way across public and private CAs, and that a change of issuer needs no new workflows.
• Bulk re-issuance of certificates by group, policy, or algorithm in one controlled run.
• Algorithm visibility for every certificate and key, recorded in a form that can feed a cryptographic bill of materials (CBOM).

Bulk re-issuance is where CA independence gets tested. A root program distrust decision can require replacing every certificate from an issuing CA on a fixed timeline, and a post-quantum migration runs on the same capability. The CA/Browser Forum lists faster transitions between cryptographic algorithms as a benefit of Ballot SC-081v3, since certificates that turn over every few weeks can carry a new algorithm into the estate soon after a policy change.

For post-quantum readiness, the requirement is sequencing. Private PKI can adopt ML-DSA certificates on an internal schedule. Public TLS adoption depends on CA/Browser Forum and root program approval. NIST IR 8547’s proposed 2030 and 2035 dates give planners fixed points to work back from, starting with a report of which certificates rely on RSA-2048 or ECC P-256 today.

SSH keys and code-signing keys often rely on the same RSA and ECC algorithms as TLS certificates, and tracking them in separate tools splits the inventory a migration depends on. SSH key management and governance of code-signing keys belong in the same requirement set as certificates.

Which CLM requirements are must-haves?

A requirement is a must-have when one of the deadlines in Table 1 depends on it, and you can test it in your own environment. A should-have widens coverage or saves operator time. Anything else can wait for a later evaluation round.

Table 2. CLM requirements by priority, with a proof-of-concept test for each

Requirement	Priority	How to verify in a POC
Discovery across network, CA, cloud, and Kubernetes sources	Must-have	Seed known certificates in each location and compare the found set with the seed list
Owner and crypto metadata on every record	Must-have	Export the inventory, check owner, key size, EKU, issuing CA, and bindings, then filter for RSA-2048 and ECC P-256
Renewal through deployment and validation	Must-have	Renew a certificate on a staging load balancer and confirm the new serial number is serving
Automated domain control validation	Must-have	Complete a public renewal with no manual DNS change
CA-agnostic issuance	Must-have	Move a certificate group from one CA to another in bulk
Policy enforcement at request time	Must-have	Submit a weak-key or unapproved-CA request and confirm it is blocked and logged
SSH and code-signing keys on the same platform	Must-have	Discover SSH keys on a test host and review the signing log for a test build
Self-service with approvals and RBAC	Should-have	Have an application team request a certificate without a PKI ticket
ITSM and DevOps integrations	Should-have	Raise a certificate request from your ITSM tool or CI/CD pipeline and confirm it completes without a manual handoff

Priorities follow the dated drivers in Table 1. Each test runs in a staging or test environment during a proof of concept.

Where to start automating

Roll out automation across four certificate and key groups, ordered by the deadline each one faces, from internet-facing public TLS in March 2027 to SSH and code-signing keys on the post-quantum timeline. Each stage builds the inventory and policy set the next stage relies on:

Internet-facing public TLS on load balancers and web servers, ahead of the 100-day phase on March 15, 2027.

1. Domain control validation through DNS integration, so the 100-day reuse limit adds no manual DNS work.
2. Private PKI, mTLS, and Kubernetes certificates, including client-auth certificates moving off public hierarchies.
3. SSH keys and code-signing keys, which feed the same algorithm inventory for post-quantum planning.

Questions to ask CLM vendors

A proof of concept also needs answers to operational and commercial questions beyond the table:

• Whether pricing is based on certificate count or issuance volume, since issuance volume rises about 8.5x by 2029.
• What happens when a deployment fails, including rollback and who gets notified.
• How long it takes to connect a new CA, including one added after go-live.
• Which deployment models are available, such as SaaS, private cloud, and on-premises.

How AppViewX meets CLM requirements

AppViewX, named a Leader in the IDC MarketScape for Worldwide CLM Software 2026, runs discovery, automation, policy, and crypto-agility from one control plane, covering the must-haves in the table above.

• Smart Discovery combines authenticated and unauthenticated scans across public and private CAs, multi-cloud environments, Kubernetes, and legacy applications.
• Every scan result feeds one live inventory that records the issuing CA, location, expiry, crypto standard, and chain of trust.
• Closed-Loop Automation carries each renewal through enrollment, provisioning, endpoint binding, and domain control validation, then validates the deployment and rolls back on failure.
• The AppViewX CLM platform enforces enterprise PKI policy and role-based access control, generates audit reports, and works across existing public and private CAs with no CA lock-in.
• CBOM visibility and algorithm reporting support post-quantum planning, and Crypto Resilience Scorecards rank cryptographic risk to show which certificates to remediate first.
• Private PKI, SSH key management, and code signing share the same inventory and policy model, hence, certificates and keys are governed together.
• Deployment options include SaaS, private cloud, hybrid, and on-premises.

Disclaimer

Based on public sources as of October 12, 2026. Standards, policies, and deadlines change often, so confirm current versions with each standards body and regulator. AppViewX publishes this guide, and AppViewX product details come from its own documentation.

Sources

1. CA/Browser Forum, Ballot SC-081v3 (April 11, 2025)
2. Google, Chrome Root Program Policy 1.8 (February 5, 2026)
3. PCI Security Standards Council, PCI DSS v4.0.1 (June 2024)
4. European Commission, Delegated Regulation (EU) 2024/1774 (March 13, 2024)
5. NIST, FIPS 203, 204, and 205 (August 13, 2024)
6. NIST, IR 8547 draft (November 12, 2024)
7. The White House, Executive Order 14412 (June 22, 2026)
8. NIST NCCoE, SP 1800-16 Volume A (June 2020)
9. NIST, SP 800-57 Part 1 Rev. 5 (May 2020)
10. IETF, RFC 8555 (March 2019), RFC 7030 (October 2013), and RFC 8894 (September 2020)
11. AppViewX, Smart Discovery, Closed-Loop Automation, CLM platform, Crypto Resilience Scorecards, and IDC MarketScape pages.