Follow this page for useful information regarding upcoming and planned changes to TCS.
| Date | Description | Background Information | Action Required |
|---|---|---|---|
| September 2025 | Require domain validation and CAA checks to be performed from multiple Network Perspectives | ||
| 2nd March 2026 | End of all support for OCSP URLs | The end of life for OCSP and requirement for CRL for revocation information has been progressing for sometime, this date finalises the removal of this information from TCS certificates. | |
| 15th March 2026 | Certificate validity drops to 200 days | If your certificate is issued before the deadline, it can still have the current maximum validity (398 days max). However, any certificate issued on or after 15 March 2026 must follow the new 200-day rule – even if the renewal process started earlier. For Organisation Validation (OV) certificates, the reuse periods for domain and organisation validation are also shortening in line with the certificate lifetimes. That means even your validation data (like proof of domain control) must be refreshed more frequently, reinforcing the need for automation. | |
| 15th March 2026 | Enforcement of DNSSEC | CAs complying with the TLS Baseline Requirements are required to validate DNSSEC, when present, in the course of retrieving CAA records or performing DCV-related DNS lookups from Primary Network Perspectives. | |
| 6th April 2026 | End of Support for EKU | Public TLS certificates are intended solely for server authentication on the open Internet. If they also contain the ClientAuth EKU, they could be misused for purposes that public CAs cannot validate or govern (e.g., authenticating users into enterprise systems). This does not mean client authentication is going away — it means organisations must use private PKI, enterprise PKI services, or sector-specific solutions instead of public TLS certificates for mTLS. We recommend that |
TCS "IGTF Client Authentication Certificates" are used for this purpose. |