The 90-Day TLS Mandate: Advancing Your Certificate Management Maturity Model

In the world of modern infrastructure, a simple expired digital certificate can cause more financial damage and brand reputation loss than a sophisticated cyberattack. According to recent industry reports, over 80% of organizations have experienced at least one certificate-related outage in the past 24 months. The average resolution time? Over three hours of frantic troubleshooting, log parsing, and manual renewals.

Historically, IT teams could scrape by using spreadsheets and calendar reminders to manage Public Key Infrastructure (PKI). Certificates lasted for two or three years, making manual rotation a tedious but manageable annual chore.

Those days are officially over.

With Google’s Chromium Root Program pushing to reduce the maximum validity of public TLS certificates from 398 days to just 90 days, and the rapid shrinking of internal microservice certificate lifespans to mere hours, manual management is no longer mathematically possible. To survive this shift, organizations must evaluate their current operations against the Certificate Management Maturity Model (CMMM) and aggressively push toward total automation.

This guide breaks down the four stages of the CMMM, explores the impending cryptographic changes you need to prepare for, and provides actionable, code-driven steps to level up your infrastructure.

Understanding the Certificate Management Maturity Model (CMMM)

The CMMM is a strategic framework that helps DevOps, security professionals, and IT administrators benchmark their current PKI operations and map a clear path toward zero-touch, crypto-agile automation.

Stage 1: Reactive (The "Spreadsheet" Era)

At this stage, certificate management is highly decentralized and entirely manual. IT teams track expirations using Excel spreadsheets, Jira tickets, or tribal knowledge.

• The Symptoms: Purchasing is fragmented across different departments. Developers bypass IT to spin up quick, self-signed certificates or free Let's Encrypt certs in cloud environments, creating massive blind spots known as "Shadow PKI."
• The Business Impact: Frequent, unexpected outages. When a critical load balancer goes down, engineers waste hours hunting for the private key and the employee who originally provisioned it. Compliance violations are common.

Stage 2: Managed (Centralized Visibility)

Organizations in Stage 2 have recognized the pain of outages and implemented centralized tracking and alerting. They have a known inventory of their certificates and standardized Certificate Authority (CA) usage.

• The Symptoms: Implementation of continuous discovery tools, network scanners, and Certificate Transparency (CT) log monitoring. Teams receive automated alerts well before a certificate expires.
• The Business Impact: Outages are drastically reduced. However, the actual renewal and provisioning processes still require human intervention—generating a CSR (Certificate Signing Request), logging into a CA portal, downloading the cert, and manually binding it to a web server.

Pro Tip: If you are currently in Stage 1, adopting a dedicated monitoring tool like Expiring.at is the fastest way to achieve Stage 2. It provides the centralized visibility and critical alerting infrastructure needed to stop the bleeding of surprise outages.

Stage 3: Automated (Zero-Touch Provisioning)

This is the baseline requirement for surviving the 90-day TLS mandate. At Stage 3, human beings are entirely removed from the certificate lifecycle.

• The Symptoms: Deep integration with CI/CD pipelines. Infrastructure-as-code (IaC) automatically requests and binds certificates during deployment. Heavy reliance on standard protocols like ACME (Automated Certificate Management Environment) for web servers and SCEP/EST for IoT devices.
• The Business Impact: Zero human error. The organization can effortlessly handle short-lived certificates, and engineering teams reclaim hundreds of hours previously spent on manual renewals.

Stage 4: Crypto-Agile (Future-Proof & Policy-Driven)

The pinnacle of the maturity model. Crypto-agility means your infrastructure is governed by policy-as-code, allowing you to instantly swap out cryptographic algorithms or entire CAs across the enterprise without touching application code.

• The Symptoms: Deep Zero Trust integration. Readiness for Post-Quantum Cryptography (PQC). If a CA is compromised, or an algorithm is deprecated, the organization can rotate every machine identity globally in minutes.
• The Business Impact: Complete resilience against cryptographic deprecation, CA compromises, and future regulatory mandates.

The Catalysts for Change: Why You Must Advance Now

If your organization is lingering in Stage 1 or 2, several impending industry shifts are about to turn your technical debt into an operational crisis.

1. The 90-Day TLS Mandate

Google’s proposal to reduce maximum TLS validity to 90 days is widely accepted as an inevitability for 2025/2026. If you manage 1,000 public-facing certificates, a 90-day lifespan means you are processing roughly 11 manual renewals every single day. Without Stage 3 automation, your security team will become a full-time certificate renewal factory.

