Review this workflow before relying on a qualified trust service provider for signatures, seals, timestamps, website authentication certificates, attestations, archiving, ledgers, or related qualified trust services.
The checks focus on trusted-list validation, exact qualified service scope, certificate and revocation evidence, published policies, supervision, audits, termination planning, incident posture, and records to retain.
Select a only after the relevant Member State shows both the provider and the exact qualified service you will use. Qualified status is service-specific: the same provider may offer qualified and non-qualified services. This workflow helps procurement, product, security, legal, and compliance teams verify that status, test the service evidence, review operating terms, and define monitoring before onboarding or continued reliance.
1
Section 1
1. Confirm the provider and service in the EU trusted-list system
Start with the Member State and the Commission List Of Trusted Lists, not with a vendor certificate bundle or sales deck. eIDAS requires Member States to establish, maintain, and publish trusted lists that identify qualified trust service providers and the qualified trust services for which they are responsible.
Record the legal provider name, Member State, trusted-list location, scheme operator, service name, service type identifier, service digital identity, current service status, status start time, and relevant service history. If the exact service is not shown with a suitable qualified status, do not treat it as qualified. A vendor explanation can resolve an identity or scope mismatch, but it cannot replace the trusted-list indication required before a qualified trust service may begin.
Verify that the provider is a qualified trust service provider, not only a trust service provider with a non-qualified service.
Match the listed service type to the planned use case, such as qualified certificates for electronic signatures, seals, website authentication, timestamps, electronic registered delivery, electronic attestations of attributes, archiving, or ledgers.
Check current status and historical status entries because trusted lists are designed to show whether a service is or was operating in compliance at a specific time.
Keep a machine-readable trusted-list extract or validation output, a human-readable screenshot if useful, and the date and time of the check.
Do not accept a generic EU trust mark, logo, or website claim unless it links back to the relevant trusted-list entry for the qualified service.
Defines trusted-list fields used for QTSP diligence, including TSP information, service type, current status, status start time, service digital identity, and history.
Trusted lists therefore contain not only the service's current status, but also the history of its statuses.
2
Section 2
2. Scope the qualified service and certificate evidence
A can provide more than one service, and only some services may be qualified. Scope the review to the exact certificate, timestamp, validation, preservation, registered delivery, attestation, archiving, ledger, or remote signing service that the product will consume.
For certificate-based services, review the certificate policy, , certificate profile, usage limits, revocation mechanism, validity information, and any qualified-certificate statements that indicate the applicable legal framework and certificate purpose. These checks do not apply unchanged to every trust service. For timestamps, registered delivery, attestations, archiving, ledgers, validation, preservation, or remote-device management, use the service-specific policy and requirements instead of forcing a certificate-issuance checklist onto the service.
Qualified certificate diligence must distinguish electronic signature, electronic seal, and website authentication uses. A can help identify a certificate's declared status, purpose, or QSCD relationship, but the certificate extension does not replace the trusted-list check for the issuing qualified service.
Collect the CP, CPS, terms and conditions, relying-party guidance, subscriber obligations, certificate type descriptions, and policy object identifiers that apply to the service.
For qualified certificates, verify that the certificate identity, issuer identity, qualified status, certificate purpose, key usage, extended key usage, QCStatements, and country/legal-framework indicators match the intended reliance model.
For QWACs, confirm that the certificate is a qualified certificate for website authentication and that the service scope in the covers that certificate service.
For revocation-sensitive workflows, test the published validity or revocation status mechanism and keep the result with the onboarding record.
For remote signing or managed devices, document whether the reviewed service includes management of a remote qualified electronic signature creation device or only certificate issuance.
Article 24 and the certificate annexes support checks for identity verification, qualified certificates, certificate databases, revocation status, and relying-party validity information.
provide to any relying party information on the validity or revocation status of qualified certificates
Supports checking QCStatements that declare EU qualified-certificate status, certificate purpose, legal framework, and related qualified-certificate attributes.
The qcStatements certificate extension can contain any statement by the certificate issuer
3
Section 3
3. Review supervision, audits, security controls, and change triggers
The operational review should connect provider claims to the eIDAS supervision cycle. A must undergo a conformity-assessment-body audit at least every 24 months, notify its supervisory body at least one month before a planned audit, and submit the resulting report to that body within three working days of receipt. The law requires delivery to the supervisory body, not publication to customers, so record the report or scope statement only when it is lawfully made available.
The monitoring plan should also cover planned service changes, cessation, significant security incidents, supply-chain dependencies, and termination arrangements. A must notify its supervisory body at least one month before a change to a qualified service and at least three months before intended cessation. Reopen diligence when the relied-on service changes, its qualified status changes, or the provider announces cessation.
Ask for evidence of the latest conformity assessment cycle, the services in scope, the conformity assessment body, and whether any disclosed remediation affects the relied-on service. Accept a suitable assurance statement when the full report is confidential; do not describe customer access to the report as an eIDAS right.
Confirm that the provider knows which supervisory body is responsible and can explain how supervisory decisions update the .
Check the provider's information security policy, risk assessment approval, incident response process, monitoring and logging, business continuity controls, and post-incident review process.
Review the termination plan because eIDAS and ETSI requirements expect continuity of information needed to verify trust-service correctness after cessation.
For outsourced or cloud-supported service components, retain the provider's supply-chain control summary, relevant service-level commitments, and assurance that the remains responsible for its service.
Articles 20 and 24 support review of periodic audits, supervisory-body audits, remediation, qualified-status withdrawal, planned audits, service changes, cessation, and trusted-list updates.
audited at their own expense at least every 24 months
Supports security and operational checks for risk assessment, practice statements, terms, incident management, evidence collection, termination, compliance, and supply chain.
Supports the supervision lens for qualified trust services and the relationship between supervisory authorities, QTSPs, and conformity assessment.
guidelines on supervision of qualified trust service providers pursuant to Art.20
4
Section 4
4. Evidence to retain for QTSP selection and ongoing monitoring
Keep the record useful for a later customer question, audit, dispute, incident, or migration. The evidence should show why the provider and exact qualified service were acceptable at onboarding and what would trigger a new review.
For ongoing monitoring, separate static onboarding evidence from time-sensitive status evidence. Trusted-list status, service scope, revocation availability, incident posture, and material provider changes can change after the initial selection.
Provider and service identity: legal name, country, supervisory body, trusted-list entry, service type identifier, service name, service digital identity, current status, status start time, and relevant history.
Certificate evidence: sample certificates, chain-validation result, policy identifiers, CP/CPS links, QCStatements review, key-usage review, QWAC or signature/seal purpose review, and revocation or validity-status test result.
Policy evidence: terms and conditions, relying-party obligations, subscriber obligations, permitted uses, usage limits, revocation request route, incident contact, and support or escalation terms.
Assurance evidence: conformity-assessment scope, audit date or cycle evidence when available, disclosed remediation that affects the relied-on service, security and continuity summaries, supply-chain assurance, and termination-plan confirmation.
Monitoring triggers: trusted-list status change, certificate-policy change, service-scope change, supervisory notice, provider incident, revocation/OCSP/CRL availability failure, planned cessation, material outsourcing change, or product use-case change.
Supports retaining operational assurance evidence for risk assessment, incident handling, collection of evidence, termination planning, compliance, and supplier controls.
Collection of evidence
Recommended next step
Build a QTSP onboarding and monitoring record
Sorena can help structure the trusted-list checks, certificate evidence, policy review, supervision questions, and monitoring triggers into a reusable QTSP diligence record.
Primary legal source for QTSP status, supervision, trusted lists, EU trust mark, qualified-certificate issuance, revocation status, and supervisory withdrawal of qualified status.
Articles 21, 22, and 23 support checking service-specific qualified status, national trusted lists, and the EU trust mark before relying on a QTSP.
Article 24 and the certificate annexes support checks for identity verification, qualified certificates, certificate databases, revocation status, and relying-party validity information.
Show 1 more
Articles 20 and 24 support review of periodic audits, supervisory-body audits, remediation, qualified-status withdrawal, planned audits, service changes, cessation, and trusted-list updates.
"a trust service provider who provides one or more qualified trust services"
More quoted passages
"Qualified trust service providers may begin to provide the qualified trust service after the qualified status has been indicated in the trusted lists"
"provide to any relying party information on the validity or revocation status of qualified certificates"
"audited at their own expense at least every 24 months"
Trust-service provider policy source for risk assessment, practice statements, terms, information security, incident management, evidence collection, termination, compliance, and supply-chain checks.
Supports security and operational checks for risk assessment, practice statements, terms, incident management, evidence collection, termination, compliance, and supply chain.
Supports retaining operational assurance evidence for risk assessment, incident handling, collection of evidence, termination planning, compliance, and supplier controls.
"General Policy Requirements for Trust Service Providers"
Technical source for validating provider and service status through trusted-list fields, the List Of Trusted Lists, service status, and service history.
Defines trusted-list fields used for QTSP diligence, including TSP information, service type, current status, status start time, service digital identity, and history.
Supports retaining trusted-list status and history evidence because the list is used to determine service status at the time of reliance.
"Trusted lists therefore contain not only the service's current status, but also the history of its statuses."
Certificate-profile source for reviewing QCStatements in EU qualified certificates, including certificate purpose and applicable legal framework.
Supports checking QCStatements that declare EU qualified-certificate status, certificate purpose, legal framework, and related qualified-certificate attributes.
"Requirements on QCStatements in EU qualified certificates"
More quoted passages
"The qcStatements certificate extension can contain any statement by the certificate issuer"