Certificate lifetimes and compliance dates
Maximum lifetimes for publicly trusted TLS certificates are shrinking on a schedule agreed by the CA/Browser Forum. This is the single strongest argument for automation: the arithmetic stops working for manual processes.
The schedule
Section titled “The schedule”| From | Max TLS validity | Max domain-validation reuse |
|---|---|---|
| until 2026-03-14 | 398 days | 398 days |
| 2026-03-15 | 200 days | 200 days |
| 2027-03-15 | 100 days | 100 days |
| 2029-03-15 | 47 days | 10 days |
Set against a working year, that is roughly:
| Period | Renewals per certificate per year |
|---|---|
| 398 days | ~1 |
| 200 days | ~2 |
| 100 days | ~4 |
| 47 days | ~8 |
At 47 days, a hundred certificates means eight hundred renewals a year, and a domain validation that can only be reused for ten days. Manual renewal is not merely tedious at that point; it is arithmetically impossible to staff.
Plan for the 2029 numbers now. Anything built assuming an annual cycle will be rewritten.
Other dates worth knowing
Section titled “Other dates worth knowing”MPIC, from 2026-03-15. CAs must corroborate domain validation from at least three network perspectives. Handled by the CAs; it can make validation slower and occasionally flakier for hosts reachable from only some networks. If validation fails for a host behind geo-restricted DNS or a split-horizon setup, this is a likely cause.
S/MIME Baseline Requirements. Multipurpose and strict profiles cap at 825 days,
legacy profiles are being retired, and domain validation for S/MIME must be no
older than 398 days. Reflected in
smime_profile.
Post-quantum. ML-DSA (FIPS 204) is standardised. CNSA 2.0 sets January 2027 for
US National Security Systems. Browser and OS support governs when hybrid chains
become default rather than experimental. NextPKI’s data model already expresses
hybrid algorithms, so a hybrid certificate can be inventoried rather than reported
as unknown.
eIDAS 2.0. Progressive obligations for EU trust services, including EUDI wallet work. Relevant through QWAC-capable providers in the registry.
What this means for your integration
Section titled “What this means for your integration”Do not hard-code lifetimes. Read not_before and not_after. A client that
assumes a year is already wrong.
Do not renew on a fixed calendar date. Renew on a window relative to
not_after. NextPKI’s own scheduler uses 30 days, which is comfortable at 200-day
lifetimes and will need revisiting at 47.
Make deployment automatic, not just issuance. At eight renewals a year, a manual copy-and-reload step is where the outage will come from. See automate renewals.
Expect short-lived certificates to be normal. Alert thresholds tuned for annual certificates produce constant noise against 47-day ones.