Significant changes to the rules governing public TLS certificates are already underway and will continue through 2029. Some updates took effect in February 2026, with additional industry-wide requirements in March and beyond.

The changes originate from the CA/Browser Forum and browser root programs, led by Google Chrome. They affect certificate lifetimes, validation reuse periods, DNSSEC enforcement, multi-perspective issuance corroboration (MPIC), and client authentication use cases. 

Because these updates roll out in stages, planning is critical. Below is a timeline of what’s already in effect, what happens next, and what it means for organizations that rely on public TLS certificates. 

Changes already in effect (February–early March 2026)

Several important changes are already live.

February 24, 2026: Shorter validity and reuse

DigiCert no longer accepts public TLS certificate requests with validity greater than 199 days. Certificates issued on or after February 24, 2026, cannot exceed 199 days.

Validation reuse periods were also reduced:

• Domain Control Validation (DCV): 199 days

• Organization Validation (OV): 397 days

Renewal planning must now align to the shorter lifecycle.

February 24, 2026: DNSSEC validation enforced (if present)

DigiCert now validates DNSSEC, when configured, during domain control verification and DNS Certification Authority Authorization (CAA) checks.

DNSSEC is not mandatory. However, if DNSSEC is enabled, misconfigured DNSSEC can now block certificate issuance.

March 3, 2026: Enhanced MPIC enforcement

DigiCert updated its MPIC process to use at least three remote network perspectives across at least two Regional Internet Registry (RIR) regions.

Globally inconsistent DNS or HTTP responses may now surface during validation, increasing the importance of globally stable configurations. Depending on how you perform DCV, you may need to adjust your network configuration to avoid certificate issuance issues under MPIC. Read this knowledge base article for implementation details.

March 15, 2026: Industry-wide enforcement

On March 15, 2026, CA/Browser Forum requirements take effect across all public TLS certificates.

Validation method changes:

• CAs may no longer use the IP address method validate control of a domain.

• Certificates may not contain domain names ending in an IP reverse zone suffix.

• Precertificate Signing CAs may no longer be used to issue precertificates.

DNSSEC enforcement:

• DNSSEC validation must be performed back to the IANA DNSSEC root trust anchor for required DNS queries.

• DNSSEC validation errors (e.g., SERVFAIL) must not be treated as authorization to issue.

• Local policy may not disable DNSSEC validation for domain authorization or control checks.

MPIC requirement:

• CAs must implement MPIC using at least three remote network perspectives spanning at least two RIR regions.

Certificate lifetime and reuse limits:

• Maximum TLS certificate validity: 200 days

• Domain and IP validation reuse: 200 days

• Subject identity information reuse: 398 days

These limits apply ecosystem-wide. These limits apply ecosystem-wide. As detailed above, DigiCert enforced the changes earlier (February 24) to ensure all systems are fully aligned and stable ahead of March 15 and to prevent any risk of issuing certificates that exceed the CA/B Forum's new 200-day limit. We also set our validity limits to one day below the CA/Browser Forum maximums to ensure continuous compliance.

2026: Phasing out client authentication in WebPKI TLS

Public TLS certificates are transitioning to server authentication-only use. Client authentication (mTLS) is being removed from WebPKI in phases, primarily through Chrome’s root program.

Organizations using public TLS certificates for API authentication or machine-to-machine communication should review those use cases carefully.

May 1, 2026: DigiCert stops issuing ClientAuth EKU

• DigiCert will no longer issue public TLS certificates containing the ClientAuth EKU. New certificates will include server authentication EKU only. [DigiCert rule]

May 15, 2026: ICA revocations under G2/G3 hierarchies

• DigiCert will revoke intermediate CA (ICA) certificates, along with all associated end-entity certificates, that chain up to the DigiCert Global Root G2 and DigiCert Global Root G3 root hierarchies. The Chrome Root Program intends to distrust these and all roots that support certificates for any purpose other than server authentication. [Early implementation of Chrome’s June 15 distrust]

June 15, 2026: Chrome distrusts intermediates with ClientAuth EKU

• Chrome will no longer trust intermediate TLS certificate authorities containing the client authentication EKU. [Chrome Root Program rule]

• Certificate authorities must implement MPIC using at least four remote network perspectives. The corroborating networks must fall within at least two RIR regions. [CA/B Forum rule]

August 28, 2026: ClientAuth purchases will fail in 2027

• Certificates purchased on or after this date with the ClientAuth EKU will fail for client authentication on March 15, 2027, even if they haven’t expired.

September 11, 2026: First 199-day certificates expire

• Certificates issued under the February 24, 2026, 199-day maximum validity will begin to expire.

December 15, 2026: MPIC expands further

• Certificate authorities must implement MPIC using at least five remote network perspectives spanning at least two RIR regions. [CA/B Forum rule] [Chrome Root Program rule]

