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.
One entry in that list has since moved: ballot SC102, passed on July 14, 2026, replaced the hardcoded 398 days for EV domain validation reuse with a reference to the Baseline Requirements, currently 200 days, leaving the organization items below on 398.
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.
Frequently Asked Questions
Answers to common questions about certificates and our services.
How often does my company have to be re-verified for an OV certificate?
Once every 398 days, counting from the day the certificate authority collected each piece of evidence. Baseline Requirements section 4.2.1 lets a CA reuse validated Subject Identity Information for a maximum of 398 days for certificates issued on or after March 15, 2026, down from 825 days before that date. Your CA will usually run the re-verification quietly in the background when an order arrives with stale data, so the first sign is often a slower issuance rather than a formal notice.
Did the 398-day change affect EV certificates?
No. EV has been on a 398-day clock the whole time. Section 3.2.2.14.3 of the EV Guidelines caps the age of validated data at 398 days for every item it lists: legal existence and identity, assumed name, address of place of business, verified method of communication, operational existence, domain name, and the name, title, agency and authority of the contract signer and certificate approver. What happened on March 15, 2026 is that OV converged onto the schedule EV already ran.
When does the 398-day clock actually start?
On the date the CA collected the information, not the date your certificate was issued and not the date you paid. The EV Guidelines state this in as many words: the 398-day period begins to run on the date the information was collected by the CA. That distinction catches people out, because evidence gathered several weeks before an issuance has already burned several weeks of its life. Two certificates issued on the same day can therefore have organization data with very different amounts of time left on it.
What happens if my organization validation expires?
Nothing at all to the certificate you are already running. Validation data reuse limits govern issuance, so an expired validation cannot revoke or invalidate a live certificate. The consequence lands on your next request: the CA has to redo the organization checks before it can issue, which means registry lookups, a call to a verified phone number, and sometimes a signed document. Your existing certificate keeps working normally until its own expiry date.
Will the 398-day reuse period shrink again like certificate lifetimes?
Not on any published schedule. The Baseline Requirements reuse table for Subject Identity Information has exactly two rows, 825 days before March 15, 2026 and 398 days after it, with no further step. Domain and IP validation data is on a separate, much steeper track, falling to 100 days in March 2027 and 10 days in March 2029, and maximum certificate validity drops to 100 days and then 47 days on the same dates. The organization clock is the one number in this area that stands still.
Can ACME or another automation tool handle the revalidation?
No, and the standards are explicit about why. An ACME challenge proves control of a domain name by publishing a token in DNS or serving it over HTTP; it has no mechanism for confirming that a company is registered at an address or that the person requesting the certificate is authorised to. Chrome Root Program Policy carves this out directly when it requires CAs to automate issuance, excluding the human input needed for identity and business document verification tied to IV, OV and EV issuance.
What makes a revalidation take longer than people expect?
Third parties, almost every time. The CA has to confirm your organization through a government registry, a reliable third-party database, a site visit, or an attestation letter, and then verify the request itself over a reliable method of communication. Company details that changed since the last validation are the usual delay: a new registered address, a renamed entity, a phone number that no longer appears in the source the CA checks, or a signatory who has left. Registry lag after a genuine change adds days that nobody can shorten.
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.