Validate a by checking the signature result, the qualified certificate, the issuing , trusted-list status, indication, signed-data integrity, and security-relevant issues.
This page is a relying-party checklist for accepting or rejecting a QES validation result and retaining evidence that can be rechecked later.
Validate a under eIDAS by confirming that its supporting certificate was qualified and valid at signing time and issued by a qualified trust service provider. Check that the validation data matches the data provided to the relying party, that the signatory data and any pseudonym are correctly shown, that a qualified electronic signature creation device created the signature, that the signed data remains intact, and that the Article 26 requirements were met at signing. The validation system must return the correct result and let the relying party detect security-relevant issues. A visible PDF signature panel alone does not prove that those checks passed.
Article 32 of Regulation (EU) No 910/2014 sets the validation requirements for qualified electronic signatures. A relying party should treat the output as a technical conclusion about the Article 32 conditions. Whether to accept the transaction can still depend on authority, intent, contract rules, required form, and other case-specific law.
The check should be anchored at the time of signing. A certificate can be revoked later, but QES validation still needs evidence about whether the certificate was qualified, issued by a , and valid at the relevant signing time.
Keep the signature classes separate. An electronic signature cannot be denied legal effect solely because it is electronic or is not qualified. An advanced electronic signature must meet Article 26, but it is a QES only when it also uses a qualified certificate and a creation device. An advanced signature based on a qualified certificate is therefore not automatically a QES.
Sources (1)
Defines electronic, advanced, and qualified signature classes, the legal effect of a QES, and the validation conditions, including certificate qualification, QTSP issuance, validation data, signatory data, QSCD use, integrity, and Article 26 requirements.
Requirements for the validation of qualified electronic signatures
The trusted-list check is the control that prevents a relying party from accepting a certificate as qualified only because a vendor label says it is. ETSI explains that EU Member State trusted lists include qualified trust service providers and their qualified trust services, and that the Commission publishes a central List Of Trusted Lists for access to Member State lists.
For QES validation, retain the trusted-list status used by the validator: the Member State list or LOTL source, the service type, the service status and history, the qualified certificate status, and the time at which the trust-list evidence was evaluated.
Sources (3)
Explains that EU trusted lists contain supervised qualified trust service providers and services, and that listed qualified services are necessary for users to benefit from the legal effect associated with a qualified trust service.
Trusted lists are essential elements in building trust
Machine-processable central List Of Trusted Lists location referenced by ETSI for accessing Member State trusted-list locations.
List Of Trusted Lists
Technical specification for trusted-list format and content, including TSP information, service information, current status, status dates, history, and pointers to other trusted lists.
Trusted Lists
Certificate validation should capture both current cryptographic checks and signing-time context. eIDAS requires the certificate to have been qualified, -issued, and valid at signing time; the certificate also needs usable validity or revocation status information.
A validator may report a certificate as currently revoked yet still reach a valid signature conclusion when reliable proof of existence shows that the signature existed before revocation. This is validation-policy and evidence dependent. The report must expose the time evidence, revocation facts, and trusted-list history instead of treating later revocation as automatically harmless.
Sources (2)
Requires qualified certificate issuers to register revocations, publish revocation status promptly, and provide validity or revocation status information to relying parties.
provide to any relying party information on the validity or revocation status
Shows how DSS detailed reports separate signature, timestamp, revocation-data, and validation-process indications, including examples where current revocation does not automatically decide the overall result.
Interpreting a detailed report
The European Commission's Digital Signature Service (DSS) reports make the validation decision inspectable. The detailed report separates validation processes from building blocks, so a relying party can see whether a failure came from the signature, a timestamp, revocation data, certificate validation, or trusted-list interpretation.
For QES acceptance, do not retain only a green banner or a PDF viewer screenshot. Retain the diagnostic data, detailed report, validation policy or constraints, trusted-list source, certificate path, revocation responses, timestamp evidence, and the final indication that the signature was qualified.
Sources (2)
Documents DSS validation reports, validation processes, building blocks, best-signature-time logic, qualification determination, and evidence-record support.
The overall validation result is then provided as the indication returned by the validation process
Distinguishes a qualified validation service from ordinary tool use by requiring a QTSP, Article 32 validation, automated relying-party results, and the provider's advanced signature or seal on the result.
Qualified validation service for qualified electronic signatures
The retained evidence should let a later reviewer reproduce why the signature was accepted as qualified. It must show that the validation result supports the eIDAS conditions at the relevant time, rather than merely showing that the document contains a signature.
If the business depends on the signature's qualified status, store validation evidence with the transaction record. Do not leave the only copy inside a temporary signing platform. Re-run validation when the signed object, detached contents, trust-list configuration, validation policy, or certificate status evidence changes.
No. The visible panel is not enough by itself. The relying party needs a validation result that addresses eIDAS Article 32 checks, including certificate qualification, issuance, certificate validity at signing time, validation data, signatory data, use, signed-data integrity, and security-relevant issues.
No. A valid Article 32 result establishes that the electronic signature met the qualified validation conditions. The relying party must still decide whether the signatory had authority and capacity, intended the transaction, satisfied any contract or sector-specific form rule, and met the relying party's acceptance policy.
Save the signed object, detached content if used, validation report, diagnostic data, trusted-list and status evidence, certificate chain, revocation responses, timestamp or best-signature-time evidence, indication, final qualification result, validator configuration, and acceptance or rejection record.
Sources (3)
Provides the legal checklist that retained validation evidence should support, the QES legal-effect rule, and the boundary preserving Union or national rules on contract formation, validity, and legal obligations.
shall provide to the relying party the correct result of the validation process
Supports retaining detailed reports, diagnostic data, trusted-list interpretation, timestamp evidence, and evidence records for later verification.
Signature validation and reports
Supports keeping trusted-list evidence because qualified provider and service status is established through Member State trusted lists.
For EU countries the information on CAs issuing qualified certificates are held in Trusted Lists
Sorena can help turn the eIDAS QES validation checks on this page into reusable evidence requests, review steps, and acceptance criteria for relying-party workflows.
Ask questions tied to cited sources about QES validation, QTSP status, trusted lists, and retained validation evidence.
Check whether your validation process captures the certificate, trusted-list, revocation, report, and acceptance evidence needed for later review.
"Digital Signature Service"
"Interpreting a detailed report"
"The overall validation result is then provided as the indication returned by the validation process"
"Signature validation and reports"
"Trusted lists are essential elements in building trust"
"For EU countries the information on CAs issuing qualified certificates are held in Trusted Lists"
"Electronic Signatures and Trust Infrastructures (ESI); Trusted Lists"
"Trusted Lists"
"List Of Trusted Lists"
"Requirements for the validation of qualified electronic signatures"
"provide to any relying party information on the validity or revocation status"
"Qualified validation service for qualified electronic signatures"
"shall provide to the relying party the correct result of the validation process"
"Requirements for the validation of qualified electronic signatures"
eIDAS 2 calendar separating binding EUDI Wallet, reporting, and trust-service dates from implementation milestones and technical programme updates.
Compare the original eIDAS electronic identification and trust-service framework with the eIDAS 2.0 amendments for EUDI Wallets, relying parties, attestations, QWACs, and supervision.
Official source guide to eIDAS qualified certificates, website authentication certificates, trusted lists, relying-party checks, and validation evidence.
Build an eIDAS evidence pack for qualified trust services, electronic signatures, trusted-list checks, certificate validation, supervisory records, and EUDI Wallet relying-party controls.
Official source eIDAS compliance guide for trust-service classification, QTSP supervision evidence, qualified signatures, seals, time stamps, certificates, trusted-list validation, and EUDI Wallet relying-party records.
An official source guide to eIDAS electronic-signature legal effect: SES, AES, QES, qualified certificates, QTSP trusted-list checks, validation, recognition, and evidence records.
Guide to eIDAS Article 16 fine floors, national penalty rules, supervisory action, qualified-status withdrawal, and trusted-list evidence.
How to select an EU eIDAS qualified trust service provider: identify the qualified service type, verify trusted-list status, review supervision evidence, and retain certificate-policy records.
Source-grounded guide to eIDAS remote signature controls: remote QSCD scope, server-side signing, QTSP evidence, signer authentication, certificate validation, and trusted-list checks.
Compare eIDAS signature levels by legal effect, governing form rules, qualified certificate status, QTSP evidence, QSCD use, validation, and public-service recognition.
Classify an eIDAS role by evidence: trust service provider, qualified trust service provider, signature or seal validator, EUDI Wallet relying party, relying party, or customer of a QTSP.
How to validate EU eIDAS trusted-list evidence: start from the Commission LOTL, confirm QTSP and qualified-service status, check certificate path and revocation data, and retain validation reports.
Compare eIDAS with ESIGN and UETA for electronic signatures, qualified certificates, trust services, cross-border recognition, validation evidence, and source gaps.
Compare eIDAS and ETSI EN 319 401 for trust services: legal scope, QTSP supervision, conformity assessment, audits, incident evidence, and operational controls.
Compare eIDAS identity, trust-service, and EUDI Wallet rules with GDPR duties for personal-data processing, minimisation, lawful basis, evidence, security, and user rights.
Compare eIDAS trust-service and QTSP duties with NIS2 cybersecurity risk-management, incident reporting, supervision, and evidence duties for trust service providers.
Official source guide to electronic attestations of attributes under amended EU eIDAS: EAA, QEAA, public-sector authentic-source attestations, wallet use, issuer checks, relying-party validation, revocation, and legal effect.
An official source eIDAS scope test for QTSPs, trust services, electronic signatures, seals, timestamps, QWACs, EUDI Wallet relying parties, and cross-border recognition evidence.
Checklist for eIDAS trust-service and EUDI Wallet controls: qualified status, trusted lists, certificates, signatures, seals, timestamps, validation evidence, and relying-party records.
FAQ on eIDAS trust services and the European Digital Identity framework, covering advanced and qualified electronic signatures, QTSP status, trusted lists, QWACs, EUDI Wallet relying parties, attestations of attributes, and validation evidence.
How qualified trust service providers obtain and keep qualified status under eIDAS, including conformity assessment reports, supervision, trusted lists, incidents, and evidence.
Check a qualified trust service provider under eIDAS by validating trusted-list status, qualified service scope, certificates, policies, supervision, audits, and retained evidence.
Official source guide to core eIDAS requirements for trust service providers, qualified trust services, electronic signatures, seals, time stamps, trusted lists, and EUDI Wallet relying parties.
Readiness guide for organisations preparing to request or verify data from European Digital Identity Wallets: roles, registration, ARF alignment, selective disclosure, implementing acts, and evidence.
Prepare an eIDAS wallet-relying-party registration, intended-use record, access-certificate controls, attribute request, validation evidence, and intermediary safeguards.
What eIDAS Article 5b and the EUDI Wallet ARF say about wallet relying party registration, intended uses, attribute requests, certificates, evidence, and Member State gaps.
Technical guide to the EUDI Wallet architecture: ARF roles, wallet units, PID and attestations, relying parties, trust model, certificates, protocols, privacy, and security controls.
A source-grounded guide to qualified website authentication certificates under eIDAS, covering Annex IV data, trusted lists, browser recognition, validation evidence, and QTSP checks.
A source-grounded guide to the systems and services covered by EU eIDAS: notified electronic identification, trust services, signatures, seals, time stamps, registered delivery, website authentication, trusted lists, the EUDI Wallet, and attribute attestations.
What electronic attestations of attributes mean under eIDAS, how QEAAs differ from public-sector and non-qualified attestations, and what issuers, wallets, and relying parties should verify.
How EU eIDAS Trusted Lists and the Commission LOTL support QTSP and qualified trust-service validation, with practical evidence checks for relying parties.
What EUDI Wallet relying parties must do under eIDAS, when the harmonised registration rules apply, and how to control requested data, identification, validation, and evidence.
Compare qualified electronic signatures (QES) and advanced electronic signatures (AdES) under EU eIDAS, including legal effect, qualified certificates, QTSP status, QSCDs, and validation evidence.
How to verify QTSP status under eIDAS using the qualified service, supervisory body decision, trusted list entry, conformity assessment evidence, and service-specific records.
Plain-language FAQ on qualified website authentication certificates under eIDAS, including website identity, QTSP trusted-list checks, browser recognition, and validation evidence.