The Certificate Management Maturity Model: Navigating the 90-Day TLS Mandate and Beyond

In recent years, high-profile global outages at companies like Starlink, Spotify, Epic Games, and Microsoft have all shared a remarkably simple, yet devastating root cause: a single expired TLS certificate.

As we move deeper into 2024 and 2025, the landscape of Public Key Infrastructure (PKI) and Certificate Lifecycle Management (CLM) is undergoing a seismic shift. Machine identities—spanning cloud workloads, IoT devices, containers, and microservices—now outnumber human identities by a staggering ratio of 45:1. Worse, with Google's "Moving Forward, Together" initiative proposing to reduce the maximum public TLS certificate lifespan from 398 days to just 90 days, manual certificate management is no longer just inefficient; it is a critical operational risk.

To survive this transition, engineering and security teams must evolve. The Certificate Management Maturity Model (CMMM) provides a concrete framework to benchmark your current PKI practices and map a journey from reactive, manual firefighting to fully automated, crypto-agile environments.

In this comprehensive guide, we will break down the four stages of the CMMM, compare the tooling landscape available to help you level up, and provide actionable technical steps to automate your certificate infrastructure.

The 4 Stages of the Certificate Management Maturity Model

Understanding where your organization currently stands is the first step toward automation. The CMMM is divided into four distinct levels, each representing a leap in visibility, automation, and resilience.

Level 1: Reactive & Manual (The Danger Zone)

At Level 1, certificate management is an ad-hoc, human-driven process. Organizations at this stage typically track their certificates in massive Excel spreadsheets, Outlook calendar reminders, or sticky notes.

• The Workflow: When a certificate is nearing expiration, a system administrator manually generates a Certificate Signing Request (CSR) via OpenSSL, logs into a Certificate Authority (CA) portal, purchases or requests the certificate, and manually installs it on the target server or load balancer.
• The Risks: This level is characterized by high human error, rampant shadow IT (developers buying certificates on corporate credit cards to bypass slow security approvals), and frequent, costly outages. Gartner estimates that network downtime costs average $300,000 per hour—a steep price for a missed calendar alert.
• The 2025 Reality: Organizations at Level 1 will fundamentally break when the 90-day TLS lifespan mandate takes effect. A human team simply cannot manually rotate thousands of certificates every 60 to 80 days.

Level 2: Centralized & Managed (Gaining Visibility)

The transition to Level 2 begins when an organization realizes it cannot protect what it cannot see. At this stage, teams deploy centralized discovery and monitoring tools to build a comprehensive inventory of all certificates across on-premises networks, cloud environments, and edge devices.

• The Workflow: Automated scanners regularly poll networks and endpoints to detect certificates. Security teams have a single pane of glass showing what certificates exist, who issued them, and when they expire.
• The Risks: While visibility is solved, the actual provisioning and renewal processes remain largely manual. Security teams often become a bottleneck, slowing down CI/CD pipelines as developers wait for certificate approvals.
• The 2025 Reality: Level 2 is excellent for auditing and compliance, but it lacks the execution speed required for modern, ephemeral cloud workloads. However, establishing an independent monitoring layer is critical. This is where tools like Expiring.at shine, providing a reliable, automated alerting system that acts as an independent failsafe, ensuring that even if your automated deployment pipelines fail silently, you are still alerted before an expiration causes an outage.

Level 3: Automated & Integrated (DevOps Aligned)

Level 3 is the current baseline standard for modern enterprise organizations. At this stage, certificate management transitions from a security bottleneck to a seamless, developer-friendly service.

• The Workflow: Zero-touch provisioning is achieved. CLM tools are directly integrated into CI/CD pipelines, container orchestration platforms (like Kubernetes), and IT Service Management (ITSM) tools. Standard protocols like ACME (Automated Certificate Management Environment) and SCEP/EST are heavily utilized.
• The Risks: Achieving Level 3 requires significant upfront engineering effort and a strong cultural alignment between SecOps and DevOps teams.
• The 2025 Reality: Level 3 is mandatory for supporting ephemeral certificates—where cloud-native microservices use mutual TLS (mTLS) certificates that are valid for only hours or minutes.

