2026-10-20 · RESEARCH · The Offensive Technology team

Has the 200-day certificate rule already taken effect?

Short answer: yes, but only exactly as much as required. The CA/Browser Forum's cap on public TLS certificate validity dropped from 398 days to 200 days on 15 March 2026, seven months ago. We read the public Certificate Transparency history of 702 top domains, 1,359,618 deduplicated logged certificates from 2013 to today, and compared every certificate's validity window before and after that date. In the two years before the cutover, 75.3% of certificates were already 200 days or shorter. In the seven months since, that's 99.91%, functionally total compliance. But where each certificate authority lands under that new ceiling is the real story. Free, automated issuers, Let’s Encrypt and Google Trust Services among them, sit at a 90-day median, completely unchanged by the rule, because they were already years ahead of it. The large commercial CAs, DigiCert, Amazon, Microsoft, GlobalSign, dropped from a 324-to-397-day median straight to 198 or 199 days: the floor of what the rule now allows, not a day shorter. One of them, Sectigo, broke that pattern. Here is the full data, how we measured it, and what changes again in March 2027.

The schedule, and where we are on it

Ballot SC-081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods,” passed the CA/Browser Forum on 11 April 2025: certificate issuers voted 25-0-5 (five abstentions), and the browser group, Apple, Google, Microsoft, and Mozilla, voted 4-0-0 in favor. Apple proposed it. It sets a stepped reduction in the maximum validity period for public TLS certificates, and a parallel, steeper reduction in how long a CA can reuse a prior domain-control validation:

• Through 14 March 2026: 398 days maximum validity, 398 days validation reuse.
• 15 March 2026: 200 days maximum validity, 200 days validation reuse. This step has already happened.
• 15 March 2027: 100 days maximum validity, 100 days validation reuse.
• 15 March 2029: 47 days maximum validity, 10 days validation reuse.

As of today, the 200-day step is seven months old, the 100-day step is about five months away, and the 47-day step is roughly two and a half years out. This piece is about what the first step actually changed, not about the schedule itself: every registrar and CA knowledge base already explains the dates. We wanted to know whether issuance in the wild moved when the rule said it had to, and we had thirteen years of our own passive CT data on hand to check.

Two tiers, one deadline

Zoom out first. Across every issuer combined, the share of newly issued certificates at 200 days or shorter went from 75.3% in the two years before the cap to 99.91% in the seven months since, a close to universal snap into compliance, which is exactly what a hard Baseline Requirements deadline should produce: miss it and a browser stops trusting your certificate. That part worked as designed.

Zoom in and the ecosystem splits into two groups that didn’t move the same way, or at all:

• Already there. Let’s Encrypt and Google Trust Services, the two highest-volume issuers in our sample by a wide margin, have run a 90-day default since well before this rule existed, because their issuance is free, automated, and built around frequent renewal from day one. Their post-mandate median is 90 days. Their pre-mandate median was 90 days. Apple’s own ACME-issued certificates and the newer automation-first CA Certainly show the same pattern at 86 and 30 days respectively, flat across the cutover. For this group, 15 March 2026 changed nothing, because the rule finally caught up to where they already were.
• Landed exactly at the floor. DigiCert, Amazon, Microsoft, and GlobalSign all dropped sharply, but every one of them landed at 198 or 199 days, one day under the new 200-day ceiling, not meaningfully below it. Before the cap, their typical certificate ran 180 to 397 days. After it, all four converge within a single day of the legal maximum. That is compliance with the letter of a rule that was explicitly designed to push the industry toward shorter-lived certificates, without adopting the spirit of it.

Sectigo is the one issuer in our sample that doesn’t fit either pattern cleanly. Its pre-mandate median was 366 days, squarely in the legacy camp, but its post-mandate median fell to 90.4 days, with 55.6% of its post-mandate certificates already at 90 days or less. That is a real shift toward the automated tier’s behavior, not a slide down to the new ceiling. We don’t know why from CT metadata alone; it is consistent with a change in which issuance pipeline or ACME integration Sectigo customers in our sample are now using, but we can’t confirm the mechanism.

Microsoft is worth a separate note because its number moved the wrong way on paper: a 180-day pre-mandate median ticking up to 198 days post-mandate. We read this as Microsoft having already run somewhat shorter than the old 398-day ceiling allowed, and then re-centering just under the new 200-day one, the same floor-hugging behavior as the other enterprise CAs, just starting from a slightly shorter baseline. It is not evidence that Microsoft’s certificates got less secure; validity period and security posture are not the same axis, which is also the subject of our next section.

Who, by the numbers

Every issuer above cleared the 200-day cap on essentially 100% of its post-mandate certificates in our sample; we found no Baseline Requirements violations, which is what we’d expect from root programs that actively audit for this. The finding isn’t non-compliance. It’s that compliance has two distinct shapes, and the gap between “automated, already-short” and “enterprise, now-at-the-floor” is still a factor of roughly two in actual days, 90 to 198, inside a single rule that both groups equally satisfy.

