Transitioning from Manual Certificate Tracking to Cryptographic Agility

The mathematical reality of modern infrastructure is making manual certificate management impossible. Google has signaled its intent to reduce the maximum validity of public TLS certificates from 398 days to 90 days. Simultaneously, machine identities—containers, virtual machines, APIs, and IoT devices—now outnumber human identities in the enterprise by a factor of 45 to 1.

If your team is tracking renewals in a spreadsheet, a 90-day lifecycle across thousands of microservices means you will be manually rotating certificates every single day.

To survive this shift, organizations must modernize their Public Key Infrastructure (PKI) and Machine Identity Management. The framework used to measure this progression is the Certificate Management Maturity Model (CMMM). By understanding where your infrastructure currently sits on this spectrum, you can build a roadmap to eliminate expiration outages, secure ephemeral workloads, and prepare for the post-quantum cryptography transition.

Level 1: Reactive and Decentralized

At the lowest level of maturity, certificate management is entirely manual, heavily decentralized, and largely invisible to central IT or security teams.

In a Level 1 organization, developers and system administrators generate Certificate Signing Requests (CSRs) manually using OpenSSL. They purchase certificates from various public Certificate Authorities (CAs) using corporate credit cards, creating massive pockets of Shadow IT. The tracking system is usually a shared Excel spreadsheet or a fragmented Wiki page that relies on human memory for updates.

The business impact of operating at Level 1 is severe. According to the 2024 Keyfactor State of Machine Identity Report, over 50% of organizations still rely on spreadsheets, and 77% have experienced at least one severe outage due to an expired certificate in the past 24 months.

High-profile examples of Level 1 failures are common. In 2022, Starlink suffered a massive global outage caused by a single expired ground-station certificate. Across 2023 and 2024, Cisco issued multiple security advisories detailing how expired internal certificates broke VPN and web-filter functionalities. When outages occur at this level, incident response is notoriously slow because teams must first locate the expired certificate, figure out who owns it, and manually execute the renewal and installation process.

Level 2: Managed and Centralized

The transition to Level 2 begins when an organization realizes that relying on human memory to prevent infrastructure outages is an unacceptable operational risk. The primary goal of Level 2 is establishing centralized visibility and alerting.

At this stage, organizations deploy discovery sensors and unauthenticated network scanners (running continuous port 443 sweeps) to build a dynamic inventory of every certificate active on their network. They also integrate with cloud providers (like AWS Certificate Manager) and load balancers (like F5) to pull certificate metadata into a single pane of glass.

While provisioning and deployment are often still manual—relying on Jira or ServiceNow tickets—the risk of unexpected expiration drops drastically. This is where dedicated tracking and alerting tools become invaluable. By routing your discovered inventory into Expiring.at, you can configure automated, multi-channel alerts (via Slack, email, or webhook) well before a certificate reaches its expiration date.

Level 2 stops the bleeding. It prevents the catastrophic, revenue-impacting outages caused by forgotten renewals. However, it does not solve the scaling problem. When the 90-day TLS mandate takes effect, alerting alone won't be enough if your team lacks the engineering hours to manually process the sheer volume of incoming renewal tickets.

Level 3: Automated and Zero-Touch

Level 3 is where certificate management transforms from an IT operations task into a seamless DevOps process. At this stage, human intervention is completely removed from the certificate lifecycle. Certificates are provisioned, deployed, and renewed automatically.

Achieving Level 3 requires embracing the Automated Certificate Management Environment (ACME - RFC 8555). Originally popularized by Let's Encrypt for public web servers, ACME is now a mandatory protocol for internal enterprise PKI.

In a Level 3 architecture, certificate provisioning is shifted left and embedded directly into Infrastructure as Code (IaC) and CI/CD pipelines.

Kubernetes Automation with cert-manager

For containerized environments, cert-manager is the industry standard for achieving Level 3 automation. It runs as a native Kubernetes add-on, watching for specific annotations on Ingress resources or custom Certificate resources, and automatically negotiates with your CA (via ACME, Vault, or Venafi) to issue and mount the certificate as a Kubernetes Secret.

Here is an example of how a Level 3 organization automates Let's Encrypt certificates using a ClusterIssuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: security@yourdomain.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - http01:
        ingress:
          class: nginx
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-gateway-cert
  namespace: production
spec:
  secretName: api-gateway-tls
  duration: 2160h # 90 days
  renewBefore: 360h # 15 days
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - api.yourdomain.com

With this configuration, cert-manager handles the initial issuance, continually monitors the certificate's time-to-live (TTL), and automatically executes the renewal and secret rotation 15 days before expiration. The application pods seamlessly pick up the new certificate without downtime.

Ephemeral Certificates with HashiCorp Vault

Level 3 also tackles internal East-West traffic. Under a Zero Trust Architecture (ZTA), such as NIST SP 800-207, every workload must be mutually authenticated (mTLS).

For highly ephemeral environments, organizations use tools like HashiCorp Vault to act as an intermediate CA. Vault's PKI Secrets Engine can dynamically generate certificates that live for only hours or days.

```bash

Generating a short-lived, 24-hour certificate for an internal microservice

vault write pki_int/issue/microservice-role \
common_name="payment-service.internal" \
ttl="24h"