Qualified Trust Service Providers: How the EU Trusted List Decides What Counts

Trust service provider sounds like marketing. It isn't. Under Regulation (EU) 910/2014, better known as eIDAS, it's a defined legal category, and Article 3(19) draws it narrowly: a natural or legal person who provides one or more trust services, either as a qualified trust service provider or as a non-qualified one.

So the weight sits on trust service, which Article 3(16) spells out. An electronic service, normally provided for money, that creates, verifies or validates electronic signatures, electronic seals or electronic time stamps, or the certificates behind them. Electronic registered delivery is in there too, along with website authentication certificates and the long-term preservation of signatures and seals.

Notice what's missing. Storing documents isn't a trust service. Routing them round for approval isn't one either. A company can sit at the centre of how your contracts get signed and still not be a trust service provider in the eIDAS sense, because the regulation is naming a specific set of cryptographic services rather than an industry.

Two things follow from that definition, and both catch people out.

First, the term covers everyone in the category, qualified or not. A non-qualified provider isn't a lesser or shadier thing. It's the default, and plenty of them do careful work.

Second, the category attaches to services, not to companies. One provider can run four trust services and hold qualified status for two of them. We'll come back to that, because it's the single most common mistake in a supplier check.

Here's the part that surprises people: a provider doesn't decide it's qualified, and neither does its auditor.

Article 3(20) is blunt about the mechanism. A qualified trust service provider is one that provides qualified trust services and is granted the qualified status by the supervisory body. Granted. It's conferred by a national regulator, not earned by passing a test and not bought.

The route runs in a fixed order:

1. 1
   The provider gets audited by a conformity assessment body, which is itself accredited for the job.
2. 2
   That conformity assessment report goes to the national supervisory body, together with notification that the provider intends to start.
3. 3
   The supervisory body checks the provider and its services against the regulation. eIDAS gives it three months and makes it explain itself if it needs longer.
4. 4
   If the check passes, the supervisory body grants qualified status and has the national trusted list updated.

Step 4 isn't paperwork. Article 21(3) says a qualified trust service provider may begin to provide the qualified trust service after the qualified status has been indicated in the trusted list. Until that entry exists, the service isn't qualified, whatever the audit found. The list doesn't describe qualified status. It confers it.

Supervision doesn't stop at the entry, either. Article 20(1) puts qualified providers back in front of a conformity assessment body, at their own expense, at least every 24 months. Article 23 then lets them display the EU trust mark, which is a label for the status rather than a source of it.

Now the correction that changes how you go looking for it: there is no single EU Trusted List file sitting on a Commission server.

Article 22(1) puts the obligation on member states. Each one establishes, maintains and publishes its own trusted list covering the qualified trust service providers it supervises. The real picture is therefore around thirty national lists, each maintained by a different scheme operator in a different country, several EEA states included.

What the Commission publishes is the layer above. Under Article 22(3) and 22(4), member states notify where their list lives and which certificates seal it, and the Commission republishes that through a secure channel, sealed and machine-processable. ETSI calls the result the List of Trusted Lists, or LOTL: a compiled set of pointers to every national list, whose location is notified in the Official Journal of the European Union.

That two-tier shape is the entire trust model, and it rewards slowing down on. The LOTL holds no providers at all. It holds the addresses of the national lists plus the certificates that authenticate them, which means a validator that trusts one file can then authenticate the thirty lists that hold the actual data. Everything downstream inherits from that single anchor.

Format isn't left to taste. Commission Implementing Decision (EU) 2015/1505 pins the technical specification to ETSI TS 119 612, so a Spanish list and a Finnish list are the same XML shape and one implementation parses both. EU Trusted List, or EUTL, is shorthand for that whole arrangement rather than for any one filename.

Open a national list and you'll find providers, and under each provider a set of services. The service is the unit that matters. TS 119 612 gives every one of them the same handful of fields.