How we measured this

A skeptic should be able to rebuild this from scratch.

• The population. The same roughly 700 Tranco top-domain Certificate Transparency histories, read via crt.sh, that we reused for our CT logging-delay census and our internal-hostname-leak census. We read zero new network requests for this piece; the full dataset was already cached from prior work.
• The metric. For each deduplicated logged certificate, validity period is not_after minus not_before, rounded to the nearest whole day before bucketing, since a nominal “90-day” certificate is often 90 days plus a few hours of raw timestamp drift tied to the issuance time of day.
• The split. We bucketed certificates by whether not_before fell before or on/after 15 March 2026. For the per-issuer comparison, we used a matched two-year window immediately before the cutover (15 March 2024 to 14 March 2026) rather than all-time history, so a CA’s decade-old legacy certificates don’t drag down its “before” number unfairly.
• What we did not do. We never requested a certificate, connected to a web server, or scanned anything. Reading a public CT log is a lookup, not a probe.
• What we kept. Aggregate counts, medians, and percentiles per issuer and per period. No domain or subdomain name is in the output.

What this does not prove

Honest limits, because a number without its caveats is marketing.

• Shorter certificate validity is not the same as shorter private key lifetime. A CA or subscriber can renew a certificate on the same key pair every 90 or 200 days indefinitely; crt.sh’s basic entry metadata doesn’t expose the subject public key fingerprint, so we cannot tell from this data whether key material is actually being rotated alongside the certificate. The security benefit of shorter validity depends on that rotation happening; we did not measure it here.
• Seven months of post-mandate data is an early read. It is enough to show the shape of the initial compliance response, not to certify it as the industry’s permanent equilibrium under a 200-day cap. We plan to re-check this at the next step, in March 2027.
• Not every issuer has a reliable before-and-after picture. A number of CAs in our cache, including GoDaddy and several smaller or regional issuers, had a post-mandate sample too thin in our specific 700-domain panel to report confidently; we only tabled issuers with a real sample on both sides.
• The population skews toward high-traffic domains. Tranco’s top tier leans on well-resourced organizations and major CDNs. Issuance behavior for the long tail of smaller sites, often behind the same large CAs through different automation, may differ.
• This measures certificate authorities, not attacker risk directly. A shorter cap shrinks the maximum window a certificate stays valid if something goes wrong with it, but only as one input into a larger chain that includes revocation, key hygiene, and monitoring.

Why this matters

The entire argument for shrinking certificate lifetimes is exposure window: a leaked or misissued certificate that would have run for 398 days under the old rule now runs for, at most, 200, and will run for at most 100, then 47, as the schedule continues. That argument only pays off if the ecosystem actually moves toward the shorter end, not just under whatever ceiling is currently legal. Seven months in, the data says both things are true at once. The rule did its job as a hard floor: compliance went from three-quarters to effectively all of it, overnight by industry standards. But most of the volume that moved only moved as far as the new floor required, landing within a day of 200 rather than anywhere near 90. The issuers already running short, the ones whose business model depends on cheap, frequent, automated renewal, were unaffected, because they built for this years before a Forum ballot made it mandatory. That is the same pattern we found when we looked at how fast certificates get logged to CT: the parts of this ecosystem under real enforcement move exactly as fast as enforcement requires, no faster.

Has the 200-day certificate rule taken effect: quick answers

When did the 200-day certificate rule start?

15 March 2026, under CA/Browser Forum ballot SC-081v3, which passed 11 April 2025. It cut maximum public TLS certificate validity from 398 to 200 days. The next cut, to 100 days, lands 15 March 2027; a final cut to 47 days lands 15 March 2029.

Do existing certificates need to be reissued under the new limit?

No. The cap applies only to certificates issued on or after the effective date. A certificate issued under the old 398-day rule keeps running on its original schedule.

Will the domain validation reuse period also get shorter?

Yes, on the same schedule: 398 to 200 days alongside the March 2026 step, then 100 days in March 2027 and 10 days by March 2029, forcing more frequent reverification of domain control independent of certificate validity itself.

When does the 47-day certificate rule take effect?

15 March 2029, the final step of the SC-081v3 schedule: 398 days until 14 March 2026, 200 days from 15 March 2026, 100 days from 15 March 2027, 47 days from 15 March 2029.

How was this measured?

Passively. We read the public CT history, via crt.sh, of roughly 700 Tranco top-1,000 domains, computing each certificate's validity period as NotAfter minus NotBefore. No host was contacted, resolved, or scanned. The result is 1,359,618 deduplicated log entries from 2013 to October 2026.

Related reading

• Certificate Transparency log delay: what 1.3M certs show.
• How Certificate Transparency logs leak internal subdomains.
• What the certs prove.