2. Post-Quantum Cryptography (PQC) Standardization

In August 2024, NIST finalized the first set of PQC standards (FIPS 203, 204, and 205). Quantum computers capable of breaking RSA and ECC cryptography are on the horizon. Organizations are now mandated to begin transitioning their PKI to quantum-resistant algorithms. You cannot achieve a smooth PQC migration without first reaching Stage 4 Crypto-Agility.

3. Strict Regulatory Frameworks

New regulations demand strict control over cryptography. The EU's Digital Operational Resilience Act (DORA), taking effect in January 2025, requires financial entities to strictly control ICT risks—heavily implicating certificate-driven outages. Similarly, PCI-DSS v4.0 demands accurate, automated inventories of all trusted keys and certificates.

Actionable Steps to Level Up Your Infrastructure

Moving up the CMMM requires a combination of process changes and technical implementations. Here is how you can practically advance your infrastructure.

Step 1: Establish Continuous Discovery and Alerting (Moving to Stage 2)

You cannot manage what you cannot see. Before you can automate renewals, you must eliminate Shadow PKI. Relying on manual openssl commands to check expirations is a recipe for disaster:

# The old, manual way of checking expirations
echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

Instead, you need continuous, automated discovery.
1. Scan your perimeters: Utilize network scanners on port 443 to find active certificates.
2. Monitor CT Logs: Certificate Transparency logs are public records of all issued TLS certificates. Monitoring them helps you catch certificates issued by developers outside of official IT channels.
3. Implement Centralized Alerting: Use a platform like Expiring.at to aggregate this data. Set up webhooks to push expiration warnings directly into your Slack channels, PagerDuty, or Jira boards 30, 15, and 7 days before expiration.

Step 2: Adopt Standard Automation Protocols (Moving to Stage 3)

Stop using proprietary CA dashboards and manual CSR generation. The ACME protocol is the industry standard for automated certificate issuance and rotation.

For standard Linux web servers (Nginx/Apache), implementing an ACME client like Certbot is straightforward. However, the true power of ACME shines when integrated into modern cloud-native environments.

Step 3: Shift-Left PKI with Kubernetes and cert-manager

If you are running containerized workloads, cert-manager (a graduated CNCF project) is the absolute standard for Stage 3 automation. It natively integrates with Kubernetes to ensure certificates are valid and up to date.

Instead of a developer requesting a certificate, they simply define their ingress routing, and the infrastructure handles the rest.

Here is a practical example of setting up a ClusterIssuer using Let's Encrypt via the ACME protocol in Kubernetes:

# cluster-issuer.yaml
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

Once the issuer is configured, developers simply request a certificate using a Kubernetes manifest. Notice how the developer never touches a private key or a CSR:

# certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-gateway-cert
  namespace: production
spec:
  # Instructs cert-manager to renew the cert 30 days before expiration
  renewBefore: 720h 
  secretName: api-gateway-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - api.yourdomain.com

With this setup, cert-manager will automatically handle the ACME challenge, provision the certificate, store it as a Kubernetes Secret, and auto-renew it every 60 days (well within the impending 90-day mandate).

Step 4: Modernize Internal PKI for Microservices

Public TLS is only half the battle. Internal microservices communicating via mutual TLS (mTLS) require certificates with incredibly short lifespans—often just hours. Legacy systems like Microsoft Active Directory Certificate Services (ADCS) were not built for the velocity of cloud-native environments.

To reach Stage 3 and 4 internally, integrate tools like HashiCorp Vault. Vault’s PKI secrets engine can dynamically generate X.509 certificates on the fly. Because the certificates are so short-lived, the risk of a compromised key is drastically reduced, and you rarely need to worry about complex Certificate Revocation Lists (CRLs).

Real-World Case Studies: The Cost of Stagnation vs. The Value of Automation

The Stage 1 Failure (A Cautionary Tale)
Recently, a major global telecommunications provider suffered a catastrophic 12-hour outage of their primary customer portal. The root cause? A wildcard certificate installed on an obscure, legacy load balancer had expired. The certificate was being tracked in an outdated SharePoint Excel file by an engineer who had left the company six months prior. The resulting downtime cost the company millions in SLA penalties and severe brand damage.

The Stage 3 Success (The Aspirational Standard)
Conversely, a rapidly scaling SaaS company recognized the impending 90-day mandate and overhauled their infrastructure. They migrated to Kubernetes, implementing cert-manager integrated with Let's Encrypt for public ingress and HashiCorp Vault for internal