SECOND MEASUREMENT SM-012

Certificate authorities get 92 days to file their audits. Most file in the last week, one in eleven files late, and Windows still trusts a root whose last audit ended in 2019

Markovian ProtocolMeasured 2026-10-03Status: sent to the CCADB steering committee and Microsoft’s root program 2026-10-03, responses pendingDOI: 10.5281/zenodo.23123265

Every certificate authority a browser trusts has to be audited once a year, and the four root programs that run the shared database of trusted CAs, the CCADB, give each CA 92 days after the audit period ends to file the auditor’s report. We read the deadline off the CCADB’s own export of 10,317 certificate records. Of 119 current audit statements for trusted CAs, 108 are dated inside the window, but 34 of them on days 80 to 89 and 10 on the last three days; the 90th percentile lands on day 92 itself. Eleven are dated past the deadline. Two came with an auditor’s letter, one of Thailand’s three and Firmaprofesional’s; two more, D-TRUST and PKIoverheid, opened incident reports instead; seven, Thailand’s other two, MULTICERT, Entrust, Catalonia’s CATCert and Brazil’s ITI twice, have nothing on file at all. Then the other direction: Mozilla and Chrome trust no root whose newest audit is more than 15 months old. Apple trusts six. Microsoft trusts 24, from 15 CAs, and the oldest, Certinomis, was last audited in December 2019.

Disclosure: Markovian Protocol holds no financial position in any organisation named here, was paid by no one for this work, and showed it to no one before publication except the organisations measured. How we work.

What they said, what we found

Auditing to the deadline

The distribution says more than the pass rate. CAs don’t file when the audit is done; they file when the clock is about to run out.

119 standard audit statements (WebTrust or ETSI) on trusted, non-revoked records with their own audits, period end at least 92 days before 3 October 2026. Median 76 days, 75th percentile 87, 90th percentile 92.

The 11 past the line, and what is on file for them:

Thailand filed one auditor’s letter on 14 April 2026 (bug 2031562), for the statement whose period ended 31 August 2025; its other two late statements have none, itself five and a half months after the first of those deadlines. D-TRUST and PKIoverheid opened compliance incidents tagged audit-delay (bugs 2011430 and 2074032) rather than the auditor letter the policy names; both are public, and we count them as disclosed. Entrust’s statement covers the period before its TLS business passed to Sectigo; Sectigo posted draft reports for the following period to Bugzilla in November 2025 and the CCADB record has not moved since.

How old an audit can be and still be trusted

Four root programs, one database, the same records. For each root a program includes today, the age of the newest audit period on file:

“Over 15 months” is 365 + 92 days: a year since the last period ended plus the filing window, so the next annual statement is past due. Five Microsoft roots carry no standard audit date at all and are not counted.

Apple’s six: SwissSign Silver CA G2 (841 days, removed by Mozilla and Chrome), DigiCert’s Verified Mark root (763 days, a mail-logo root no other program carries), and four Entrust AffirmTrust roots at 582 days, which Mozilla and Chrome removed in 2024 and Microsoft also keeps. Microsoft’s twelve oldest:

Most of these roots are trusted by Microsoft alone. That is the pattern: the two programs that distrust publicly and quickly, Mozilla and Chrome, have no stale audits; the two that don’t have 30 between them, and the longest-standing ones are roots the others already dropped.

How this ends

It ends per CA and per program: a late statement gets its letter or its upload, the daily recheck of the CCADB export drops it from the eleven; a root with a stale audit gets a new one or leaves the store, and the 24 falls. The CCADB could end the ambiguity for good by publishing the upload date, which is the first question on the page.

The evidence

Every quote below was copied from the source and checked against a saved copy, fetched 2026-10-03. The CCADB export, the policy pages, the Bugzilla threads and the scripts are published next to this page (SHA256SUMS).

CCADB AllCertificateRecordsCSVFormatV5, 2026-10-03: 10,317 records, 89 columns
  Standard Audit Period End Date   Standard Audit Statement Date   Standard Audit URL   Audit Firm
  Mozilla Status / Chrome Status / Apple Status / Microsoft Status   Revocation Status   Audits Same as Parent

D-TRUST            period end 2025-10-07   statement 2026-01-15   100 days   TÜV NORD CERT   Apple, Chrome, Microsoft, Mozilla
Entrust            period end 2025-02-28   statement 2025-06-27   119 days   Deloitte        Apple, Microsoft
Certinomis         newest period end 2019-12-13   Microsoft: Included   Mozilla: Removed   Apple: Removed

