I checked nine free RFC 3161 endpoints against the EU Trusted List. None is qualified. Five of the companies are.

On 16 October 2026 I sent one timestamp request to each of nine public, free RFC 3161 endpoints and looked up the certificate that signed each reply in the EU Trusted List. All nine answered. All nine tokens verified (message imprint and nonce echoed back correctly). None of the nine is a qualified timestamp under eIDAS.

The list I checked against: LOTL sequence 397, issued 2026-10-15, 29 member-state lists downloaded and signature-verified, 1,443 TSA/QTST entries of which 915 are granted today. Snapshot SHA-256 d1700e6a…c85d, LOTL SHA-256 a36d0053…70e6. Hungary and Portugal didn't download (TLS cut the connection), so a Hungarian or Portuguese endpoint would have come back "not checked", not "not qualified". None of the nine is in either country.

"Qualified" here is the mechanical test from ETSI TS 119 615: the key that signed the token, or the CA that issued it, has to match a TSA/QTST entry whose status was granted at the token's genTime. For all nine, neither the signing key nor the issuer name appears anywhere among the 1,443 qualified-timestamp entries. Not as granted, not as withdrawn. The lookup never reached the status step.

The last column is the point

I ran this same check in August and wrote it up with one example of a QTSP whose free endpoint isn't qualified: Actalis. That undersold it. Five of the nine companies hold granted qualified-timestamp entries on the list today. They just don't hand them out at the free URL.

Actalis is the cleanest case because both halves sit in the same country under the same company name. The free endpoint signs with Actalis Time-Stamping Authority TSU 2, issued by Actalis Time Stamping CA G1. The Italian list has two granted entries for Actalis S.p.A.: Actalis TSA 1 EIDAS and Actalis EU Qualified TimeStamp CA G1. Different CAs. The library returns False for the free one, and that is the right answer.

The other four are the same shape with an extra twist: the entity on the list is often not the entity on the certificate. The free Sectigo token is signed under O=Sectigo Limited, C=GB; the qualified entry is Sectigo (Europe) SL on the Spanish list. GlobalSign's free token says GlobalSign nv-sa, C=BE, and Belgium does list four granted GlobalSign qualified timestamping CAs, none of which issued this certificate. Certum's token is signed by Asseco Data Systems, which has three granted entries in Poland, under different CAs. DigiCert's nine granted entries are in the Netherlands, under DigiCert Europe Netherlands B.V., with QuoVadis names on the certificates.

So "is this provider a QTSP?" is the wrong question. Qualification attaches to a service entry, which is a public key plus a status timeline. The right question is whether the key that signed your token is on the list, and was granted at that second.

Two things that moved in eight weeks

Entrust's URL still answers, and the token it returns is signed by Sectigo Public Time Stamping Signer R37, serial 0xe74ef255…a315. That's byte-for-byte the same certificate timestamp.sectigo.com returned a few seconds earlier. Entrust sold its public certificate business to Sectigo, and the endpoint followed. A config file that says entrust now produces Sectigo evidence. Nothing broke; nothing told you either.

Apple's signing certificate was issued on 2026-10-15 and expires on 2026-11-26. Forty-two days. Whatever certificate you look up next month will not be this one. Between my August run (LOTL 390) and this one (LOTL 397) the list itself moved seven sequence numbers; Ireland, unreachable in August, downloaded fine, and Hungary and Portugal didn't.

What this costs you, legally

Article 41(1) of eIDAS says an electronic timestamp can't be refused as evidence just because it is electronic or not qualified. So every token in that table is admissible. Article 41(2) gives qualified timestamps, and only qualified timestamps, a presumption of accuracy of the time and integrity of the data. With a free token, you prove the clock and the integrity; with a qualified one, the other side has to disprove them.

For most logging that's fine. It stops being fine when the record is one you'd put in front of a regulator. The AI Act's Article 12 logging duty applies from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, after Regulation (EU) 2026/1744 moved the dates, and the text of the article didn't change. If you're building toward that, the free tier of a QTSP is not the QTSP. I haven't found a free qualified endpoint, from these nine or anywhere else. (If you know of one, I'd like to be wrong.)

Look it up when you stamp, not when you're asked

The failure mode I care about isn't picking a free endpoint. It's picking a paid qualified one, and then checking its status three years later when a dispute arrives. That lookup answers today's question against today's list. Keys rotate, entries get withdrawn, the Entrust URL becomes a Sectigo URL. The only time the answer is knowable is the moment the token comes back, and the answer has to be written down then, next to the token, with the hash of the list it was checked against. That is what tg-attest does on its write path, as a three-valued field (True / False / None for "couldn't check"), with no network call at stamping time. The measurement above is that code run by hand.

Limits

Nine endpoints is nine endpoints, picked because they are the ones people paste into signtool and openssl ts. Certificates rotate (Apple's lasts six weeks; GlobalSign's is named 202510) and the LOTL moved seven times in eight weeks, so this table is true for 16 October 2026 and I make no claim about any other date. The "company name" column is my substring match on the list's provider names, not a corporate register; it's there to show the pattern, not to settle who owns whom. The two unreachable member states are unreachable today, not permanently, and five list entries (one French, four Norwegian) carried certificates my parser rejected and were skipped. A verdict of "not qualified" is about Article 41(2)'s presumption only; nothing here says these tokens are technically weak. All nine echoed my hash and nonce correctly. I didn't run full chain verification for this post.

I kept every .tsr from this run, and you don't need them: request a token from any of the nine yourself and openssl ts -reply -in <file> -token_in -text shows the same certificate names without installing anything of mine. The snapshot was built with python -m tg_attest.eutl_build, which verifies the LOTL against the six certificates in OJ C/2026/1944 and each national list against the LOTL.

Sources

• Regulation (EU) No 910/2014 (eIDAS), Article 41
• ETSI TS 119 615 V1.3.1, procedures for using and interpreting EU Member States' trusted lists, §4.6
• OJ C/2026/1944, LOTL signing certificates
• Regulation (EU) 2026/1744 (Digital Omnibus), moving the AI Act Chapter III application dates
• Entrust, public certificate business transition to Sectigo

A routing audit for your team, fixed price. The method in this series runs on any Claude Code trace store. Send me 30 days of your team's usage records (model, tokens, timestamps, agent and session ids; I'll send a one-line jq filter that drops prompt and answer text before anything leaves your machine) and within ten working days you get one number and a five-page report: what share of your spend ran on a tier your own routing policy would not have chosen, what that cost at list price, and which components caused it. On my own 26,131 traces the number was 22.6% and $1,248.13, all of it on subagents and none on the main thread. US$1,500, flat. Write to info@zhuojun.li with the subject "routing audit".