March 15, 2027: 100-day certificates and DCV removals

Another major contraction occurs in March 2027.

Domain and IP validation methods removed:

• Several validation methods will be deprecated, including:

• Phone-based domain validation methods

• Email, fax, SMS, or postal mail to IP address contact

• Reverse address lookup for IP validation

• Phone contact with IP address contact

Organizations relying on legacy or manual validation workflows should transition before this deadline.

Lifetime reduction phase two:

• Maximum TLS certificate validity:100 days

• Domain and IP validation reuse:100 days

• DigiCert will set our maximum validity period to 99 days. We have not announced the date this change will take effect. We set our validity limits to one day below the CA/Browser Forum maximums to ensure continuous compliance.

Chrome change: ClientAuth distrust

• Chrome will no longer trust TLS end-entity certificates containing the client authentication EKU. [Chrome Root Program rule]

Early June, 2027: First 100-day certificates expire

The first certificates issued under the 100-day maximum will begin to expire. Renewal cadence now resembles a quarterly cycle.

March 15, 2028: Email-based DCV methods removed

The CA/Browser Forum will prohibit several email-based validation methods:

• Constructed email to domain contact

• Email to DNS CAA contact

• Email to DNS TXT contact

Automated DNS- or HTTP-based validation methods should be fully operational well before this change.

March 15, 2029: 47-day certificates

The final scheduled reduction dramatically shortens certificate lifetimes:

• Maximum TLS certificate validity: 47 days
• Domain and IP validation reuse: 10 days
• DigiCert will set our maximum validity period to 46 days. We have not announced the date this change will take effect. We set our validity limits to one day below the CA/Browser Forum maximums to ensure continuous compliance.

At this stage, certificate management becomes a continuous operational process. Manual workflows will not scale to this cadence.

What these changes mean for organizations

Taken together, shorter certificate lifetimes, stricter validation rules, expanded MPIC requirements, and root program changes reshape how organizations manage trust. The effect isn’t limited to certificate issuance—it touches compatibility planning, renewal workflows, DNS configuration, and automation strategy.

Here’s where most organizations will feel the impact.

Trust and compatibility risks

Browser root programs periodically update their trust policies, including which roots and intermediates remain trusted. When roots are removed or usage is restricted, trust chains break in ways that cause hard browser failures. Instead of a warning banner, users may see a “certificate not trusted” error that prevents access entirely.

Organizations may need to migrate to supported roots and intermediates and pay closer attention to certificate chain selection. Compatibility planning must also reflect your actual client mix—older devices, embedded systems, and long-lived enterprise software don’t behave like modern Chrome, so testing across real-world environments is critical to avoid unexpected outages.

Root and intermediate transitions aren’t theoretical events. Being prepared requires inventory visibility, coordinated deployment, and validation before changes reach production.

Issuance and renewal reliability

New CA/B Forum requirements—including stricter multi-perspective issuance corroboration (MPIC) and shorter validation reuse windows—raise the bar for certificate validation.

DNS or HTTP responses that vary by geography due to CDNs, Anycast routing, or split DNS can cause validation checks to fail. When certificate authorities (CAs) validate from multiple network perspectives, inconsistent responses may delay issuance or block renewal.

While MPIC is operationally a CA responsibility, its effects are shared. Organizations need globally consistent DNS responses, reliable reachability, and sufficient renewal buffer time to avoid disruption.

Operational pressure from shorter lifecycles

TLS certificate lifetimes are shrinking from annual renewals to sub-100-day windows—and eventually to 47 days. That compression materially changes how certificate management must operate.

Shorter validity periods mean more frequent renewals, more deployments, and less time to troubleshoot when something breaks. Validation reuse periods are shrinking as well, which increases the cadence of domain and identity checks.

Manual processes that worked in a 398-day world won’t scale to a 47-day lifecycle. Visibility, automation, and clearly defined ownership become foundational, not optional.

What your organization should do now

If you rely on public TLS certificates, planning can’t wait. Start taking these steps now:

• Audit certificate lifetimes and renewal assumptions across all environments. 

• Confirm you’re not dependent on deprecated DCV methods.

• Review any use of public TLS certificates for client authentication or mTLS. 

• Validate DNS consistency globally, especially if using CDNs, Anycast, or split DNS.

• Build renewal buffer time into automation to account for stricter validation. 

• Assess whether your certificate management processes can operate at a 47-day cadence.

TLS certificate management is shifting from periodic administration to continuous operations. The timeline is already in motion. Organizations that adapt early—with automation, visibility, and disciplined processes—will absorb these changes with minimal disruption. 

Explore DigiCert’s certificate lifecycle management solutions to see how modern CLM helps teams maintain visibility, automate renewals, and reduce disruption as requirements tighten.