> Dated, plain summary of what is changing in certificates and PKI: 47-day lifetimes, OCSP, clientAuth, Let's Encrypt, post-quantum and EU rules. Source: https://pkizerotohero.com/changes/ · Last reviewed: 2026-10-19 # What's changing in PKI Last reviewed 19 October 2026 As of 2026-10-20. Public TLS certificates are getting much shorter lives, revocation is moving from OCSP to CRLs, public certificates are losing their client-authentication purpose, and post-quantum cryptography has moved from research into browsers and government roadmaps. **In short:** the maximum lifetime of a public TLS certificate is 200 days today and drops to 100 days from 15 March 2027, then to 47 days from 15 March 2029. Manual renewal stops being realistic, so automation (usually [ACME](https://pkizerotohero.com/handbook/glossary/#acme)) and a certificate inventory become basic hygiene. At the same time, OCSP has become optional and Let’s Encrypt has switched it off, public certificates are being limited to server authentication, and major browsers already use hybrid post-quantum key exchange by default. In the EU, NIS2 and DORA make cryptography policy and security training part of risk management. Note How this page works We update this page every quarter and whenever a big change is announced. Every date and number on it comes from a list of dated facts, each linked to its primary source. Found something out of date? [Tell us](mailto:info@pkizerotohero.com?subject=Error%20report:%20What's%20changing%20in%20PKI). **Who this page is for:** developers, IT operations and platform teams, security people, and leaders who need the dates. New to certificates? Start with the [crash course](https://pkizerotohero.com/course/) and come back. ## The timeline at a glance | When | What changes | Read more | | --- | --- | --- | | 15 March 2024 | OCSP became optional and CRLs became mandatory for publicly trusted TLS certificates | [Revocation](https://pkizerotohero.com/changes/#is-ocsp-going-away) | | 4 June 2025 | Let's Encrypt no longer sends expiration reminder emails | [Let’s Encrypt](https://pkizerotohero.com/changes/#what-has-changed-at-lets-encrypt) | | 6 August 2025 | Let's Encrypt has shut down its OCSP service | [Revocation](https://pkizerotohero.com/changes/#is-ocsp-going-away) | | 15 March 2026 | Maximum TLS certificate lifetime: 200 days | [Lifetimes](https://pkizerotohero.com/changes/#how-long-can-a-tls-certificate-be-valid) | | 15 June 2026 | Chrome's root program starts phasing out root hierarchies that are not dedicated to TLS server authentication | [Client authentication](https://pkizerotohero.com/changes/#why-are-public-certificates-losing-client-authentication) | | 15 March 2027 | Maximum TLS certificate lifetime: 100 days | [Lifetimes](https://pkizerotohero.com/changes/#how-long-can-a-tls-certificate-be-valid) | | 15 March 2027 | TLS certificates that chain to the Chrome Root Store must list only the TLS server authentication purpose | [Client authentication](https://pkizerotohero.com/changes/#why-are-public-certificates-losing-client-authentication) | | 15 March 2029 | Maximum TLS certificate lifetime: 47 days | [Lifetimes](https://pkizerotohero.com/changes/#how-long-can-a-tls-certificate-be-valid) | ## How long can a TLS certificate be valid? **What changes.** The CA/Browser Forum, where certificate authorities and browser makers agree the rules for public TLS certificates, adopted CA/Browser Forum Ballot SC-081v3 in 11 April 2025. It shortens two things step by step: - the **maximum lifetime** of a certificate; - how long a CA may **reuse a domain validation**, the check that you control the name, before it must check again. | From | Maximum certificate lifetime | Domain validation can be reused for | | --- | --- | --- | | Before 15 March 2026 | 398 days | 398 days | | 15 March 2026 | 200 days | 200 days | | 15 March 2027 | 100 days | 100 days | | 15 March 2029 | 47 days | 10 days | These rules cover publicly trusted TLS certificates: the ones browsers trust for websites and APIs. Certificates from your own private CA follow your own policy. **Who is affected.** - **IT operations and platform teams:** at 47 days, every public certificate must be replaced at least eight times a year. Renewing by hand, by ticket or by calendar reminder will not keep up. - **Developers:** applications that load a certificate once at start-up, or pin a specific certificate, will break more often. Short domain-validation reuse also means your ACME client proves control of the name almost every time it renews. - **Leaders:** expiry outages become more likely unless renewal is automated, and the cost of manual work grows with every step. **What to do now.** 1. Build an inventory: every public certificate, where it is installed, who owns it and how it is renewed. 2. Automate renewal from end to end, including installing the new certificate and reloading the service. ACME is the standard protocol for this. 3. Make sure services pick up a renewed certificate without a manual restart. 4. Monitor expiry dates independently of the renewal tool, so a silent failure still raises an alarm. 5. Try the [lifetime calendar](https://pkizerotohero.com/tools/lifetime/) to see what each step means for one of your certificates. **Learn more:** [ACME and the 47-day schedule](https://pkizerotohero.com/handbook/acme/) and [Inventory, expiry and renewal](https://pkizerotohero.com/handbook/certificate-lifecycle/). ## Is OCSP going away? **What changes.** A CA can take back (revoke) a certificate before it expires, for example when its private key leaks. There are two ways to publish that news: [certificate revocation lists (CRLs)](https://pkizerotohero.com/handbook/glossary/#crl), which list revoked certificates, and [OCSP](https://pkizerotohero.com/handbook/glossary/#ocsp), where a client asks the CA about one certificate. On 15 March 2024, the rules changed: OCSP became optional and CRLs became mandatory for publicly trusted TLS certificates. Let’s Encrypt has already dropped OCSP: - Let's Encrypt stopped putting OCSP URLs in its certificates on 7 May 2025; - Let's Encrypt has shut down its OCSP service (since 6 August 2025). Very short-lived certificates may leave out revocation information altogether, because they expire before revocation would make much difference. From 15 March 2026, “short-lived” means valid for at most 7 days. **Who is affected.** - **IT operations:** OCSP stapling settings and the “OCSP Must-Staple” option no longer do anything useful for certificates without an OCSP address. Clients that do check revocation now need to reach the CA’s CRL addresses; if a firewall blocks them, checks can be slow or fail. - **Developers:** code or devices that insist on an OCSP response, or that treat a missing OCSP address as an error, need updating. - **Leaders:** little direct impact. Browser revocation checking has long been largely soft-fail, so the real protection is shorter lifetimes and good key protection. **What to do now.** 1. Find clients, appliances and libraries that require OCSP, and test them with a certificate that has no OCSP address. 2. Allow outbound access to your CA’s CRL addresses where your clients check revocation. 3. Remove Must-Staple requests from your certificate orders. **Learn more:** [Taking it back: CRLs, OCSP and stapling](https://pkizerotohero.com/handbook/revocation/). ## Why are public certificates losing client authentication? **What changes.** A certificate lists the jobs it may do in its extended key usage. Many public TLS certificates used to carry two: server authentication (a website proving who it is) and client authentication (a client proving who it is, as in [mutual TLS](https://pkizerotohero.com/handbook/glossary/#mutual-tls)). Browser root programs, led by Chrome’s, now want public TLS CAs to serve one purpose only: websites. - Chrome's root program starts phasing out root hierarchies that are not dedicated to TLS server authentication (15 June 2026). - TLS certificates that chain to the Chrome Root Store must list only the TLS server authentication purpose (for certificates issued from 15 March 2027). - Let's Encrypt certificates no longer include the TLS client authentication purpose (11 February 2026 for the default profile, and 8 July 2026 for the last opt-in profile). Other public CAs are making similar changes on their own schedules. Check your CA’s announcements. **Who is affected.** - **IT operations and developers** who use a public TLS certificate as a *client* certificate: for example a server that calls a partner’s API with mutual TLS, or a VPN or device login that accepts public certificates. When the certificate is renewed, it may arrive without the client authentication purpose, and the connection fails. - **Leaders:** partner integrations that rely on this can break at renewal time, which is easy to miss in planning. **What to do now.** 1. Search your inventory for public certificates used for client authentication. Decode them with the [certificate decoder](https://pkizerotohero.com/tools/decoder/) and look at the extended key usage. 2. Move client authentication to a private CA that you and your partners agree to trust, or to certificates issued for that purpose. 3. Agree the change with partners before your next renewal. **Learn more:** [Names and jobs: SANs, wildcards, key usage and the CA flag](https://pkizerotohero.com/handbook/names-and-key-usage/), [Both sides show ID: mutual TLS](https://pkizerotohero.com/handbook/mutual-tls/) and [A CA of your own](https://pkizerotohero.com/handbook/private-ca/). ## What has changed at Let’s Encrypt? Let’s Encrypt is a free certificate authority used by a large share of websites, so its changes reach many teams at once. Besides ending OCSP and client authentication (above), four changes matter: - **No more expiry emails.** Let's Encrypt no longer sends expiration reminder emails (since 4 June 2025). If those emails were your only warning, you have no warning now. - **Six-day certificates.** Since 15 January 2026, Let’s Encrypt has offered six-day certificates as an option, and certificates for IP addresses as well. - **Shorter default lifetimes.** The default lifetime is 90 days today. Let’s Encrypt’s published schedule: 45-day certificates in its opt-in tlsserver profile from 13 May 2026, a default of 64 days from 10 February 2027, and 45 days from 16 February 2028. - **Shorter validation reuse.** From 16 February 2028, a domain validation can be reused for only 7 hours, so almost every renewal proves control of the name again. **Who is affected.** Anyone who uses Let’s Encrypt certificates. **IT operations** feel it first; **developers** who wrote their own renewal scripts with a fixed schedule (for example “renew every 60 days”) will see those scripts fail. **What to do now.** 1. Set up your own expiry monitoring, separate from the renewal tool. 2. Do not hard-code a renewal interval. Let your ACME client decide, ideally using ACME Renewal Information (ARI), which lets the CA tell clients when to renew. See the [Let’s Encrypt documentation on lifetimes](https://letsencrypt.org/docs/cert-lifetimes/). 3. Check that DNS or HTTP validation works without human help every time. **Learn more:** [ACME and the 47-day schedule](https://pkizerotohero.com/handbook/acme/). ## What about post-quantum cryptography? **What changes.** A large enough quantum computer could break today’s public-key algorithms, RSA and elliptic-curve cryptography. Nobody has such a machine today, and nobody can say for sure when one will exist. But data recorded now could be decrypted later (“harvest now, decrypt later”), and replacing algorithms across an organisation takes years. So the work has started: - **New standards.** NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on 13 August 2024. ML-KEM is for agreeing keys; ML-DSA and SLH-DSA are for signatures. - **Browsers already use it.** X25519MLKEM768 hybrid post-quantum key exchange is on by default in Chrome, Firefox and Apple's operating systems (late 2024 in Chrome 131 and Firefox 132). “Hybrid” means a classical and a post-quantum method are combined, so the connection stays safe as long as either one holds. - **Certificates come later.** Publicly trusted TLS certificates still use classical signatures such as RSA and ECDSA; post-quantum signatures are not yet allowed in them. Post-quantum signatures are much larger, and the web is still working out how to carry them. - **Government timelines.** NIST proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing all of them after 2035 (NIST IR 8547 (initial public draft, November 2024)). In the EU, a coordinated roadmap (23 June 2025) says EU member states should start the transition by the end of 2026, finish it for high-risk use cases by the end of 2030 and complete as much as feasible by 2035. **Who is affected.** - **Leaders:** this is a multi-year migration that needs a plan and a budget line, not an emergency. Data that must stay secret for many years is the first concern. - **IT operations and security:** you need to know where you use RSA and elliptic curves: TLS, VPNs, code signing, private CAs, hardware security modules and devices. - **Developers:** keep TLS libraries current, and avoid hard-coding algorithms so they can be swapped later (“crypto agility”). **What to do now.** 1. Make a cryptography inventory: which systems use which algorithms and key sizes, and who supplies them. 2. Ask your vendors (VPN, HSM, PKI, browsers, operating systems) for their post-quantum plans and dates. 3. Keep TLS libraries and servers up to date so hybrid key exchange works where browsers already offer it. 4. For public websites there is no post-quantum certificate to buy yet. Follow the standards and your CA’s plans rather than vendor promises. **Learn more:** [Post-quantum cryptography](https://pkizerotohero.com/handbook/post-quantum/). ## Which EU rules touch PKI and cryptography? **What changes.** Several EU laws now treat cryptography and security knowledge as part of managing risk. This is a summary of what the texts say, not legal advice. Whether a law applies to your organisation, and what it asks of you, is a question for your legal and compliance advisers. - **NIS2.** The NIS2 Directive applies to essential and important entities in many sectors, through national laws, which member states had to apply from 18 October 2024. Some countries were late, so check your own country’s law. Its list of cybersecurity risk-management measures includes: - basic cyber hygiene practices and cybersecurity training (NIS2 Directive (EU) 2022/2555, Article 21(2)(g)); - policies and procedures regarding the use of cryptography and, where appropriate, encryption (NIS2 Directive (EU) 2022/2555, Article 21(2)(h)). - **DORA.** The Digital Operational Resilience Act applies to financial entities from 17 January 2025. It requires ICT security awareness programmes and digital operational resilience training (DORA Regulation (EU) 2022/2554, Article 13(6)). - **eIDAS 2.0.** Regulation (EU) 2024/1183 (eIDAS 2.0) entered into force on 20 May 2024. It introduces the European Digital Identity Wallet, which member states must offer by the end of 2026, and it sets rules on qualified certificates for website authentication and how browsers recognise them (Article 45). Both run on PKI. Read the texts on EUR-Lex: [NIS2](https://eur-lex.europa.eu/eli/dir/2022/2555/oj), [DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) and [eIDAS 2.0](https://eur-lex.europa.eu/eli/reg/2024/1183/oj). **Who is affected.** - **Leaders, risk and compliance:** a cryptography policy and a certificate inventory can serve as concrete evidence for the “cryptography” measure, and staff who understand certificates can be part of the “training” measure. - **IT operations and security:** you are the people who make the policy real: key protection, renewal, algorithm choices and the inventory. - **Developers:** wallet and qualified-certificate projects bring signatures and certificate checks into ordinary applications. **What to do now.** 1. Check with your compliance team whether NIS2 or DORA applies to you, and how your country has implemented NIS2. 2. If you have no written cryptography policy, start one: approved algorithms and key sizes, who may issue certificates, how keys are protected, how renewal and revocation work, and how you will move to post-quantum algorithms. 3. Give the people who run certificates real training, and keep a record of it. **Learn more:** [PKI for leaders in 10 minutes](https://pkizerotohero.com/leaders/), [Inventory, expiry and renewal](https://pkizerotohero.com/handbook/certificate-lifecycle/) and [Guarding the keys: HSMs and key ceremonies](https://pkizerotohero.com/handbook/hsm-and-key-ceremonies/). ## Also on the radar - **Old roots are being retired.** Chrome’s root program removes roots whose keys are older than 15 years, phased in from 15 April 2026. Your CA handles the move to newer roots, but old devices that do not know the newer roots can stop trusting your site. It has happened before: on 30 September 2021, DST Root CA X3, the older root that had cross-signed Let's Encrypt, expired, so devices that did not trust ISRG Root X1 began rejecting Let's Encrypt certificates. Read [Two roads to the same root](https://pkizerotohero.com/handbook/cross-signing/). - **Certificate Transparency stays mandatory.** Chrome requires Certificate Transparency for publicly trusted TLS certificates (since April 2018). Monitoring the public logs for your own domains is a cheap way to spot certificates you did not order. Read [Certificate Transparency](https://pkizerotohero.com/handbook/certificate-transparency/). ## What should I do first? If you only do three things this quarter: 1. **Know what you have.** An inventory of every certificate, its owner and its expiry date. 2. **Automate renewal end to end,** and monitor expiry separately. 3. **Write down your cryptography choices,** so the post-quantum move has a starting point. Then go deeper: - **New to all of this?** Take the [crash course](https://pkizerotohero.com/course/): short lessons, no account needed. - **Running servers?** Read [Inventory, expiry and renewal](https://pkizerotohero.com/handbook/certificate-lifecycle/) and [ACME and the 47-day schedule](https://pkizerotohero.com/handbook/acme/), and try the [lifetime calendar](https://pkizerotohero.com/tools/lifetime/). - **Leading a team?** Read [PKI for leaders in 10 minutes](https://pkizerotohero.com/leaders/). - **Want the history?** The [timeline](https://pkizerotohero.com/handbook/timeline/) and the [standards index](https://pkizerotohero.com/handbook/standards/) list the sources. ## Where do these facts come from? Every date and number on this page links back to a primary source: the CA/Browser Forum’s ballots and [Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/), the [Chrome Root Program policy](https://googlechrome.github.io/chromerootprogram/), [Let’s Encrypt’s announcements](https://letsencrypt.org/blog/), [NIST’s post-quantum project](https://csrc.nist.gov/projects/post-quantum-cryptography), the [EU post-quantum roadmap](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography) and EU law on EUR-Lex. We review this page every quarter.