Certificate lifecycle management and the 47-day deadline

The timeline

Subject Identity Information reuse for OV and EV certificates dropped to 398 days from 15 March 2026, and domain control validation reuse tightens to 10 days by the end state, so you revalidate domains far more often as well as reissuing more often.

Why this is a non-human identity problem, not a PKI problem

Certificates are credentials held by software to prove identity to other software. That is the definition of a non-human identity. The reason certificate management has historically been treated as a separate discipline is organisational, not technical: it lived with the PKI team, it used different tooling, and its failure mode was an outage rather than a breach.

The 47-day change collapses that separation, for a specific reason. At annual renewal, a spreadsheet plus a calendar reminder is a viable control. At monthly renewal across an estate of thousands of certificates, the only viable control is automated discovery, automated issuance, automated deployment, and automated verification, which is precisely the control set required for API keys, workload credentials, and service account keys.

The strategic implication for governance programmes: if you are building an NHI programme and a CLM programme in parallel with different owners, different budgets, and different tooling, you are paying twice for one capability. The discovery layer, the ownership attribution layer, the rotation layer, and the evidence layer are the same in both cases. See NHI lifecycle management for the shared model.

The failure modes to plan for

• The unknown certificate. You cannot automate renewal for a certificate you do not know exists. Discovery is the binding constraint, and at 47 days an unknown certificate becomes an outage within seven weeks rather than within a year. Most organisations discover their true certificate count is two to five times their tracked count.
• The unautomatable endpoint. Appliances, embedded devices, legacy middleware, and anything where certificate installation requires a GUI or a vendor engineer. These need to be identified now and either replaced, fronted by a terminating proxy, or moved to private PKI with a documented risk acceptance.
• IoT and embedded devices. The ballot explicitly acknowledges that many devices cannot easily update certificates. If you have field-deployed devices with public TLS certificates and no remote update path, that is a strategic problem requiring a hardware or architecture decision, not an operational one.
• Ownership gaps. Automated renewal fails silently when the automation breaks and no one owns the alert. The renewal is automated; the accountability cannot be.
• Certificate authority concentration. Eightfold issuance volume against a single CA is an availability dependency worth deliberately assessing.

The post-quantum connection

The crypto-agility rationale is the part most organisations under-weight, and it is the one that matters over a five to ten year horizon.

NIST finalised the first post-quantum cryptographic standards in 2024 and its published trajectory points toward deprecating current RSA and elliptic-curve algorithms around 2030. Separately, the EU has published a post-quantum migration roadmap, adding regulatory pressure to the same timeline. "Harvest now, decrypt later" collection, capturing encrypted traffic today to decrypt once quantum capability matures, makes the timeline present-tense for anything with long-term confidentiality requirements.

The connection is mechanical: an organisation that can reissue its entire certificate estate on a 47-day cycle can complete an algorithm migration in weeks. An organisation that cannot will need years. The CA/Browser Forum change is, in effect, a mandatory rehearsal for post-quantum migration. That reframing is the one worth taking to a budget conversation, because it converts a compliance cost into an option on a much larger future cost.

What to do, in order

1. Inventory. Discover every certificate, public and private, including ones outside the PKI team's visibility. Expect the real number to exceed the tracked number substantially.
2. Attribute ownership. Every certificate needs an accountable human or team. This is the step that is skipped and the step that causes outages.
3. Classify by automatability. Three buckets: already automated, automatable with work, and cannot be automated. The third bucket is your actual project.
4. Automate issuance and deployment. ACME where possible. The measure of success is not "we have a CLM tool" but "no human touches a renewal in the normal path."
5. Instrument the failure path. Alert on renewal failure, on approaching expiry, and on newly discovered untracked certificates, with a named owner for each alert.
6. Design for algorithm substitution. Assume the algorithm changes. Anything that hard-codes key type or size is future rework.
7. Merge with your NHI programme. Same discovery, same ownership model, same rotation machinery, same audit evidence.

Frequently asked questions

When do 47-day TLS certificates become mandatory?

15 March 2029, under CA/Browser Forum ballot SC-081v3. The reduction is phased: maximum lifetimes drop to 200 days on 15 March 2026, to 100 days on 15 March 2027, and to 47 days on 15 March 2029. Domain control validation reuse tightens to 10 days at the end state.

Does the 47-day rule apply to internal or private certificates?

Not directly. CA/Browser Forum requirements govern publicly trusted TLS certificates. Private PKI is outside their scope. In practice most organisations align internal issuance to the same cadence, because running two operating models for the same control costs more than running one.

Are certificates non-human identities?

Yes. A certificate is a credential held by software to authenticate to other software, which is the defining characteristic of a non-human identity. The historical separation between certificate lifecycle management and NHI governance is organisational rather than technical, and shortening lifetimes is collapsing it.

What happens to IoT and embedded devices?

This is the hardest case. The CA/Browser Forum ballot explicitly acknowledges that many devices cannot easily update certificates. Organisations with field-deployed devices carrying public TLS certificates and no remote update path face an architecture or hardware decision rather than an operational one, and it needs to be identified well before 2029.

How does this relate to post-quantum cryptography?

Directly. NIST's published trajectory points toward deprecating current RSA and elliptic-curve algorithms around 2030, and the EU has published its own post-quantum migration roadmap. An organisation that can reissue its whole certificate estate on a 47-day cycle can migrate algorithms in weeks; one that cannot will need years. The 47-day requirement functions as a mandatory rehearsal for that migration.

What is the single biggest cause of failure at 47 days?

Undiscovered certificates. Automation cannot renew what is not inventoried, and at a 47-day lifetime an untracked certificate becomes an outage within seven weeks rather than within a year. Discovery, not tooling, is the binding constraint for most organisations.