Nobody picks 198. It is what you get when the maximum a browser will accept became 200 days and the authority you buy from set its own ceiling a day under the rule.
On 4 September 2026 we connected to one public web server at each of a hundred well-known organizations, ten per sector, and read the certificate each one served. Ninety-seven answered. Thirty-seven of them, from the IRS to the CDC to a good share of the banks, were serving a TLS certificate valid for exactly 198 days.
Nobody picks 198. No change window, compliance calendar or engineering reason lands on 198. It is not a round number and it is not a quarter of anything. It is what you get when the maximum lifetime the browsers will accept became 200 days on 15 March 2026, and the certificate authority you buy from set its own ceiling a day under the rule to be safe. DigiCert says so in its own customer alert: its maximum validities "are one day shorter than the maximum validity allowed by the CA/Browser Forum, to avoid exceeding the maximum permitted validity." A 199-day product, measured as 198 days between the two dates on the certificate, on thirty-seven servers that have nothing else in common.
That is the whole finding. The rest is what it implies. The most common certificate lifetime on the recognisable web is not a decision anybody made about their infrastructure. It is a reading of the regulation, taken at the last permitted moment.
The rule is Ballot SC-081v3 of the CA/Browser Forum, the body where certificate authorities and browser makers set the requirements for publicly trusted certificates. It passed on 11 April 2025. The vote among certificate issuers was 25 in favour, none against, 5 abstaining; among the four certificate consumers that vote, Apple, Google, Microsoft and Mozilla, it was 4 to 0. Nobody voted no in either chamber. The stated rationale is one sentence: "Certificates are representations of a point in time state of reality." The longer a certificate lives, the longer a stale fact stays trusted.
The schedule steps the maximum lifetime down: 398 days until March 2026, 200 days from then, 100 days from March 2027, and 47 days from 15 March 2029. The ballot page gives the shape ("starting in March 2026 and concluding in March 2029") and the redlined requirements give the day, the fifteenth in each case. The same ballot shortens how long a domain-validation check can be reused before it must be repeated: from 825 days to 398, and then to 10.
Hold on to that second schedule. It is the one that matters, and it is the one nobody writes about.
The usual story is a mass at 90 days, put there by Let's Encrypt and its ACME automation, plus a shrinking tail of annual certificates renewed by hand. Under that story, the interesting question is how fat the tail still is.
The measured distribution has a different shape. Of the 97 hosts (three failed to verify against our client's trust store and are excluded from every figure below; all three connect fine with verification off, so they are artifacts of the probe, not of the sites):
| Served lifetime | Hosts | Share |
|---|---|---|
| 48 to 100 days | 24 | 24.7% |
| 101 to 200 days | 50 | 51.5% |
| 201 to 398 days | 23 | 23.7% |
| over 398 days | 0 | 0% |
The median is 198 days. The mean is 212. Within the 101-to-200 band, 44 of the 50 sit between 190 and 200 days, and 37 of those are the 198 exactly. Only a quarter of the sample is in the 90-day automation band, and 22 of those 24 are at 89 or 90 days precisely, which is Let's Encrypt's and Google Trust Services' default.
So there are not two populations, a modern one and a tail. There are three, and the middle one is the largest:
The second population is the finding. Its lifetime carries no information about whether it can rotate faster, because the number was never about capability. Every step down so far has looked like a success in a histogram and proved nothing, because a group that renews at the maximum by hand will re-anchor to the new maximum by hand. The empty bucket above 398 days is not evidence that anyone automated. It is evidence that a rule was followed on the day it took effect, exactly as written.
The issuer split makes this hard to argue with. Of the 24 hosts in the automation band, 20 are on an ACME-native authority: Let's Encrypt (11) and Google Trust Services (9). Of the 44 hosts parked at 190 to 200 days, 31 are on DigiCert (25) or Sectigo (6). Of the 23 pre-cap legacy hosts, 18 are on DigiCert, Sectigo or Entrust.
Which certificate authority an organisation buys from tells you its certificate lifetime better than anything else we measured. That is another way of saying the lifetime is a procurement fact, not an engineering one. The organizations at 198 did not evaluate their renewal pipeline and conclude 198 was right. They bought a certificate from a vendor whose product is the maximum, minus a day.
Ten sectors, ten organizations each, one host per organisation, measured on 4 September 2026:
| Sector | n | Automated, 100 days or under | At the cap, 190 to 200 | Pre-cap legacy, over 200 |
|---|---|---|---|---|
| Higher education | 10 | 6 (60%) | 4 (40%) | 0 |
| Federal government | 10 | 4 (40%) | 2 (20%) | 4 (40%) |
| Big tech | 10 | 3 (30%) | 3 (30%) | 3 (30%) |
| Industrial | 10 | 3 (30%) | 4 (40%) | 3 (30%) |
| Utilities | 10 | 3 (30%) | 5 (50%) | 2 (20%) |
| State government | 9 | 2 (22%) | 3 (33%) | 2 (22%) |
| Healthcare | 10 | 2 (20%) | 5 (50%) | 3 (30%) |
| News media | 9 | 1 (11%) | 5 (56%) | 2 (22%) |
| Retail | 9 | 0 | 6 (67%) | 3 (33%) |
| Banking | 10 | 0 | 7 (70%) | 1 (10%) |
| All | 97 | 24 (24.7%) | 44 | 23 |
Two sectors are at zero. Banking is 0 of 10 and retail is 0 of 9 in the automated band. The two sectors with the most to lose from a certificate outage on a Saturday are the two with no measured automation in the sample at all.
And the sector furthest ahead is higher education, at 6 of 10, running Let's Encrypt, Google Trust Services, InCommon and Internet2. The universities got there first. The population with the least money to spend on certificate lifecycle products is the population that stopped needing them.
A caution that applies to every row: a CDN in front of an origin means we measured the CDN's certificate, not the organisation's. Some of the 89-day results are certainly a CDN's automation. That is a real fact about who carries the burden, and it is not the same claim as "this organisation automated."
Forty-seven days is survivable by a determined person with a calendar. Eight renewals a year per certificate is miserable, and it is possible.
What is not possible is the other schedule. Domain-control validation, the check that proves you own the name before a certificate is issued, currently has a reuse window: validate once, mint certificates against that proof for a while. The Forum's ballot takes that window from 825 days to 398 and then to 10. Let's Encrypt, which issues more publicly trusted certificates than anyone, has published exactly where it lands. In its post of 2 December 2025, "Decreasing Certificate Lifetimes to 45 Days," the dates are: 13 May 2026, a 45-day certificate profile offered as an opt-in; 10 February 2027, the default profile moves to 64-day certificates with a 10-day authorization reuse period; 16 February 2028, the default profile moves to 45-day certificates with a 7-hour authorization reuse period. The reuse period today is 30 days.
Seven hours. A certificate you can renew by hand. A validation you must repeat within seven hours of every issuance, you cannot. It has to be a machine talking to a machine, on a schedule nobody attends. That is the forcing function, and it is not the number in the headline.
Notice too that the automated population is not being dragged to the deadline. Let's Encrypt reaches 45 days in February 2028, more than a year before the industry maximum becomes 47, and its own documentation says so in one line: "Industry rules will limit certificate lifetimes to a maximum of 47 days starting on March 15, 2029." It already offers 6-day certificates to anyone who wants them. The gap between the two populations in our sample is going to widen before it closes.
The first test is not in 2029. The 200-day cap took effect on 15 March 2026, so the first certificates issued at the new maximum come due on 1 October 2026. That is four weeks from the measurement. Every organisation in the 190-to-200 band renewed under the new cap once, in the spring, and is about to find out what its second renewal looks like at the same cadence, and its third, and its fourth, for as long as it keeps buying the maximum.
Some named certificates, read on 4 September 2026 and re-read on 7 September 2026 (all three of the named hosts below were serving the same certificate on both dates), are closer than that:
Each of those is one host, read once, on a stated date. It supports "the certificate this host served on that day had that lifetime." It does not support "this organisation cannot automate." The distinction is the whole reason the numbers are worth reading.
Then the steps, by sector, with the share of each sector's sample that has not been measured automating:
| Step | Date | Banking | Retail | News media | Healthcare | Utilities | State gov | Industrial | Big tech | Federal gov | Higher ed |
|---|---|---|---|---|---|---|---|---|---|---|---|
| First 200-day renewals fall due | 1 Oct 2026 | 100% | 100% | 89% | 80% | 70% | 78% | 70% | 70% | 60% | 40% |
| Maximum drops to 100 days | 15 Mar 2027 | 100% | 100% | 89% | 80% | 70% | 78% | 70% | 70% | 60% | 40% |
| Let's Encrypt default to 64 days, 10-day reuse | 10 Feb 2027 | same populations, if they migrate | |||||||||
| Let's Encrypt default to 45 days, 7-hour reuse | 16 Feb 2028 | ||||||||||
| Industry maximum 47 days | 15 Mar 2029 | 100% | 100% | 89% | 80% | 70% | 78% | 70% | 70% | 60% | 40% |
The percentages do not change down the table, and that is the point. Nothing in the data says which of the 73 non-automated hosts will automate before each step. It says only that, as of September 2026, three years and six months from the last step, 75 percent of a sample of well-resourced, recognisable organizations were still renewing at whatever the maximum was. The rows are not a forecast. They are the same measurement, held up against three dates.
Certificate Transparency logs record issuance. Every publicly trusted certificate is logged when it is created, so the logs will show the 200-day and 100-day and 47-day certificates arriving on schedule, and they will show it perfectly. What they cannot show is deployment. A certificate authority can log a 47-day certificate nobody ever installs. An operator can keep serving a certificate that expired last Tuesday, and the logs will hold no record of the outage, because nothing was issued.
That is why this measurement was taken from the other side, by connecting to the servers and reading what they serve. It records deployment, which the logs cannot. It still does not record pain. The signal that would, an expired certificate found in use at scan time, came back at zero: 0 of 97 hosts were serving an expired certificate. That is a null result and it is reported as one. The sample is large, well-resourced organizations, which is exactly where you would expect zero, and it says nothing about the long tail of small servers where expired certificates actually live. We did not sample that tail, so we cannot count it.
One more thing this data does not do: it is not a random sample of the web. It is a hundred hand-picked organizations with sector labels we chose. It supports claims about these organizations and about the shape of the split. It does not support a percentage-of-the-web claim, and none is made here. The vendor figures in circulation, the ones that say most companies had a certificate-related outage last year, are self-reported surveys run by companies that sell certificate management; they may be right, and they are not measurements.
If you run infrastructure, read your own certificates the way this piece read a hundred strangers'. Take the lifetime of what each public host serves and sort it into the three bands. The 89-day band is done; leave it. The over-200 band has a date on every certificate and each date is a renewal you already know about. The band in the middle, the certificates at 198 or 199 days, is the one to look at, because it is the one that feels finished and is not. Each of those certificates was issued at the maximum by a process that will issue at the maximum again in 2027, at 99 days, and again in 2029, at 46, and somewhere between those two steps the validation reuse window on the automated side collapses to hours.
The question to ask of that band is not "when does this expire." It is "what issued this, and would it still work if it had to run eight times a year without a person." Where the answer is a person with a calendar, the certificate lifetime you see today is telling you the date of a rule, not the state of your system. The system is whatever happens on 1 October.
Method, so you can repeat it: we opened a TLS connection to one public host at each of a hundred organizations on 4 September 2026, read the notBefore and notAfter dates and the issuer from the certificate each server presented, and took the lifetime as the whole days between those two dates. Three hosts failed to verify against our client's trust store and are excluded from every figure. Every host in the sample is a public web server, so any reading here can be checked directly: openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer returns the same three fields we recorded. The hosts named with expiry dates were re-read on the day of writing and their dates and issuers matched. Every quotation carries its source and section.
The logs record what was issued. They cannot record what is deployed.
That gap is the whole reason this measurement had to be taken from the server side, and it is not unique to certificates. Chain of Consciousness is the machinery for the general version: a tamper-evident record written at the moment of the decision rather than reconstructed afterward, so what a system actually did can be checked by someone who was not there and does not have to take your word for it.
pip install chain-of-consciousness · npm install chain-of-consciousness
Or the whole stack, provenance and ratings and verification together: pip install agent-trust-stack / npm install agent-trust-stack.