How shorter certificate lifetimes enable post-quantum migration

Certificate lifetime determines how quickly an algorithm change reaches an estate. With automated issuance, reconfiguring the issuing authority moves every endpoint within one certificate lifetime. The reduction to 47 days by 2029 therefore turns a multi-year migration into a rotation, provided automation is in place first.

Why certificate lifetime governs migration speed

An algorithm change is not deployed. It propagates. The issuing authority is reconfigured to issue under the new algorithm, and each endpoint adopts it when its certificate next renews.

That makes the maximum time to clear the estate equal to one certificate lifetime, assuming issuance is automated and every certificate is under management. At a three-year internal lifetime, the estate converges three years after the change. At 47 days, it converges in under two months.

This is the single most useful property in a post-quantum programme, because it converts the hardest part of migration, touching every endpoint, into something that happens by itself. It is also entirely conditional on automation, which is the point most often missed.

What the reduction schedule requires

CA/Browser Forum ballot SC-081v3, passed in April 2025, reduces the maximum validity of publicly trusted TLS certificates on a fixed schedule, with domain validation data reuse periods tightening alongside.

The right-hand column is the post-quantum consequence. By the time the NCSC expects highest-priority migration to be complete in 2031, an automated estate on public certificates will propagate an algorithm change in weeks.

The schedule is enforced by browser root programmes rather than advisory, so the shortening happens whether or not an organisation prepares for it.

Shorter lifetimes without automation make things worse

The same property that makes short lifetimes powerful makes them dangerous in a manual estate.

At 398 days, a certificate is renewed roughly once a year and a missed renewal is an occasional incident. At 47 days it is renewed nearly eight times a year, and every renewal is an opportunity for failure. The outage probability rises in direct proportion to renewal frequency, and manual processes do not scale to absorb it.

An organisation that shortens internal certificate lifetimes hoping to gain agility, without first automating issuance, will simply increase its outage rate. The sequence is automation first, then lifetime reduction, then algorithm change.

What automation actually requires

Four things, and the last is the one usually missing.

An enrolment protocol the endpoints support, whether ACME, EST, SCEP or CMP, so that renewal happens without human involvement. Coverage of the whole estate rather than the easy part, since certificates outside the automation are the ones that fail. Monitoring that detects certificates approaching expiry and renewals that did not complete, because automated failure is silent failure. And ownership, meaning a named team accountable for the issuance platform rather than distributed responsibility across application owners.

Where those exist, an algorithm change is a configuration change at the issuing authority. Where they do not, it is a project with an endpoint count.

Applying this to internal certificates

Public TLS lifetimes are being shortened for you. Internal lifetimes are a choice, and most organisations still issue internal certificates for one to three years.

There is a strong argument for aligning internal lifetimes with the public direction ahead of the deadline, because it builds the capability where the consequences of failure are contained. An internal estate operating at short lifetimes with automated issuance is, by construction, ready to accept an algorithm change. One operating at three-year lifetimes with manual renewal is not, and will discover that only when the change is required.

Internal certificates also carry more of the post-quantum risk in most estates. Device identity, service authentication, machine-to-machine connections and administrative access typically run on internal hierarchies, and those are the credentials whose forgery grants direct access.

Where shorter lifetimes do not help

Three categories remain outside this mechanism and need separate treatment.

Long-lived keys are the point. Root certificates, code signing keys and firmware verification keys are deliberately long-lived, and they are the assets an early, scarce quantum capability would be aimed at. They require planned replacement rather than rotation.

Embedded and operational technology devices frequently cannot renew automatically, either because they lack the protocol support or because their certificates are provisioned at manufacture. These are covered in quantum risk in embedded and operational technology.

Public post-quantum certificates are not yet available, since no post-quantum roots have been accepted into the browser trust stores. The propagation benefit applies today to private hierarchies, and to public certificates once the ecosystem permits it.

The practical sequence

Automate first, across the whole estate rather than the straightforward part, with monitoring that detects both expiry and renewal failure.

Shorten internal lifetimes progressively once automation is proven, moving in stages rather than in a single step so that any gaps in coverage surface at low volume.

Verify propagation by making a controlled change at the issuing authority and confirming that endpoints adopt it through normal renewal. This proves the mechanism before it is needed for an algorithm change.

Then treat the post-quantum algorithm change as a rotation. Stand up the post-quantum hierarchy, reconfigure issuance, and allow the estate to converge, dealing separately with the assets that cannot participate.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We establish actual certificate coverage, including the certificates no register holds, through our PKI health check, then design and deliver the certificate lifecycle management capability that makes short lifetimes safe rather than hazardous. Where a parallel post-quantum hierarchy is required, our PKI design and build practice delivers it alongside the automation that populates it.

For the funding argument that this capability usually rests on, see building the investment case for certificate lifecycle management.

‍