4 March 15 Changes Flying Under the Radar

Everyone's focused on 200-day certificates. Four other CA/B Forum requirements take effect the same day — and most teams aren't tracking any of them.

Everyone's focused on 200-day (actually 199 days) certificates on March 15. That change is real, it's significant, and it absolutely deserves attention.

But it's not the only thing changing on March 15.

Four other CA/B Forum requirements take effect the same day — and most teams aren't tracking any of them. Each one has the potential to quietly break a workflow that nobody thought to test.

Here's what's flying under the radar.

1. DCV Reuse Drops to 200 Days (Was 398)

What changed: Domain Control Validation data — the proof that you control a domain — used to be reusable for 398 days. After March 15, that window drops to 200 days.

Why it matters: This isn't the same thing as certificate validity. Even if you're already planning for shorter cert lifetimes, your DCV reuse window has now been cut nearly in half independently.

If your organization validates domains on a schedule that was designed around 398-day reuse, that schedule is now wrong. Validation data you collect today is only reusable for 200 days — not 398.

What to check:

• How often does your CA (or your automation tooling) re-validate domain control?
• If you're managing certificates manually or on a long cycle, your next renewal may hit an expired DCV window before you expect it.
• For high-volume issuance environments, this effectively doubles the frequency of DCV operations required.

2. OV/EV Org Validation Reuse Drops to 398 Days (Was 825)

What changed: For Organization Validated (OV) and Extended Validated (EV) certificates, the Subject Identity Information (SII) — the company name, address, jurisdiction, and other organizational data — used to be reusable for 825 days. After March 15, that drops to 398 days.

Why it matters: 825 days is over two years. A lot of OV/EV certificate programs were set up with the assumption that organizational identity data was a "validate once, reuse for a while" problem. That assumption is now invalid.

398 days means re-validating org identity annually, with a small buffer. For enterprises with many OV or EV certificates across multiple entities, subsidiaries, or domains, this increases the operational burden on the validation process significantly.

What to check:

• When was your organizational identity last validated with your CA?
• If it was validated more than 398 days ago, you'll need fresh validation before your CA can issue new OV or EV certificates.
• For companies that recently rebranded, merged, or changed addresses: this is a good forcing function to make sure your CA has accurate current data.

3. Short-Lived Certificate Threshold Drops to 7 Days (Was 10)

What changed: Certificates with a validity period of 10 days or less previously qualified for an OCSP/CRL exemption — meaning the CA wasn't required to provide revocation information for them. After March 15, that threshold drops to 7 days.

Why it matters: If you're issuing short-lived certificates specifically to take advantage of the revocation exemption, and you were issuing them at 8, 9, or 10 days of validity — you've just lost that exemption.

Certificates at those durations now require OCSP or CRL coverage just like any other certificate.

What to check:

• Are you issuing any certificates in the 8–10 day range?
• If so, check with your CA whether they'll still issue at that validity period, and what their OCSP/CRL support looks like for those certs.
• If your use case was specifically designed around the exemption, you may need to drop to 7 days or below — or revisit the architecture entirely.

This change is narrow in scope but will catch teams who engineered specifically to the previous 10-day boundary.

4. DNSSEC Validation Now Required for All DCV and CAA Lookups

What changed: CAs are now required to validate the DNSSEC chain all the way back to the IANA root trust anchor for every domain validation check and every CAA record lookup. Previously, DNSSEC validation was recommended but not uniformly required.

Why it matters: If your domain's DNSSEC configuration has any issues — broken chain, expired signatures, misconfigured DS records — certificate issuance may fail. Without warning. Right when you need to renew.

This doesn't affect domains that don't use DNSSEC at all (the CA validates what it can). But for domains where DNSSEC is partially configured or in a degraded state, this requirement can result in unexpected issuance failures.

What to check:

• Does your domain use DNSSEC? Check with your DNS provider or run a DNSSEC validation test.
• If DNSSEC is enabled, when were your zone signatures last verified? DNSSEC signatures have expiry dates.
• If you manage DNS in-house, check that your DS records at the parent zone are current and correct.
• Check your DNS provider's DNSSEC support status — not all providers handle DNSSEC renewal automatically.

The Bigger Picture

The 200-day cert limit is getting all the attention because it's the most visible change — it affects every TLS certificate issuer and every organization managing certificate renewals. But the four changes above will quietly break workflows that nobody thought to test.

They share a pattern: each one tightens a window that teams built operational processes around, assuming those windows were stable. DCV reuse. Org identity reuse. Short-lived cert thresholds. DNSSEC enforcement. All of them move on the same date.

March 15 isn't one change. It's five.

Full Compliance Timeline

Want the complete picture of every deadline in effect and what's coming next?

The FixMyCert Compliance Hub tracks CA/B Forum requirements, Chrome Root Program deadlines, Mozilla Root Store policies, and more — all in one place.

View the Compliance Hub →

Based on CA/B Forum Baseline Requirements SC-081v3. All deadlines and requirements referenced are effective March 15, 2026.