Certificate lifecycle management vs spreadsheet renewals

Certificate lifecycle management (CLM) is the unglamorous work of knowing which certificates you have, who they belong to, when they expire, how they get renewed, and where they are installed. A spreadsheet can hold the first three. It cannot perform the last two.

That gap is the whole pain. The sheet is an inventory with no hands.

Vendors from the large CLM suites down to focused automation tools will all tell you they manage the lifecycle. Many of them do renew and redeploy. Comparing them by the word "automation" does not help. Compare them by whether a failed renewal is visible, and whether the new certificate reaches the device that terminates TLS.

What people put in the sheet

A typical renewal sheet has a hostname, an expiry, a vendor, and an owner. Sometimes it has a port. It rarely has the binding: which IIS site, which firewall VIP, which VPN portal, which proxy server block. The owner is whoever last edited the row.

The sheet is useful the week someone builds it. It decays when a name is added during an incident, when a firewall is replaced, or when the owner leaves and the row still says their name. Expiry monitoring that reads the sheet is monitoring the sheet, not the network.

Use the certificate inventory template to record the fields needed for renewal. A better inventory is the one you would trust on a Friday. Each row needs the name clients use, the device that presents the certificate, the expiry, the last successful install, and the last error. If the last error is empty only because nobody records errors, you do not have monitoring. You have a list.

Where spreadsheet renewals fail first

They fail in the same places every time.

• A name exists on a device and not in the sheet. Nobody is warned.
• The sheet says the certificate was renewed because the CA portal says so. The device was not updated. Automatic certificate deployment is the missing step.
• The renewal ran and failed, and the only notification was an email to a shared inbox over a holiday. The Bazel outage writeup describes certificate expiry on 26 December 2025 after auto-renewal failed without a notification. Details and the separate Bank of England incident are in how to stop expiry outages. Neither incident is evidence for a particular product.
• Two people renew the same name in different ways, and the sheet records whichever one remembered to edit it.

Shortening public TLS lifetimes makes the decay faster. A sheet you reconcile twice a year becomes wrong in the gaps between reconciliations. The dates are in TLS certificate lifetime changes. About 200 days is the ceiling now. One hundred days and 47 days are later. They are not the limit today.

What CLM has to cover, in order

Use the phrase for the work, not as a logo.

1. Inventory. Names, devices, and expiries you can filter. "Expiring soon" and "failed" are the views that matter. Healthy is the rest.
2. Monitoring. Alert on approaching expiry and on a renewal or install that failed. One without the other leaves a hole.
3. Renewal. An order with the authority, on a clock, with an error you can read.
4. Deployment. Install on the device, then check the live service.
5. Recovery. Dry-run when you want to see the change. Rollback when the check fails.

If a tool does 1 and 3, you have a nicer spreadsheet and a CA integration. The outage still lives in 4.

The install target is the hard part

ACME clients made renewal ordinary for a single web server. CLM projects stall on the devices that do not run those clients: firewalls, VPN gateways, and Windows roles. The launch set Certonomy installs on is FortiGate, IIS, Windows Server, and RDS, Palo Alto PAN-OS and GlobalProtect, SonicWall, Sophos, WatchGuard, NGINX, Apache, and HAProxy. Later platforms are listed on the product page and are not install targets yet. The checklist is here: device certificate auto-renew.

The private key stays on site. The agent creates it there. Certonomy completes the ACME order, delivers the certificate to the agent, and does not take the key back. The agent installs, verifies the live service, and rolls back if the check fails.

That is a lifecycle. Discovery and monitoring are the inventory and the status. Auto-renew is the order. Redeploy is the install. Skip any of those and you are back to a sheet plus a ticket.

Replacing the sheet without a six-month program

You do not need every certificate in the company on day one. Start with the names whose failure would page someone: the VPN, the public site, the remote desktop gateway, the firewall admin interface you actually use.

Put those in an inventory that records expiry and failure. Point renewal at them. Confirm the install with a connection to the name, not with a green row in a portal.

See how it works for that path on the platforms above. Founding pricing for teams and MSPs is on the product page. This guide does not restate it, and it does not rank one vendor as the only way to renew a certificate.