The service type identifier is a URI saying what this service does. CA/QC marks a certification authority issuing qualified certificates. TSA/QTST marks a qualified timestamping authority. Separate types exist for OCSP responders and CRL issuers, and for several things besides. A service listed under one type is not thereby listed under another.

The service digital identity holds the actual certificate or public key of the service. That's the trust anchor, the thing a validator chains up to. Everything else in the entry is metadata about when and how the anchor counts.

Service current status is another URI, and under eIDAS it's usually granted or withdrawn. Older values from the pre-eIDAS Directive era, like undersupervision and accredited, still turn up in the record.

Then the field most tools quietly skip. Alongside the current status sits its starting date and time, and alongside that sits the service history: earlier statuses, each with its own starting time. Trusted lists carry the whole history of a service's statuses rather than just the current one, and that exists for a reason we'll get to.

The Qualifications extension does the awkward work

One CA can issue qualified and non-qualified certificates alike. When the certificate's own contents don't make the difference machine-readable, clause 5.5.9.2 of TS 119 612 requires the list entry to carry a Qualifications extension: criteria, matched on things like policy OIDs and key usage, saying which certificates from that service are qualified and whether the private key sits in a QSCD.

It's fiddly. It's also why finding a CA on the list doesn't, on its own, tell you that a given certificate from it is qualified.

Put the pieces together and the qualified verdict is a lookup with a strict order of operations. A validator doing this properly runs something like:

1. 1
   Fetch the LOTL and check its seal against the certificates published in the Official Journal. If that fails, stop, because everything below inherits from this one check.
2. 2
   Follow the pointers to each national list and check each list's own seal against the certificate the LOTL declares for it. Only now is the data trustworthy.
3. 3
   Collect the service digital identities of the relevant services, filtered by the status that applied at the right point in time.
4. 4
   Chain the signer's certificate up to one of those anchors.
5. 5
   Apply the Qualifications criteria, together with the qualified-certificate statements inside the certificate itself, to decide whether this is a qualified certificate for signatures, for seals, or for neither.

ETSI wrote the procedure down so tools don't each invent their own. TS 119 615 covers exactly this: how to use and interpret the national trusted lists when deciding EU qualified status. It's unusually direct about the stakes, describing the lists as having "legal constitutive value" and calling them the single formal source for confirming that a service really was granted qualified status. EN 319 102-1 handles the validation around it, meaning integrity, chain, revocation and timestamps.

Step 3 is where careful tools separate from careless ones. The question isn't whether the provider is qualified today. It's whether the service was granted at the moment of signing. A provider whose status was withdrawn last year was still qualified for everything signed under it beforehand, and a document signed the week before its status was granted never was. Which is also why a signature with no trusted timestamp gets awkward here: if you can't prove when it was signed, you can't pick the right row in the history.

A signature can be cryptographically perfect and not qualified. That isn't a bug in the checker.

Valid means the maths holds up: the hash matches the bytes, the chain reaches a root the tool recognises, the certificate wasn't revoked or expired when it was used. Qualified means something narrower and entirely legal. The issuing service appears on a national trusted list with qualified status, and this particular certificate meets the criteria on that entry.

Commercial CAs that sit on no national list issue perfectly sound certificates every day. Signatures made with them validate cleanly. They aren't qualified, and no amount of cryptographic strength changes that, because qualification isn't a property of the cryptography.

This is also why two tools disagree about the same file. Adobe Acrobat checks against its own trust store, a different list maintained by a different organisation for different reasons. A signature can be trusted in Acrobat and unqualified under eIDAS at once, and both tools are telling the truth about the question they asked.

What qualified status buys you legally is a separate topic with its own answer, and this page won't repeat it. Article 25(2) gives a qualified electronic signature, or QES, the equivalent legal effect of a handwritten one, and Article 25(3) carries that recognition cross-border into every other member state. Where it leaves you on burden of proof when a document is actually challenged is the part worth reading properly, and our guide to qualified electronic signatures works through that, along with where an advanced signature is enough. If the thing you're holding was issued by an organisation rather than a person, electronic seals under eIDAS covers the parallel case, and the trust anchors are identical.