Level 4: Crypto-Agile (Future-Proof)

The pinnacle of the maturity model is Crypto-Agility. This level is defined by the ability to swap out cryptographic algorithms, Certificate Authorities, or root certificates instantly across the entire infrastructure without application downtime.

• The Workflow: Policy-as-code is strictly enforced. Cryptography is abstracted from the application layer. The organization maintains a dynamic CBOM (Cryptography Bill of Materials).
• The Impetus: In August 2024, NIST finalized the first Post-Quantum Cryptography (PQC) standards (FIPS 203, 204, and 205). Furthermore, the EU's Digital Operational Resilience Act (DORA) mandates strict control over cryptographic assets. Level 4 maturity is required to transition infrastructure to quantum-safe algorithms and comply with these emerging resilience regulations.

Tool Comparison: Choosing the Right Stack for Your Maturity Level

Moving up the maturity model requires the right tooling. The market is generally divided into three categories, each serving different architectural needs and maturity stages.

1. Independent Expiration Tracking & Visibility (Level 1 to Level 2)

Before you can automate, you must inventory. Relying on CA-provided dashboards is insufficient because most organizations use multiple CAs (e.g., Let's Encrypt for dev, DigiCert for prod, AWS ACM for cloud).

• Expiring.at: A highly specialized, lightweight monitoring tool designed to eliminate the "spreadsheet problem." It provides independent, external verification of your certificate health. Even if you use advanced automation (Level 3), Expiring.at serves as the ultimate "trust but verify" failsafe. If an ACME client crashes or a Kubernetes cronjob fails silently, Expiring.at catches the impending expiration and alerts your team via Slack, email, or webhooks before an outage occurs.

2. Cloud-Native & Open Source CLM (Level 2 to Level 3)

For DevOps teams heavily invested in Kubernetes, microservices, and cloud infrastructure, open-source automation tools are the gold standard.

• cert-manager: A Cloud Native Computing Foundation (CNCF) project that adds certificates and certificate issuers as resource types in Kubernetes clusters. It automates the issuance and renewal of certificates from sources like Let's Encrypt and HashiCorp Vault.
• HashiCorp Vault: Widely used as a PKI secrets engine. Vault acts as a dynamic, internal CA that issues short-lived certificates for internal service-to-service communication, perfectly aligning with Zero Trust mandates.
• SPIFFE/SPIRE: The emerging standard for securely authenticating software systems in highly dynamic environments using short-lived cryptographic identities.

3. Enterprise CLM Platforms (Level 3 to Level 4)

Large enterprises dealing with complex, hybrid environments (legacy data centers, IoT devices, multi-cloud) require heavyweight platforms that enforce global policy and enable crypto-agility.

• Venafi: The pioneer in Machine Identity Management. Venafi excels at abstracting the CA from the workload, providing the control plane necessary to achieve Level 4 Crypto-Agility.
• Keyfactor: Offers robust enterprise IT and IoT device identity solutions, making it ideal for manufacturing and hardware-heavy organizations transitioning to PQC.

Practical Implementation: Automating Your Way to Level 3

To illustrate what the jump to Level 3 looks like in practice, let's look at two common technical implementations: automating public-facing certificates with Kubernetes, and establishing an internal CA with HashiCorp Vault.

Example 1: Automating Ingress Certificates with cert-manager

If your team manually updates load balancer certificates, you are at Level 1. By deploying cert-manager in Kubernetes, you can leverage the ACME protocol to achieve zero-touch provisioning.

First, you define a ClusterIssuer that tells Kubernetes how to communicate with Let's Encrypt:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: security@yourdomain.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: nginx

Next, you simply annotate your Ingress resource. cert-manager will automatically detect this, generate a CSR, solve the ACME challenge, and mount the