Bugzilla, product "CA Program", component "CA Documents", opened since 2025-01-01: 35 bugs
  2031562  2026-04-14  Thailand NRCA - Explanation for delay in WebTrust Assurance report
  2055439  2026-07-16  Firmaprofesional: 2026 audit-delay explanatory letter
  2051532  2026-06-30  SHECA - Explanatory Letter for Delay of WebTrust Seal
  2067507  2026-08-29  Chunghwa Telecom - Explanatory Letter for delay WebTrust for CA seals
  2031062  2026-04-11  Sri Lanka CERT - Audit Statement Delay Explanation Letter
  2076925  2026-09-30  Documents for SSL.com   (period ended 2026-06-30; filed on day 92)

Our questions

Sent on 3 October 2026 to the CCADB steering committee, which represents all four root programs, and to Microsoft’s Trusted Root Program. Answers will be printed here as written.

1. Does the CCADB record the date an audit statement was uploaded? If so, can it be added to the public export, so compliance with 5.2 can be checked by anyone rather than bounded from the statement date?
2. For the seven late statements with no letter and no incident report (Thailand’s July 2025 and February 2026 periods, MULTICERT, Entrust, CATCert, Brazil’s ITI), was a letter received by another route?
3. Microsoft: the Certinomis root’s newest audit on its CCADB record ended on 13 December 2019. Is a newer audit on file with Microsoft, and if so, why isn’t it in the CCADB?
4. Microsoft and Apple: the four Entrust AffirmTrust roots show a newest period end of 28 February 2025, and Sectigo’s drafts for the following period sit in Bugzilla. What is the current audit status of those roots in your stores?
5. Is “15 months without a current audit” a condition any of the four programs treats as grounds for removal, and if so, how are the 30 roots here still included?

Their reply, scored

Disclosure timeline

Waiting since 3 Oct.

What we can’t be sure of

• The CCADB export carries the auditor’s statement date, not the upload date. A statement dated on day 60 and uploaded on day 150 looks compliant here. Our 108 of 119 is therefore a ceiling on compliance, and the 11 a floor on lateness.
• A root program may hold a newer audit than its CCADB record shows. The CCADB is the place the programs say the record lives; if it’s out of date, that is itself the finding, but it is a different one.
• Microsoft’s store includes roots for purposes other than the web, with their own audit regimes. The 24 are measured against Microsoft’s own “annual basis” wording, which doesn’t distinguish.
• We matched letters and incident reports by CA name in Bugzilla summaries and the [audit-delay] tag. A filing under another title would be missed; the question above asks.
• One export, one day. The CSV changes daily as CAs file; the recheck will show whether the late ones catch up and whether the next filing season clusters the same way.

Run it yourself

Python 3 standard library. One 11 MB download from the CCADB and a few Bugzilla API calls; under a minute.

curl -sL https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormatV5 -o ccadb_v5.csv
python3 audit_deadlines.py     # statements, lateness by statement date, overdue CA owners, per audit type
python3 per_program.py         # per root program: age of the newest audit on each included root

Reproduced from the public repository on 3 October 2026 on a clean machine: exact (119 statements, 11 late, 90th percentile day 92; Mozilla 0 of 172, Chrome 0 of 101, Apple 6 of 144, Microsoft 24 of 331). Full table on the track record.

What you can do with this

• If you rely on the Microsoft root store, know that 24 of its roots carry audits more than 15 months old on the shared record; the list is in the exhibits.
• If you are a CA, the deadline is 92 days and the statement date is public; filing on day 92 is visible.

References

1. CCADB. CCADB Policy, section 5.2 Audit Statement Content. ccadb.org/policy.
2. Mozilla. Mozilla Root Store Policy, section 3.4 Compliance Self-Assessments. mozilla.org.
3. Microsoft. Program Requirements, Microsoft Trusted Root Program, section 2 Audit Requirements. learn.microsoft.com.
4. CCADB. All Certificate Records (CSV, V5). ccadb.my.salesforce-sites.com.
5. Bugzilla, product CA Program, component CA Documents.

Cite as

@misc{markovian-sm012,
  author = {{Markovian Protocol}},
  title  = {Audit filing deadlines in the CCADB, October 2026},
  number = {SM-012},
  doi    = {10.5281/zenodo.23123265},
  year   = {2026},
  month  = oct,
  url    = {https://markovianprotocol.com/measurements/sm-012.html}
}