You don't have to parse XML to answer a supplier question. The Commission runs the EU TL Browser, a web front end over the same national lists a validator reads. Same data, human-shaped.

Pick a country and you get its trusted list. Pick a provider and you get its services, each with a type, a current status and the certificate behind it. That's usually enough to settle a procurement question in a couple of minutes.

A few habits make the answers reliable.

Look at the service, not the company name. This is the mistake that catches people most often. A provider can be listed for qualified timestamping and not for qualified certificates, so a header confirming the company is there tells you nothing about which of its services are.

Match the service type to what you're buying. If you need qualified certificates for signatures, CA/QC is the type you want, and the Qualifications criteria on that entry decide which of its certificates qualify.

Check the country you expect. Providers appear in the list of the member state supervising them, which isn't always the country whose flag is on the website.

One honest limitation, and it matters: the browser shows you the status now. For a document signed years ago you need the history, and that's a job for a validator rather than a quick lookup.

Supplier due diligence is one question. The file in front of you right now is another, and it needs the document rather than the browser.

Format decides which check you run, and four cover almost everything you'll meet in the EU:

• A signed PDF carries a PAdES signature inside it. That's PDF signature verification.
• XML files, including most e-invoicing and public-sector filings, carry XAdES. Extensions are .xml and .xsig. See XAdES verification.
• Italian .p7m files, and detached .p7s files, are CAdES in binary CMS form. See CAdES verification.
• .asice and .asics containers bundle documents and signatures together, Estonia's .bdoc among them, though a .bdoc needs renaming to .asice or .zip if the upload refuses the extension. See ASiC verification.

Not sure which one you're holding? Don't guess. Chaindoc's signature verification takes all four through one form, works out the format, checks the signer's certificate against the EU Trusted List, and reports integrity, certificate chain, revocation state and timestamps alongside the qualified verdict. Validation runs on the EU DSS library, the European Commission's own open-source signature code, which is what much of the ecosystem builds on.

Two practical notes before you upload. Detached signatures don't contain the data they signed, so a .p7s or a detached .xml needs the original document alongside it, and it has to be the exact file rather than a re-saved copy. And the tools are free: a one-time code sent to your email address confirms your identity before the first check, the report then opens in Chaindoc, and the file itself isn't stored.

Checking at volume rather than one document at a time is an integration job instead of a browser job. That's what the API is for.

The failure patterns repeat, and they're about precision rather than technology.

Reading trust service provider as a claim of qualification

It isn't one. Article 3(19) covers qualified and non-qualified providers alike, so a supplier describing itself as a trust service provider has told you which regulation it lives under and nothing at all about its status. The word you're checking for is qualified, and you check it in the list rather than in the brochure.

Checking the company instead of the service

Qualified status attaches to individual services. Finding a provider's name in a trusted list is the start of the check, not the end of it. Open the specific service, then read its type and its status.

Asking about today when the document is from 2021

Status changes. A service that's withdrawn now was qualified for everything signed while it was granted, and the service history is what settles that. Any tool reading only the current status will get old documents wrong in both directions.

Treating a green tick in a PDF reader as an eIDAS verdict

A reader checks against its own trust store. That's a real check, and it answers a different question from the one your compliance file needs answered.

If you take one thing from this page, make it the order of operations. Qualified status is granted by a national supervisory body, published in that country's trusted list, and only then true. Everything a validator does afterwards is a lookup against that record. So when a report comes back valid but not qualified, the useful next move isn't to argue with the cryptography. Open the entry for the issuing service, check its type and its status on the signing date, and you'll usually have your answer in a minute. Got a file in front of you now? Run it through the verifier and read the detailed report rather than the headline verdict.