PKI and Certificate Lifecycle Maturity Model

Certificates are the most widely deployed machine identity in most organisations, yet few can say how many they have, who owns them, or whether they could replace all of them in a week. This maturity model gives a five-level scale, from Ad hoc to Optimised, across six capability areas: inventory and discovery, ownership and policy, issuance and automation, short-lived certificates and renewal, key protection and revocation, and crypto agility. Each level is defined by evidence an assessor can check. It is written for PKI owners, platform and security architects and CISOs who need a baseline, a defensible target and a roadmap, particularly now that the maximum lifetime of public TLS certificates is falling to 47 days. For the discipline itself see the Machine Identity, PKI and Certificate Lifecycle Guide; this page covers staged maturity, not the basics.

Key takeaways

The calendar is setting the target: under the CA/Browser Forum Baseline Requirements, publicly trusted TLS certificates issued from 15 March 2026 may last at most 200 days, from 15 March 2027 at most 100 days and from 15 March 2029 at most 47 days, so manual renewal stops being viable for public certificates during this period.
Score the weakest area, not the average: perfect automation for web servers does not help if an unknown internal CA signs certificates for production databases with no owner, so the overall rating is the lowest area score.
Evidence decides the level: a discovery report, a renewal success rate or a timed mass-replacement exercise counts; a policy document or a tool purchase on its own does not.
Level 3 is the minimum for 2027: Defined means a complete inventory with owners and automated renewal for public certificates, which is what 100-day and then 47-day lifetimes require.
Agility is the top of the scale, not an extra: the ability to replace a CA, an algorithm or every certificate quickly is what protects against CA distrust events, key compromise and the move to post-quantum algorithms.

The five levels

Level	Name	Description
1	Ad hoc	Certificates are requested by whoever needs one, from whichever CA is convenient, and tracked in spreadsheets or calendars if at all. Expiry is discovered by outage. Private keys sit in files on servers and in repositories. Nobody can produce a complete list.
2	Developing	A central team runs some discovery and an approved CA list exists. Some renewals are automated, mainly public web certificates. Ownership is recorded for part of the estate. Internal CAs and non-TLS certificates (code signing, device, client authentication) are largely outside the programme.
3	Defined	A certificate policy with named owners applies across public and private PKI. Continuous discovery feeds a single inventory. All public TLS certificates renew automatically, usually via ACME. Keys for CAs and signing certificates are in hardware. Revocation and replacement procedures are documented and tested.
4	Managed	The programme is measured: inventory coverage, renewal success, time to replace and policy exceptions are reported against targets. Internal certificates are short-lived where platforms allow. Renewal windows follow CA signals such as ACME Renewal Information. Mass replacement has been exercised against a deadline.
5	Optimised	Certificates are issued on demand for workloads and expire in hours or days. A CA, algorithm or key size can be changed by configuration. Cryptographic inventory covers algorithms and libraries, not only certificates, and post-quantum migration is under way. Lessons from industry incidents are turned into tested changes within a set time.

Capability areas

Assess each of the six areas separately. The table shows what each looks like at Levels 1, 3 and 5; Levels 2 and 4 sit between them.

Area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Inventory and discovery	No list; certificates found when they expire	Continuous discovery across networks, cloud accounts, load balancers, Kubernetes and Certificate Transparency logs into one inventory, including private CAs	Inventory includes algorithms, key sizes, libraries and dependencies (a cryptographic bill of materials) and drives automated decisions
Ownership and policy	No owner field; anyone can request from any CA	Certificate policy approved; every certificate has an owning team and application; approved CA list enforced	Ownership derived automatically from workload identity and service catalogue; policy enforced as code at issuance
Issuance and automation	Manual CSR, email to CA, manual install	ACME or platform-native automation for all public TLS; enrolment protocols for devices; renewal tested	Issuance is a self-service API for every certificate type; no human handles private keys
Short-lived certificates and renewal	Longest available lifetime chosen to avoid work	Public certificates renewed at about two-thirds of lifetime; internal lifetimes set by policy and shrinking	Workload certificates live hours to days; renewal timing follows CA signals; outages from expiry do not occur
Key protection and revocation	Keys in files, copied between servers and into source control	CA and code signing keys in HSMs or managed key services; revocation procedure documented and tested; CT monitoring for unexpected issuance	Non-exportable keys for workloads; revocation replaced by short lifetimes where possible; compromise drills run
Crypto agility	No idea which systems depend on which CA or algorithm	Dependencies on each CA known; a documented plan to move off any CA; algorithm inventory started	CA or algorithm swap is a configuration change; replacement of all certificates from one CA proven within days; post-quantum pilots running

