EV Domain Validation Reuse: The 398-Day Number Is Gone

What ballot SC102 actually changed

SC102 edited three places in the EV Guidelines, and every edit deletes something rather than adds it. The Domain Name entry in section 3.2.2.14.3 lost its hardcoded 398-day reuse period and now refers to section 4.2.1 of the Baseline Requirements. Section 3.2.2.14.1(6) lost its WHOIS and RDAP same-registrant re-check. Section 6.3.2 stopped stating an EV validity limit and defers to the Baseline Requirements as well.

The Server Certificate Working Group passed it unanimously, 19 votes to zero among certificate issuers and 2 to zero among browser vendors, and the 30-day intellectual property review that follows every CA/Browser Forum ballot closed on August 13, 2026. A ballot that only removes text is easy to skim past, and this one carried no compliance deadline to force anyone to read it.

What makes it worth reading is the direction of the change. Before SC102, the EV Guidelines held their own copy of a number that the Baseline Requirements had started moving on a schedule. A copy of a moving number goes stale by definition, and this one did. Replacing it with a reference means the next two steps in that schedule reach EV automatically.

Why 398 days stopped applying in March 2026

The EV Guidelines are written as a supplement to the Baseline Requirements, not as a replacement for them, and the Baseline Requirements apply to EV certificates as well. Where the two documents set different limits on the same thing, a certificate authority has to satisfy both, which in practice means the stricter limit governs. Ballot SC-081v3 cut domain validation reuse to 200 days for certificates issued on or after March 15, 2026, and from that date the 200 was the operative number for EV even though the EV text still read 398.

So between March and July 2026 the EV rulebook and the rule a CA enforced disagreed, in a document that procurement teams and auditors read literally. That is the gap SC102 closed. Nobody had to change a validation pipeline on July 14 because the pipelines were already on 200 days.

The number outlived the rule in one place that matters, though: written material produced before March 2026. Vendor knowledge-base pages, internal runbooks, renewal checklists and procurement templates that quote 398 days for EV domain validation are not describing a stricter-than-required practice. They are simply wrong now, and the way it surfaces is a renewal that asks for a fresh DNS record or HTTP token when someone expected last year's check to still count.

Which clock covers domains, which covers you

An EV order runs on two independent reuse clocks. Domain and IP validation, which proves you control each name in the certificate, follows Baseline Requirements section 4.2.1 and currently allows evidence up to 200 days old. The organization items in EV Guidelines section 3.2.2.14.3 — legal existence, registered address, verified method of communication, and the authority of the people who request and approve the certificate — still cap out at 398 days.

Both clocks start when the certificate authority collected the evidence, not when you ordered and not when the certificate was issued. That is easy to forget for the domain clock in particular, because a DNS record you published for an order in January has been ageing ever since, whatever you do with the certificate it produced. The organization side of this, including what a re-verification actually involves, is covered in our article on the 398-day clock on your company data.

One practical consequence of the split: an EV renewal can stall on either clock independently, and the fixes are nothing alike. A stale domain check needs a DNS record or an HTTP file and takes minutes. Stale organization data needs registry lookups, a call to a verified number, and sometimes a signed document. If you buy EV SSL certificates from us, both validations sit with Certum, the publicly trusted CA that issues them from its own roots, rather than being split across an intermediary.

Is the WHOIS registrant re-check gone?

Yes, as an EV-specific step. Before SC102, the domain reuse path in EV Guidelines section 3.2.2.14.1(6) asked the certificate authority to confirm through WHOIS or RDAP that the domain was still registered to the same registrant before it reused an earlier validation. That requirement is gone. EV domain re-validation now runs through the ordinary Baseline Requirements methods in section 3.2.2.7, the same ones behind a DV order, with no extra registrant lookup layered on top.

Removing a check sounds like a weakening, so it is worth being precise about what the check was doing. It compared a registrant record against an earlier one. Registrar redaction has made that comparison thin for years: many WHOIS and RDAP responses now return a privacy-service placeholder rather than the registrant, so the values being compared were often two copies of the same redaction notice.

The substantive protection against a domain changing hands is the reuse window itself, and it is shrinking fast. A registrant re-check mattered more when validation could be 398 days old than it does at 200 days, and it will matter less again at 10 days, when the CA re-proves control from scratch for practically every issuance.

Did EV certificate validity change too?

Not in practice. Maximum certificate validity comes from section 6.3.2 of the Baseline Requirements, which caps certificates issued on or after March 15, 2026 at 200 days regardless of validation level. EV Guidelines section 6.3.2 restated the limit separately, and that duplicate is what SC102 replaced with a reference. The limit a certificate authority enforces is unchanged; only the place you read it moved.

This is worth stating plainly because the EV Guidelines carried their own validity ceiling for years, and a separate number in a separate document invites the assumption that EV runs on a separate schedule. It does not. An EV certificate issued today expires on the same schedule as a DV certificate issued the same day.

What happens in 2027 and 2029

EV inherits the Baseline Requirements schedule automatically now, with no further EV ballot needed. Maximum certificate validity falls to 100 days on March 15, 2027 and 47 days on March 15, 2029. Domain and IP validation reuse falls to 100 days on that same 2027 date, then to 10 days on March 15, 2029 — a far steeper cut than the certificate lifetime beside it.

The 47-day figure gets the headlines, and it is the wrong number to plan around. Watch the ratio instead. Today, and again after March 2027, the certificate lifetime and the maximum age of the domain check are the same, so a validation performed for one certificate can still be within its window when the replacement is issued. One check, one certificate.

From March 2029 that stops working. A 47-day certificate replaced on schedule needs domain validation that is at most 10 days old, so evidence gathered for the previous issuance is always stale by the time the next one comes around. Every issuance needs its own fresh proof of control. That is the step that removes the last place a manual DNS edit could hide, and it is the reason the 10-day number deserves more attention than the 47-day one.

What to change in your EV planning

Two things: correct the number wherever it is written down, and stop treating the domain check as an annual event. Beyond that, the useful change is in what you track. Most certificate inventories record when each certificate expires. Very few record when each domain was last validated, and after March 2026 those are two different dates that drift apart.

• Grep your runbooks for 398. Renewal checklists and procurement templates written before March 2026 carry a number that no longer applies to domain validation. The organization-data references to 398 days are still correct, so fix the domain ones and leave the rest.
• Keep validation reachable, not just openable. A DNS provider you can automate against, or a permanently writable /.well-known/ path, beats a change request you file twice a year. At 10-day reuse, opening a window per renewal stops being viable.
• Track the validation date per name. For a multi-domain EV certificate, each name in the SAN list has its own validation age. Adding a name to an existing certificate needs that name validated now, whatever the certificate's other names were validated at.
• Keep the two clocks separate in your calendar. Organization re-verification is the slow one that involves third parties and can add days nobody controls. Domain re-validation is the fast one, and it is now the one that comes round more often.
• Do not expect an EV exception again. The EV Guidelines now point at the Baseline Requirements for both of these numbers, so EV will follow each future step without a separate announcement to read.