Qualified Trust Service Provider (QTSP): What It Is
A qualified trust service provider (QTSP) is an organisation that has earned qualified status under eIDAS Regulation (EU) No 910/2014 by passing an independent conformity assessment and receiving formal approval from a national supervisory body. That status unlocks specific legal presumptions that standard trust service providers cannot claim - making a QTSP the only recognised source of legally equivalent digital signatures, seals, and timestamps across EU member states.
For labs and regulated businesses, that legal distinction is not a technicality. It determines whether a signed or sealed document holds up under audit, in court, or before a national regulator.
What makes a provider a QTSP
Under Article 3(20) of eIDAS Regulation (EU) No 910/2014, a "qualified trust service provider" is a trust service provider that offers one or more qualified trust services and has been granted qualified status by the supervisory body of the EU member state where it is established.
Getting there requires clearing two gates. First, the provider commissions an audit from an accredited conformity assessment body (CAB) - an independent third party that checks technical security, operational procedures, and compliance with the applicable ETSI EN 319 standards. Second, the national supervisory body reviews the CAB's report and either grants or refuses qualified status. Only after both gates clear does the provider appear on the national trusted list as a QTSP.
How QTSP status is granted
The process runs in a defined sequence: the applicant undergoes a CAB audit, the CAB issues a conformity assessment report, the supervisory body evaluates that report, and - if satisfied - grants qualified status and notifies the European Commission to update the national trusted list entry. The ETSI EN 319 series sets the technical benchmarks the CAB checks against.
QTSP vs. non-qualified TSP: where the gap matters
A non-qualified trust service provider can still issue digital certificates, run a signing service, or provide timestamping - but none of those outputs carry the automatic legal presumptions that eIDAS attaches to qualified services. A qualified electronic signature from a QTSP is presumed, under Article 25(2), to have the same legal effect as a handwritten signature. No standard TSP's signature carries that presumption.
That gap in legal weight is exactly why labs, notaries, and regulated businesses specifically seek out QTSPs rather than any available eIDAS TSP.
What services a QTSP can offer under eIDAS
eIDAS defines seven categories of qualified trust services. Each one requires separate qualified status - a QTSP certified for signatures is not automatically qualified for timestamps or registered delivery.
| Qualified service | eIDAS reference | What it does | Lab relevance |
|---|---|---|---|
| Qualified electronic signature | Art. 3(12), Annex I | Binds a natural person's identity to a document with full legal presumption | Signing reports requiring a named signatory |
| Qualified electronic seal | Art. 3(27), Annex III | Binds a legal entity's identity to a document, guaranteeing origin and integrity | Sealing calibration certificates and test reports |
| Qualified electronic timestamp | Art. 3(34), Annex III | Proves a document existed at a specific point in time | Locking report data against backdating |
| Qualified electronic registered delivery | Art. 3(37) | Provides legally recognised proof of sending and receipt | Delivering regulated documents to clients |
| Qualified website authentication certificate | Art. 3(39) | Binds a domain to a legal entity with verified identity | Authenticating lab portals to browsers |
| Qualified preservation service | Art. 3(40) | Maintains the verifiability of qualified signatures and seals over time | Archiving signed documents for multi-year retention |
| Remote qualified signature / seal creation | Art. 29a (eIDAS 2 / Regulation (EU) 2024/1183) | Allows signing via a centralised, QTSP-managed private key | Cloud-based signing API integration |
For a closer look at the sealing service, the eIDAS electronic seal overview explains what seals are and how they differ from signatures. The technical requirements and lab application of qualified electronic seals are covered in a dedicated guide.
On qualified timestamps and preservation: These services are especially relevant for ISO 17025 labs that must demonstrate data integrity across multi-year accreditation cycles. A dedicated guide on qualified timestamps is forthcoming.
How QTSPs are listed and supervised: the EU Trusted List
What the EU Trusted List contains
The EU Trusted List is a machine-readable XML file maintained by the European Commission at ec.europa.eu/tools/lotl/eu-lotl.xml. It aggregates the national trusted lists of all EU member states into a single authoritative source. Each entry records the provider's name, the specific qualified service or services it holds, the current trust service status, and the supervisory body responsible. The eIDAS Dashboard, operated by the European Commission, renders that XML into a searchable browser.
The role of national supervisory bodies
Each member state designates a supervisory body under Article 17 of eIDAS to oversee QTSPs established in its territory. The supervisory body grants and can withdraw qualified status, monitors compliance, and publishes the national trusted list. Well-known examples include the Rijksinspectie Digitale Infrastructuur (RDI) in the Netherlands, the Bundesamt für Sicherheit in der Informationstechnik (BSI) in Germany, and ANSSI in France. The European Commission then aggregates all national lists into the EU Trusted List.
How national lists feed into the EU Trusted List
Each supervisory body publishes its national trusted list in a standardised XML format. The European Commission's trust infrastructure pulls those lists automatically and merges them. Any change a supervisory body makes - granting a new service, withdrawing a status - propagates to the EU Trusted List within the update cycle. This architecture means the EU Trusted List is always the definitive, cross-border reference for trust service provider selection.
How to verify a provider on the Trusted List
This is the step many teams skip - and it matters. A provider's marketing page may claim qualified status while the actual list tells a different story. Here is the verification workflow:
- Open the EU Trusted List browser. Go to the eIDAS Dashboard trust services browser maintained by the European Commission.
- Select the member state. Use the country filter to narrow results to the jurisdiction where the provider is established.
- Search for the provider by name. Type the legal entity name into the search field. Match it exactly against the provider's registered legal name, not its trade name.
- Identify the specific qualified service. A provider may hold qualified status for seals but not for timestamps. Expand the provider entry to see each service listed separately.
- Check the trust service status. Each service carries one of three statuses: Granted (currently qualified), Withdrawn (qualified status removed - historically valid output may still be verifiable), or Revoked (never valid or invalidated retroactively - treat all output as untrusted).
- Confirm the service type matches your use case. A "qualified certificate for electronic seal" service is not the same as a "qualified timestamp authority" service. Confirm the service identifier maps to what you need.
- Record the check date. Status can change. Document when you verified a provider's status as part of your compliance records.
What "withdrawn" means - and what to do: A withdrawn status means the QTSP no longer holds qualified status for that service going forward. Documents sealed or signed while the status was "granted" retain their legal presumption if LTV (long-term validation) data was embedded at the time of signing. Documents created after the withdrawal date do not carry qualified status. If your provider's status is withdrawn, migrate to a new QTSP for any new issuance.
What engineers should evaluate beyond the Trusted List
Qualified status is the minimum bar, not the selection criterion. Having worked through QTSP API integrations for lab certificate portals, I can say that the difference between providers with identical qualified status can be enormous at the engineering level.
REST / signing API quality and documentation
A well-designed signing API exposes clear endpoints, consistent error codes, and OpenAPI / Swagger documentation. Providers whose documentation is a PDF from several years ago signal integration pain ahead. Check whether the provider publishes a changelog and versioning policy - breaking API changes without notice are a real risk in production systems.
API latency and throughput for high-volume sealing
For a lab issuing hundreds of calibration certificates per day, API latency compounds fast. A sealing call that takes 3 seconds per document becomes a 50-minute queue for 1,000 documents. Ask the provider for P95 latency figures under load, not just average response times.
Sandbox and test environment availability
A sandbox environment lets you build and test the full integration - including error paths and edge cases - before touching production credentials. Providers without a sandbox force you to test in production, which risks burning real certificate quota and creating compliance headaches. This is a non-negotiable criterion for any serious integration.
Long-term validation (LTV) support in output documents
Long-term validation means embedding, at signing time, all the revocation data, certificate chain data, and timestamp tokens needed to verify a signature years later - even after certificates have expired. Without LTV, a sealed lab report may become unverifiable within a few years as OCSP and CRL services go offline. Confirm that the qualified certificate provider's output supports LTV embedding natively, not as an optional post-processing step.
Support responsiveness and SLA transparency
When a signing API goes down at 2 a.m. during a batch sealing run, you need a support channel that responds in minutes, not days. Ask for incident response SLAs in writing. Check developer communities for real accounts of how the provider handles outages.
Engineer's QTSP evaluation checklist
- Provider listed on EU Trusted List with "granted" status for the required service type
- REST API with OpenAPI / Swagger documentation
- Published API versioning and deprecation policy
- Sandbox / staging environment available without production credentials
- P95 latency figures available for sealing and timestamping endpoints
- LTV embedding confirmed in output PDF / CAdES / XAdES documents
- Dedicated developer support channel with documented response SLA
- eIDAS-compliant qualified certificate issuance per Annex I / II / III requirements
- Jurisdictional alignment: supervisory body in an EU member state relevant to your users
- Active CAB audit history with no adverse findings on public record
How to choose a QTSP for sealing and timestamping integrations
The right QTSP depends on which qualified service your workflow actually needs. Here is a decision framework:
| Use case | Primary qualified service needed | Key selection criteria |
|---|---|---|
| Sealing calibration certificates and lab reports | Qualified electronic seal | LTV support, high-throughput API, Annex III-compliant QCSeal certificates |
| Timestamping document submission events | Qualified electronic timestamp | Timestamp authority latency, RFC 3161 compliance, LTV-ready TST tokens |
| Named signatory on regulated documents | Qualified electronic signature | Remote signing API, identity verification flow, Annex I-compliant QES certificates |
| Combined seal + timestamp workflow | Both seal and timestamp services | Single-provider convenience vs. best-of-breed from two providers |
Matching the qualified service type to your document workflow
Labs issuing ISO 17025 calibration certificates typically need a qualified seal (the lab as legal entity) plus a qualified timestamp (to prove the report date). Those are two separate qualified services. Some QTSPs hold both; others specialise. If you choose two providers, confirm that the LTV data from both can coexist in the same output document.
Jurisdictional considerations: where is your supervisory body?
For cross-border EU recognition, any QTSP on the EU Trusted List works. If your lab operates under a national regulatory scheme that specifies a local supervisory body, check whether your users' regulators accept certificates from providers supervised in other member states. The eIDAS mutual recognition framework generally covers this, but sector-specific regulators sometimes add requirements. This is where qualified legal counsel matters - Sandorian provides engineering integration, not legal advice.
Note on eIDAS 2: Regulation (EU) 2024/1183 introduced updates to trust service categories, including remote signing and the European Digital Identity Wallet. For how eIDAS 2 changes trust services and QTSP obligations in 2026 and beyond, a forthcoming guide covers those updates in full.
Using a QTSP in an eIDAS-sealed lab portal
Integration pattern: document - signing API - sealed output - LTV
A working lab portal integration follows a predictable sequence. The lab's LIMS or report-generation system produces a document - typically a PDF. That document is sent as a payload (or as a document hash, for privacy-preserving signing) to the QTSP's signing API over a REST call. The QTSP signs or seals the document using the lab's qualified certificate for electronic seal, embeds a qualified timestamp, and returns a sealed PDF with LTV data embedded. The portal stores the sealed document and makes it available for download by the client or regulator.
Visually: Document → QTSP signing API → [qualified seal applied] → [qualified timestamp embedded] → [LTV data embedded] → Sealed PDF stored in portal.
That flow looks straightforward on paper. In practice, handling API errors gracefully, retrying failed sealing calls without double-sealing, and embedding LTV correctly without a post-processing step are the engineering problems that take real time to solve - and that we have already solved across multiple lab integrations.
Where Sandorian's integration experience fits
Sandorian builds eIDAS-sealed certificate portals for European labs. We have integrated QTSP signing APIs for calibration certificate workflows under ISO 17025 and IVDR requirements. Once you have selected a QTSP from the EU Trusted List and confirmed its qualified status for your service type, we wire it into your portal - handling the API integration, LTV embedding, error recovery, and audit logging.
You bring the QTSP. We build the portal around it.
Ready to integrate your chosen QTSP? Contact Sandorian to discuss how we can connect your qualified trust service provider to a compliant, production-ready certificate portal for your lab.
For labs still exploring the broader context of qualified electronic signatures alongside seals and timestamps, our lab guide covers how signatures and seals differ in practice and which regulated workflows require which.
Frequently asked questions
What is the difference between a TSP and a QTSP?
A trust service provider (TSP) is any entity that offers electronic trust services such as certificates, signatures, or timestamps. A qualified trust service provider (QTSP) is a TSP that has undergone an independent conformity assessment, received approval from a national supervisory body, and been listed on the EU Trusted List. Only QTSP services carry the legal presumptions defined in eIDAS - equal legal effect to handwritten signatures, proven origin for seals, and binding timestamps.
How do I check whether a provider is qualified?
Open the eIDAS Dashboard trust services browser, filter by member state, search for the provider's legal name, and check the trust service status for the specific service type you need. Look for "granted" status. Do not rely on the provider's own website claims.
Which services can be qualified under eIDAS?
Under eIDAS, seven service types can carry qualified status: electronic signatures, electronic seals, electronic timestamps, electronic registered delivery, website authentication certificates, preservation services, and remote qualified signature or seal creation. Each service requires separate qualified status.
Who supervises QTSPs in the EU?
Each EU member state designates a national supervisory body under Article 17 of eIDAS. Examples include the RDI in the Netherlands, BSI in Germany, and ANSSI in France. The supervisory body grants, monitors, and can withdraw qualified status, and maintains the national trusted list.
How often is a QTSP audited?
Under eIDAS, a QTSP must undergo a conformity assessment at least every 24 months. The CAB submits the resulting report to the supervisory body, which decides whether to maintain or withdraw qualified status. Some supervisory bodies conduct additional spot checks between scheduled audits.
What happens if a QTSP's status is withdrawn?
Withdrawal means the provider no longer holds qualified status for that service going forward. Existing documents sealed or signed while the status was "granted" retain their legal effect only if LTV data was correctly embedded at creation time. All new issuance after the withdrawal date loses qualified status. You must switch to a qualified provider for any subsequent document issuance.
Can a provider outside the EU be a QTSP?
No. QTSP status under eIDAS Regulation (EU) No 910/2014 is granted exclusively by EU member state supervisory bodies to providers established within the EU. Non-EU providers may offer similar services under bilateral recognition agreements, but they do not hold eIDAS QTSP status unless they establish an EU legal entity and complete the full qualification process.
What is the EU trust mark and what does it indicate?
The EU trust mark is a standardised logo that QTSPs may display next to their qualified services, defined under Article 23 of eIDAS. It signals that the specific service carrying the mark has been granted qualified status. It applies at the service level, not the company level - a provider may display the trust mark for its seal service but not for a non-qualified service it also offers.
Do I need a QTSP to issue eIDAS-sealed lab certificates?
If you need the qualified electronic seal to carry the full legal presumption of origin and integrity under eIDAS - which is typically required for calibration certificates in regulated environments and under IVDR - then yes, the seal must come from a QTSP holding qualified status for electronic seals. A seal from a non-qualified provider does not carry the same legal weight.
What should engineers look for in a QTSP's API beyond qualified status?
The engineering evaluation should cover: REST API documentation quality, API versioning policy, sandbox environment availability, P95 latency under load, native LTV embedding in output documents, support SLA and incident response time, and compliance with Annex I / II / III certificate requirements. Qualified status is the entry ticket; API quality determines whether integration is feasible in practice.
Sources
Let's talk
We build the systems that power your business. Let us know how we can help.
Book a 30-min Call