Evidence by level

Evidence an assessor can check	Level 2	Level 3	Level 4	Level 5
Inventory coverage versus discovery scans and CT logs	Partial, public only	All public and private CAs	Coverage measured and above target	Includes algorithms and libraries
Certificates with a named owner	Some	All in inventory	Owner verified on each renewal	Derived automatically
Public TLS renewed automatically	Some web servers	All	All, with success rate reported	All, with CA-signalled windows
Expiry-caused incidents in the last 12 months	Several	Rare, with root cause recorded	None in critical services	None
Signing and CA keys in hardware	Root CA only	All CA and code signing keys	Plus key ceremonies audited	Plus non-exportable workload keys
Mass replacement exercise	Never	Procedure documented	Exercised against a deadline	Proven within days for a whole CA

Framework mapping

Capability area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	MITRE ATT&CK threat addressed
Inventory and discovery	ID.AM-02, ID.AM-08	CM-8 System Component Inventory	T1588.004 Digital Certificates (attacker-obtained certificates found via CT monitoring)
Ownership and policy	PR.AA-01	SC-17 Public Key Infrastructure Certificates	Unowned certificates used for impersonation
Issuance and automation	PR.AA-01, PR.DS-02	SC-17, IA-5(2) Public Key-based Authentication	Manual handling of private keys
Key protection and revocation	PR.DS-02	SC-12 Cryptographic Key Establishment and Management	T1649 Steal or Forge Authentication Certificates; T1553.002 Code Signing
Crypto agility	ID.AM-08	SC-12, SC-17	Forced replacement after CA distrust or algorithm weakness

In ISO/IEC 27001:2022 the programme sits mainly under Annex A 8.24 Use of cryptography, with inventory supported by 5.9 Inventory of information and other associated assets. NIST SP 1800-16 describes a formal TLS server certificate management programme for large and medium enterprises and is a useful reference for Levels 3 and 4.

How to run the assessment

Set the scope: include public TLS, every private CA (including those built into cloud services, service meshes and Active Directory Certificate Services), code signing, client and device certificates, and SSH certificates if used.
Gather evidence first: run discovery and compare it with Certificate Transparency results for your domains before interviewing anyone. The gap between what teams believe exists and what the scan finds is itself a finding.
Score each area against the evidence table: award a level only when all its evidence is present; partial evidence stays at the level below.
Take the lowest area as the overall level: report the area scores alongside so strengths are visible.
Set a dated target: for most organisations, Level 3 across all areas before the 100-day limit applies on 15 March 2027, and Level 4 for public certificates before the 47-day limit on 15 March 2029.
Repeat annually: and after any certificate-related incident or CA distrust event.

Self-assessment questions

Inventory and discovery

Can we produce, today, a list of every certificate due to expire in the next 30 days, including those from internal CAs?
Do we monitor Certificate Transparency logs for certificates issued for our domains that we did not request?
Do we know every private CA running in our environment, including those inside cloud services and appliances?

Ownership and policy

Does every certificate in the inventory have a named owning team and application?
Is there an approved CA list, and is issuance from other CAs blocked or detected?
Does the certificate policy set maximum lifetimes, key types and key storage per certificate type?

Issuance and automation

What percentage of public TLS certificates renew without a human touching them?
Can a developer get a correctly configured internal certificate through an API in minutes?
Are private keys ever emailed, copied by hand or committed to repositories?

Short-lived certificates and renewal

Will our renewal process still work when public certificates last 100 days, then 47 days?
Do renewal jobs alert on failure early enough to fix them before expiry?
Do our ACME clients support ACME Renewal Information so the CA can bring renewals forward?

Key protection and revocation

