Certificate Transparency log delay: what 1.3M certs show
Short answer: We read the public Certificate Transparency (CT) history of roughly 700 high-traffic domains and compared each certificate's stated validity start (NotBefore) to the moment it actually showed up in a CT log. Across 1.29 million logged certificates from 2013 through mid-2026, 19.6% took more than two full days to appear in CT, and 15.0% took more than a week. Then we split the data at June 15, 2026, when Chrome's Root Program began requiring the final issued certificate, not just the precertificate, to carry a qualifying CT log record. After that date, the over-48-hour share drops to 1.7% and the over-a-week share drops to 0.8%, in the same population, measured the same way. The median certificate was already fast before the mandate; what changed is the tail, the certificates that used to sit unlogged for days, weeks, or months. Every number here comes from a passive read of a public log. No host was contacted, nothing was scanned. Here is exactly how we measured it, which issuers closed the gap fastest, and what this does and does not prove.
Two numbers, one policy change
Certificate Transparency was built to make certificate issuance a public, append-only record: every publicly trusted CA logs the certificates it issues, so anyone, a domain owner, a browser, a researcher, can see what was minted for a given name. The catch was always the word "eventually." A CA has been required to log a precertificate and embed its signed timestamps before issuing the final certificate since 2018, and an industry-standard Maximum Merge Delay bounds how long a log has to merge a submitted precertificate, typically about 24 hours. But until this year, there was no equivalent deadline for logging the final certificate itself. A certificate could be signed, dated, and already in production use while its own log entry lagged behind by days, weeks, or, in at least one independently reported case, months.
Read the median carefully: it barely moved, from 1.0 hour before the mandate to 0.975 hours after. That is not a data error, it is the honest shape of the distribution. Most certificates, from most issuers, were already logged within the hour long before any mandate existed. What the mandate visibly closed is the tail: the minority of certificates that used to sit for days or weeks with no public log record. The mean delay tells that story more bluntly, falling from about 64 days before the cutoff to 6.7 hours after, because a mean is dragged around by exactly the outliers a median hides.
The mechanism: a precertificate deadline, and no deadline for the rest
Certificate Transparency's original design logs a precertificate, a poison-extension placeholder that lets a CA collect Signed Certificate Timestamps before it signs the real thing. Multiple public CT logs must accept and merge that precertificate within a bounded Maximum Merge Delay, on the order of a day, and browsers have enforced that logs honor it since 2018. That part of the pipeline was always timely, which is why the industry could point to "CT is required" as broadly true.
The gap was the other half: nothing forced the CA to submit the final, issued certificate to a log on any particular schedule. A CA could get its SCTs from the precertificate, embed them, issue the certificate, and put it into production, all correctly, while the final certificate's own CT log entry waited. One independently reported case describes a DigiCert-issued wildcard certificate for a major platform that carried a roughly three-month gap between its stated issuance and its appearance in CT (we have not independently verified that specific case; treat it as an illustrative, not authoritative, anecdote). Our own data shows the same shape at population scale: before the mandate, a meaningful share of certificates from several large CAs sat for more than a week with no public log record, which is exactly the loophole Chrome's June 2026 policy targets by requiring the final certificate itself to carry a qualifying log record.
Which issuers closed the gap, and by how much
We are naming certificate authorities here, not the domains whose certificates we counted. A CA's own logging practice is public-interest information about the CA, the same way an earlier study of ours looked at which CAs domains authorize to issue for them. For each issuer with a real sample on both sides of the cutoff, here is the share of its certificates logged more than 48 hours after NotBefore, before and after 15 June 2026:
| Issuer | Before (n) | Before | After (n) | After |
|---|---|---|---|---|
| DigiCert Inc | 160,949 | 27.9% | 290 | 6.2% |
| Amazon | 95,508 | 20.0% | 863 | 2.9% |
| Google Trust Services | 66,473 | 10.3% | 2,249 | 3.1% |
| Sectigo Limited | 24,430 | 0.02% | 60 | 0.0% |
| Let’s Encrypt | 532,280 | 0.06% | 5,523 | 0.0% |
Two things stand out. First, Let’s Encrypt and Sectigo were already close to zero before the mandate existed, which tracks with both running large-scale, heavily automated issuance pipelines where "issue and log" is close to one atomic step. Second, the CAs that had the most room to improve, DigiCert, Amazon, and Google Trust Services, all improved sharply, cutting their late-logging share by roughly four to seven times. We could not build a reliable before/after row for every issuer: GlobalSign, COMODO's legacy brand, and ZeroSSL either had too few post-mandate certificates in our sample to report (fewer than a few dozen) or none of our tracked domains renewed through them since 15 June 2026. That is a limit of our domain sample, not a finding about those issuers.
How we measured this
A skeptic should be able to rebuild this from scratch, so here is the whole method with nothing hidden.
- The population. Roughly 700 domains from the Tranco top 1,000 list, assembled across several of our recent passive-DNS studies. For each domain we read its full Certificate Transparency history at crt.sh, which returns every logged certificate for that domain and its subdomains, going back to 2013.
- The metric. For each logged certificate, we compared its
not_beforefield (the certificate's stated validity start) toentry_timestamp(when crt.sh recorded that log entry). The difference is the delay we report. We deduplicated by crt.sh's internal entry ID and discarded a handful of entries with an implausible gap (more than five years), which we read as clock or parsing artifacts rather than real issuance behavior. - The split. We bucketed every certificate by whether its NotBefore fell before or on/after 15 June 2026, the effective date of Chrome's Root Program requirement that the final issued certificate carry a qualifying CT log record. Our cached data runs through 24 July 2026, so the post-mandate window is roughly the first six weeks under the new rule, not a full year; treat the post-mandate figures as an early read that we expect to firm up, not a mature trend.
- 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, the same line that governs every engagement we run.
- What we kept. Aggregate counts, medians, and percentiles, per issuer and per period. No domain or subdomain name is in the output, and we gathered no personal data; domain names and public certificate metadata are not personal data.
What this does not prove
Honest limits, because a number without its caveats is marketing.
- The post-mandate window is short. Six weeks of data is enough to show the shape of the change, not to certify it as permanent. Some of the improvement could reflect early, careful compliance that relaxes over time; we plan to re-check this.
- Not every issuer has a reliable after-picture. A handful of large CAs simply had too few post-mandate certificates in our specific 700-domain sample to report responsibly. A broader domain sample would fill this in.
- NotBefore is not a perfect proxy for "when the certificate was actually signed." A CA can set NotBefore slightly in the past for clock-skew tolerance. That practice would inflate our delay figure slightly even for a CA logging promptly; it does not explain gaps measured in days or weeks.
- This is a delay measurement, not a misissuance finding. A late-logged certificate is not evidence the certificate was wrongly issued, only that the public audit trail lagged behind its use. The risk is the audit gap itself: for however long a certificate goes unlogged, nobody monitoring CT for their own domain would see it.
- The population skews toward high-traffic domains. Tranco's top 1,000 leans on well-resourced organizations and major CDNs; issuance behavior for the long tail of smaller sites, who often use the same large CAs but through different automation, may differ.
Why this matters
Certificate Transparency's entire value proposition to a domain owner is that you can monitor the public log for your own name and catch a certificate you did not expect, before it gets used against you. That only works if logging happens close to issuance. A certificate that sits unlogged for a month is a certificate that was live, trusted by every browser, and invisible to anyone watching CT for exactly that period. The gap this mandate closes is not exotic; it is the plain difference between "we technically comply with Certificate Transparency" and "you can actually see what we issued, promptly, every time." The data says the industry's fastest issuers, Let’s Encrypt and Sectigo among them, already treated that as one atomic step well before any policy required it. The rest are visibly catching up now that Chrome's Root Program made it a requirement rather than a best practice, which is the same story we found when we looked at who actually witnesses production CT logs: the parts of this ecosystem that are enforced move fast, and the parts that are merely encouraged do not.
Certificate Transparency log delay: quick answers
What is Certificate Transparency log delay?
The gap between a TLS certificate's stated validity start (NotBefore) and the moment it actually appears in a public CT log. A short gap means the public audit trail keeps pace with issuance; a long gap means a valid, usable certificate existed for a period with no public record of it.
Does Chrome require all certificates to be logged to CT?
Chrome's Root Program policy requires the final issued certificate, not just the precertificate, to carry a qualifying CT log record for certificates issued on or after 15 June 2026; certificates issued after that date without one are not trusted by Chrome. Precertificate logging had already been required since 2018.
Why could a certificate be valid before it was logged?
CT requires logging a precertificate before the final certificate issues, and Maximum Merge Delay rules (about 24 hours) bound how long that takes. Until Chrome's June 2026 policy, there was no equivalent deadline for logging the final certificate itself, so it could be signed, dated, and used while its own log entry lagged behind, sometimes by months.
How was this measured?
Passively. We read the public CT history, via crt.sh, of roughly 700 Tranco top-1,000 domains, comparing each certificate's NotBefore to its log entry timestamp. No host was contacted, resolved, or scanned. The result is 1.29 million log entries from 2013 to mid-2026, split at the 15 June 2026 mandate date.