Renewal Is a Control, Not a Reminder: Auditing Certificate Expiry in a Zero-Trust Estate

In many UK estates, certificate expiry is still managed as a calendar event. A spreadsheet carries the date, an owner carries the reminder, and a change ticket carries the renewal. That model survives while lifetimes are long and the estate is small. It becomes a liability when public certificate lifetimes compress and the number of machine identities grows faster than the team that owns them.

The direction of travel is clear. The CA/Browser Forum schedule moves public TLS certificates to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. As of November 2026, many organisations have adjusted their public-facing certificates but have not changed the operating model behind them. Internal PKI, VPN concentrators, device certificates and supplier-managed services often remain on annual cycles, manual issuance and informal ownership. Zero trust makes that gap more visible because every one of those certificates is attached to a trust decision.

The certificate estate is a dependency graph

A certificate inventory that counts certificates is not an assurance artefact. The useful question is which trust decisions depend on which certificate, and what happens when that certificate expires, is revoked or cannot be renewed. External TLS certificates protect public services. VPN concentrators authenticate remote workers. Device certificates support 802.1X, MDM enrolment and workload identity. Internal CAs issue certificates to APIs, service meshes, databases and code-signing pipelines. Each is a dependency in a chain of authentication, and each has a different failure mode.

Some trust decisions fail closed. A service mesh may reject a workload with an expired certificate and halt a transaction. Some fail open. An embedded appliance may continue to accept connections because the relying party does not check validity strictly, or because the certificate is pinned and the pin has never been rotated. The audit should record both. A trust outage is not only a service that stops. It is also a service that continues when it should not.

Where a missed renewal becomes a trust outage

The awkward cases are where the calendar model hides. Embedded devices are the first. Building management systems, printers, IP cameras, older load balancers and operational technology often have no ACME client and no supported way to automate renewal. They should not be exempted from the inventory. They should be recorded with a compensating control, a manual runbook, a vendor attestation and a replacement date. If the device cannot support short-lived certificates, the architecture should say so explicitly and segment the trust decision accordingly.

Outsourced managed PKI is the second. A contract may state that the supplier manages issuance and renewal, but the assurance question is whether the organisation can evidence expiry telemetry, revocation status and renewal success. The supplier may hold the CA, but the relying parties remain in the estate. The audit should test the interface between the two: who receives expiry alerts, who approves emergency issuance, and how a supplier outage is handled. A service level agreement that covers availability but not certificate lifecycle evidence is incomplete.

Internal CAs nobody has rotated since the last acquisition are the third. Acquisitions leave orphaned certificate authorities, undocumented templates, weak algorithms and reliance on CRL or OCSP services that no one monitors. Discovery is not only a scanning exercise. It requires reading directory logs, reviewing AD CS templates, inspecting trust stores and asking application owners which CA signed the certificates they depend on. An internal CA without an owner is a trust dependency without an accountable control.

An audit that produces evidence, not a spreadsheet

A practical audit starts with relying parties, not certificate counts. For each trust path, record the certificate, the issuing CA, the relying party, the renewal method, the expiry threshold and the failure mode. Then test the operating model against four questions.

First, is expiry telemetry visible where operations actually look? A report that lands in a shared mailbox is not telemetry. Expiry data should feed the monitoring and incident platforms used for other availability risks, with thresholds set relative to the issuance window. For a 47-day certificate, a 30-day warning is not early warning. It is the middle of the renewal window.

Second, what proportion of the estate is automated? The existence of an ACME client is not coverage. Measure the percentage of certificates issued and renewed without human intervention, the renewal success rate and the time taken to recover from a failed issuance. Manual exceptions should be listed, owned and reviewed, not hidden in a spreadsheet tab.

Third, has the failure path been rehearsed? An expired certificate in a canary environment is a test. A simulated CA outage, an emergency issuance exercise and a break-glass procedure that still satisfies zero-trust policy are evidence. A tabletop discussion is useful preparation, but it is not a substitute for a controlled failure test.

Fourth, is renewal treated as routine change? Automated renewal should not wait for a weekly change advisory board. The control is the automation, the monitoring and the rollback path, not the ticket. Where manual renewal remains, the change record should show the approval, the test and the rollback, and the audit should sample it.

The 47-day question is a design question

Shorter lifetimes reduce the window in which a compromised certificate remains useful. They also increase the tempo of operations. For organisations with mature automation, the change is manageable. For organisations with legacy appliances, outsourced PKI and unowned internal CAs, the change exposes design debt that annual renewal concealed.

The response is not to wait for 2029. It is to use 2026 to find the trust paths that cannot survive a shorter cycle. Some workloads will move to automated issuance. Some devices will be replaced or segmented. Some supplier contracts will be rewritten to require lifecycle evidence. A few exceptions will remain, but they should be documented exceptions with compensating controls, not calendar accidents waiting to happen.

Certificate renewal is a zero-trust capability because trust is only as durable as the evidence that identity remains valid. A reminder can be missed. A tested control should not be.