Are all CA and code signing private keys held in HSMs or managed key services?
When did we last test revoking and replacing a compromised certificate end to end?
Would we detect a signing key that should have been retired but is still trusted?

Crypto agility

If our main public CA were distrusted by browsers, how long would it take to replace every certificate it issued?
Do we know which systems and libraries depend on RSA and elliptic curve algorithms that post-quantum migration will replace?
Can we change CA or algorithm through configuration, or does it need code changes in each application?

Moving up: roadmap

Level 1 to 2: run discovery across networks and cloud accounts, start CT monitoring, publish an approved CA list, and automate renewal for the highest-traffic public sites. See the Certificate Transparency Monitoring Guide for Web Teams.
Level 2 to 3: adopt a certificate policy with owners, bring private CAs into the inventory, automate every public TLS certificate with ACME or platform-native tooling, move CA and signing keys into hardware, and document revocation. See the Certificate Management Policy Template and the ACME and Automated Certificate Management Guide.
Level 3 to 4: report renewal success, coverage and time-to-replace as metrics; shorten internal lifetimes; adopt ACME Renewal Information (RFC 9773), which lets a CA suggest a renewal window and helps it handle mass revocation events; run a timed mass-replacement exercise. See the CA Compromise and Mass Certificate Replacement Playbook.
Level 4 to 5: issue workload certificates on demand with lifetimes of hours or days, extend inventory to algorithms and libraries, and start post-quantum pilots. See the Cryptographic Inventory and CBOM Guide and the Post-Quantum Readiness Maturity Model.

Public CAs are already moving faster than the rules require. Let's Encrypt has announced a move from 90-day to 45-day certificates by February 2028, with a 6-day short-lived profile available by opt-in, and advises renewing at about two-thirds of a certificate's lifetime where a client does not support ACME Renewal Information.

Measuring progress

Inventory coverage: certificates in inventory as a percentage of those found by discovery and CT monitoring.
Ownership: percentage of certificates with a verified owner.
Automation: percentage of public and of internal certificates renewed without human action.
Expiry incidents: number of outages or warnings caused by expired certificates per quarter (target zero for critical services).
Time to replace: measured time to replace all certificates from one CA, from the last exercise.
Policy exceptions: number of certificates outside policy (lifetime, key type, CA) and their age.

Common failure patterns

Automating the visible estate only: public web certificates are automated while internal CAs, appliances and client certificates continue to expire unnoticed.
Inventory without owners: a tool lists thousands of certificates but nobody can say who to call when one expires or must be revoked.
Longest lifetime by default: teams choose maximum validity to avoid renewal work, so the renewal process is exercised so rarely that it fails when needed.
Keys that outlive their purpose: signing keys stay trusted long after they should be retired. In the Storm-0558 incident a 2016 consumer signing key that should have been retired in 2021 was used to forge tokens, and the US Cyber Safety Review Board found no system to alert staff to old, active signing keys. See the Microsoft Storm-0558 key breach analysis.
No plan for losing a CA: mass replacement after a CA distrust event or a revocation deadline is improvised, with a five-day revocation window under the Baseline Requirements for many reasons and 24 hours for some. See CA Distrust Events.

Lessons from incidents

The Storm-0558 case shows why key protection and lifecycle belong in the same model as certificate renewal: the failure was not a missing certificate but a key that nobody retired, with manual rotation that had stopped after an outage. The lesson for each level is the same: automate rotation so that an outage does not become a reason to stop rotating, and make the inventory raise alerts on credentials past their intended life. Expiry outages teach the mirror lesson, covered in the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Practitioner checklist

Run discovery across networks, cloud accounts, load balancers and clusters, and reconcile it with CT log results.
Bring every private CA, including cloud and directory-integrated CAs, into one inventory.
Assign an owning team and application to every certificate and verify it on renewal.
Automate renewal for all public TLS certificates before the 100-day limit on 15 March 2027.
Hold CA and code signing keys in HSMs or managed key services and audit key ceremonies.
Monitor CT logs for unexpected certificates issued for your domains.
Exercise replacing all certificates from one CA against a deadline, and record the time taken.
Start an algorithm and library inventory as the foundation for post-quantum migration.

PKI and Certificate Lifecycle Maturity Model: Five Levels, Self-Assessment and Roadmap