The short answer
Under section 4.2.1 of the CA/Browser Forum Baseline Requirements, a certificate authority may reuse the organization data it validated about you — legal existence, registered address, verified method of communication, signing authority — for a maximum of 398 days. Certificates issued before March 15, 2026 could rely on validation up to 825 days old, so an OV buyer went from re-verifying the company roughly once every 27 months to roughly once a year. EV never had the longer allowance: the EV Guidelines have capped every validated data item at 398 days all along, which is why EV customers noticed nothing on the changeover date. As of August 2026 that 398 is not scheduled to fall again, even as certificate lifetimes drop to 100 days in 2027 and 47 days in 2029.
If you are pricing a certificate that carries your company name, the annual re-verification is now part of what you are buying rather than a rare event. Organization validated certificates from My-SSL are issued by Certum, and the reuse rule below is what keeps the second year lighter than the first: within the 398 days, the CA reissues against organization evidence it has already validated instead of asking for it again.
What changed on March 15, 2026
One number in the Baseline Requirements moved: the maximum age of the organization data a CA may lean on when it issues your certificate. For certificates issued before March 15, 2026 that ceiling was 825 days. For certificates issued on or after it, the ceiling is 398 days. Nothing else about OV validation changed — same evidence, same sources, same checks, just a shorter shelf life.
The change arrived inside Ballot SC-081v3, which is far better known for something else. That ballot is the one that set the road to 47-day certificates, and almost every article written about it charts the validity column. The reuse columns sat in the same tables and got a fraction of the attention, which is how a change to the one step nobody can automate ended up as a footnote.
It matters because 825 days and 398 days are different kinds of event. At 825 days, re-verification landed on a given company about once every two and a bit years, often past the tenure of whoever handled it last time. At 398 days it lands inside every annual cycle. The task became routine, and routine tasks need an owner.
Two clocks, running at different speeds
An OV or EV certificate rests on two validations with two expiry rules. Domain control validation proves you control the names in the certificate, and since March 15, 2026 that evidence may be reused for 200 days. Organization validation proves the company in the subject field is real, and its evidence lasts 398 days. Whichever clock runs out first stalls your next issuance.
Today the domain clock is the shorter one, which hides the organization clock from view for most people. That reverses in March 2027, when domain data drops to 100 days and organization data stays at 398. From then on your CA re-runs domain validation roughly four times for every one time it re-runs the company checks, and the two events stop lining up in any tidy way.
The practical read: treat them as separate calendar items owned by different people. Domain validation belongs to whoever runs the DNS or the web server, and it can be handed to software. Organization validation belongs to whoever can answer a verification call and produce a registry document, which is usually someone in finance or legal who has never heard of ACME. Our guide to the 2026 domain validation changes covers the other clock in detail, including the validation methods being retired.
Why EV buyers saw nothing change
EV has run on a 398-day clock since long before this ballot. Section 3.2.2.14.3 of the EV Guidelines, headed Age of Validated Data, caps every item at 398 days: legal existence and identity, assumed name, registered address, verified method of communication, operational existence, domain name, and signing authority. March 15, 2026 did not touch that list. It brought OV down to meet it.
That reframes a question buyers ask constantly. The usual objection to EV is that it costs more and the browser no longer shows anything for it, so the extra vetting looks like pure overhead. Part of that overhead has now been charged to OV anyway. If your reason for choosing OV was a lighter administrative load, the gap narrowed considerably in March.
The vetting depth is still genuinely different — EV adds operational existence and a verified approval chain that OV does not require — so this is a reason to re-run the comparison, not to assume the answer flipped. If you are weighing the two, our OV versus EV breakdown sets out what each level actually verifies, and our EV certificate range lists what the issuing process asks for.
What exactly does a CA re-verify?
For OV, two things: the organization itself and the authority behind the request. Baseline Requirements section 3.2.2.1 requires the CA to verify the identity and address of the organization, and to confirm that the address is where the applicant exists or operates. Section 3.2.5 requires the CA to use a reliable method of communication to confirm that the person who filed the request was entitled to.
The evidence has to come from one of four places, and the list is short on purpose:
- A government agency in the jurisdiction where the company was legally created or is recognised.
- A third-party database that is periodically updated and qualifies as a reliable data source.
- A site visit by the CA or an agent acting for it.
- An attestation letter.
Address alone has a softer route — a utility bill, bank statement, credit card statement or government tax document can confirm where you are, though not who you are. A trading name in the certificate adds its own check under section 3.2.2.2.
None of this is new work. It is the same validation you passed the first time, run again against sources that may have moved on since. That is where the delays come from: not the CA being slow, but a registry showing your old address, or a phone number that stopped appearing in the directory the CA checks. Our breakdown of SSL validation timelines walks through what each stage typically costs in hours or days.
Why the gap widens every year
Because one number is frozen and the other is not. The Subject Identity Information reuse table in section 4.2.1 has two rows and stops: 825 days before March 15, 2026, then 398 days. There is no third row. Maximum certificate validity, meanwhile, falls to 100 days in March 2027 and 47 days in March 2029, and domain validation reuse follows it down to 10 days.
Divide one by the other and you get the number that actually shapes your risk. A 398-day organization validation currently spans about two certificate lifetimes. In 2027 it spans four. In 2029 it spans eight.
Read from the automation side, this is a growing single point of failure. Every one of those certificate cycles can be scripted end to end, and the whole sequence still depends on one manual checkpoint that fires once a year. When the checkpoint slips, it does not slow one renewal down; it stops the queue. Eight blocked issuances in 2029 is a different incident from two blocked issuances today, even though the underlying mistake is identical.
The step automation cannot cover
An ACME challenge proves one thing: that whoever holds the account can publish a value in your DNS or serve it from your web server. It has no way to establish that a company is registered at an address, or that the person requesting the certificate is authorised to. The evidence for that lives in registries and phone calls, not in the DNS.
Chrome Root Program Policy is unusually direct about this. It requires every CA in the Chrome Root Store to offer automated issuance and renewal for every certificate profile by March 15, 2027 — OV and EV included — and then carves out the human input needed for identity and business document verification. The certificate operations get automated. The vetting wrapped inside them does not.
So the end state, once the 2027 rules land, is an OV pipeline that issues without anyone touching it for 398 days at a stretch, then requires a person for one step, then goes quiet again. That shape is easy to build and easy to forget about, which is the whole problem. We covered the mandate itself in the March 2027 CA automation requirement.
Keeping the clock from stalling an order
The failure mode is always the same: an order arrives, the stored evidence has aged past 398 days, and the CA restarts checks that depend on a government registry or a phone call you cannot hurry. Preventing it is a scheduling problem rather than a technical one, and four habits cover almost all of it. The first is the one most people get wrong.
- Record the collection date, not the issue date. The EV Guidelines are explicit that the 398 days start when the CA collected the information. Evidence gathered three weeks before your certificate was issued expires three weeks earlier than a naive calculation from the issue date suggests. Ask your CA for the validation date and diary from that.
- Tell the CA when the company changes. A new registered address, a renamed entity, a restructure, or a departed signatory all invalidate stored evidence before its time. Flagging it during a quiet period costs a form. Finding out during an outage costs the outage.
- Keep the verified phone route alive. Confirming authority depends on a reliable method of communication the CA can find independently. A switchboard that no longer appears in the source the CA uses is the single most common reason a straightforward re-verification stretches into days.
- Start renewals 30 days out, not 7. With 200-day certificates you now have two renewal windows a year, and roughly one of them will collide with the organization re-check. Thirty days absorbs a registry lag; a week does not.
Where you buy affects how much of this you feel. A CA that keeps a validated organization profile on your account can re-run the checks against what it already holds and reissue against the same record; a reseller that treats each order as a fresh application makes you assemble the evidence again. Our OV certificates are issued by Certum directly, so the validated organization record stays with the CA that issues the certificate.
Buying a certificate that carries your company name
The 398-day clock applies wherever you buy, so the thing worth comparing is how much of the re-verification your provider absorbs. The SSL certificates we issue come from Certum, a publicly trusted CA that issues from its own roots, so the organization validation sits with the CA issuing your certificate rather than with an intermediary.
Related reading
- OV versus EV SSL certificates — what each validation level actually checks, now that both run on the same 398-day clock.
- Domain validation changes in 2026 — the other clock, the methods being retired, and the DNSSEC requirements behind them.
- The March 2027 CA automation requirement — why every CA must automate issuance, and what the policy deliberately leaves to people.