--- title: "EU eIDAS FAQ: signatures, QTSPs, trusted lists, QWACs, wallets, and validation" canonical_url: "https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/items" author: "Sorena AI" description: "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." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "EU eIDAS" - "qualified electronic signature" - "advanced electronic signature" - "qualified trust service provider" - "trusted lists" - "QWAC" - "EUDI Wallet" - "electronic attestations of attributes" - "validation" - "EU eIDAS Regulation" - "electronic signatures" - "qualified trust services" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU eIDAS FAQ: signatures, QTSPs, trusted lists, QWACs, wallets, and validation 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. *FAQ* *EU* ## EU eIDAS Regulation FAQ for trust services and wallets Answers to common eIDAS questions about advanced and qualified electronic signatures, qualified trust service providers, trusted lists, qualified website authentication certificates, EUDI Wallet relying parties, attestations of attributes, and validation. Use this page to separate legal effect, technical validation, trust-list status, wallet registration, and evidence records before accepting a signature, certificate, attestation, or wallet presentation. eIDAS covers electronic identification and trust services for electronic transactions in the EU internal market. This FAQ focuses on the checks a product, legal, security, or compliance team can perform before relying on an electronic signature, qualified certificate, trusted-list entry, website authentication certificate, EUDI Wallet presentation, or electronic attestation of attributes. ## Browse sub-FAQ modules ### [EU eIDAS attribute attestations: EAA, QEAA, wallet, and relying party checks](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/attribute-attestations.md) 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. - 3 items ### [EU eIDAS Trusted Lists FAQ: LOTL, QTSP status, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/trusted-lists.md) How EU eIDAS Trusted Lists and the Commission LOTL support QTSP and qualified trust-service validation, with practical evidence checks for relying parties. - 3 items ### [EUDI Wallet Relying Parties under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md) What EUDI Wallet relying parties must do under eIDAS: register, declare intended wallet use and requested data, identify themselves to users, and keep request evidence. - 4 items ### [QES vs AdES under EU eIDAS: legal effect, certificates, QTSPs, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qes-vs-ades.md) Compare qualified electronic signatures (QES) and advanced electronic signatures (AdES) under EU eIDAS, including legal effect, qualified certificates, QTSP status, QSCDs, and validation evidence. - 3 items ### [What is a qualified trust service provider under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qualified-trust-service-provider.md) How to verify QTSP status under eIDAS using the qualified service, supervisory body decision, trusted list entry, conformity assessment evidence, and service-specific records. - 3 items ### [What is a QWAC under the EU eIDAS Regulation?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qwac.md) Plain-language FAQ on qualified website authentication certificates under eIDAS, including website identity, QTSP trusted-list checks, browser recognition, and validation evidence. - 3 items Browse all indexed questions: [/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/items](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/items.md) ## All FAQ items *Page 1 of 1. Showing 19 of 19 items.* ### [What is an electronic attestation of attributes under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/attribute-attestations.md#what-is-an-electronic-attestation-of-attributes-under-eidas) *Module: [EU eIDAS attribute attestations: EAA, QEAA, wallet, and relying party checks](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/attribute-attestations.md)* An electronic attestation of attributes is a regulated way to prove facts about a natural or legal person through the eIDAS trust-service framework. eIDAS covers electronic attestation of attributes alongside signatures, seals, timestamps, electronic documents, registered delivery, website authentication, archiving, and electronic ledgers. - Treat EAA as attribute proof, not automatically as electronic identification. - Classify the attestation as non-qualified EAA, QEAA, or public-sector authentic-source EAA before relying on it. - For a QEAA, verify that the attestation identifies the qualified trust service provider, the subject, the attested attributes and their scope, validity period, unique attestation identity code, qualified signature or seal, supporting certificate location, and validity-status service. - For a public-sector authentic-source EAA, verify the issuing public body, the authentic-source basis, the subject, the attested attributes, validity period, identity code, qualified signature or seal, supporting certificate, and status-check location. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS), consolidated with the European Digital Identity amendments](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Supports the legal effect of EAAs and the Annex V and Annex VII content requirements for QEAAs and public-sector authentic-source attestations. - [Regulation (EU) 2024/1183 establishing the European Digital Identity Framework](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng?ref=sorena.io) - Amends eIDAS to add the European Digital Identity Wallet framework and the attribute-attestation provisions. ### [Who can issue QEAAs and authentic-source attestations?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/attribute-attestations.md#who-can-issue-qeaas-and-authentic-source-attestations) *Module: [EU eIDAS attribute attestations: EAA, QEAA, wallet, and relying party checks](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/attribute-attestations.md)* A QEAA is issued by a qualified trust service provider and must be able to show, in machine-processable form, that it is a qualified electronic attestation of attributes. eIDAS also requires Member States to make measures available so qualified trust service providers can verify certain public-sector attributes electronically, at the user's request, against authentic sources or recognised intermediaries. - For QEAAs, check the qualified trust service provider identity and whether the service has qualified status for the relevant attestation service. - For public-sector authentic-source attestations, check whether the public body is responsible for the authentic source or designated to act on its behalf. - For attributes such as address, age, nationality or citizenship, educational and professional qualifications, mandates, permits, licences, and company data, check whether the attribute relies on a public-sector authentic source and whether electronic verification is available. - Do not accept issuer branding alone as proof of authority; check the attestation category, certificate, signature or seal, status information, and relevant trusted-list or registry information. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS), consolidated with the European Digital Identity amendments](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Supports issuer distinctions for QEAAs, authentic-source public-sector attestations, revocation effects, and the minimum list of attributes in Annex VI. - [ETSI - Certification Authorities and other Trust Service Providers](https://portal.etsi.org/TB-SiteMap/ESI/Trust-Service-Providers?ref=sorena.io) - Explains the trust-service-provider and trusted-list context used to check qualified trust services under eIDAS. - [ETSI TS 119 612 trusted lists](https://www.etsi.org/standardssearch?ref=sorena.io) - Supports the relying-party need to authenticate and trust EU trusted lists and the Commission List of Trusted Lists when checking trust-service status. ### [How should wallets and relying parties use attribute attestations?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/attribute-attestations.md#how-should-wallets-and-relying-parties-use-attribute-attestations) *Module: [EU eIDAS attribute attestations: EAA, QEAA, wallet, and relying party checks](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/attribute-attestations.md)* For wallet use, eIDAS requires providers of electronic attestations of attributes to let EUDI Wallet users request, obtain, store, and manage attestations regardless of the Member State where the wallet is provided. Providers of QEAAs and public-sector authentic-source attestations must provide an interface with EUDI Wallets. - Authenticate the relying party before the wallet presents attributes, and show the user whether the relying party is registered to receive the requested attributes. - Request only attributes needed for the service, because selective disclosure and user approval are core wallet controls. - Verify the issuer is authorised to issue the relevant attestation type; where available, inspect the issuer registration certificate or query the relevant registry. - Check whether the attestation or its signing certificate has been revoked, because revoked QEAAs and public-sector authentic-source attestations lose validity from revocation and status must not revert. - Keep the relying-party purpose, requested attributes, user approval, issuer authority check, certificate and status-check result, attestation validity period, and revocation outcome together as evidence of the relying decision. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS), consolidated with the European Digital Identity amendments](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Supports wallet-interface duties, public-service substitution limits, revocation effects, and the separation rules for EAA service providers. - [Commission Implementing Regulation (EU) 2024/2977 on PID and electronic attestations of attributes for EUDI Wallets](https://eur-lex.europa.eu/eli/reg_impl/2024/2977/oj/eng?ref=sorena.io) - Supports wallet requirements for requesting, storing, deleting, sharing, and presenting PID and EAAs, plus validity-status and revocation-management details. - [European Commission - EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - Supports relying-party, wallet, issuer-authorisation, selective-disclosure, user-control, and attestation-revocation checks in the EUDI Wallet ecosystem. ### [What do EU eIDAS Trusted Lists prove?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/trusted-lists.md#what-do-eu-eidas-trusted-lists-prove) *Module: [EU eIDAS Trusted Lists FAQ: LOTL, QTSP status, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/trusted-lists.md)* An eIDAS Trusted List is evidence of supervised qualified status for a specific trust service provider and service, not a general approval of every certificate, product, or business process the provider offers. - Check the Member State responsible for the provider and use the current national trusted list reached through the Commission's published trusted-list information or LOTL tooling. - Match the legal provider name and service name to the exact trusted-list entry instead of relying only on a brand, reseller, or certificate common name. - Confirm the service type is the one needed for the use case, such as qualified certificate issuance, qualified timestamping, qualified electronic registered delivery, or qualified website authentication. - Record the service current status and status starting date/time because a status change can affect whether the evidence supports the transaction at the validation time. - Treat non-qualified or nationally defined services separately when a list includes them; the 2015 trusted-list implementing decision says they must be clearly indicated as not qualified under eIDAS. Sources for this answer: - [Regulation (EU) No 910/2014 - Article 22 Trusted Lists](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 22 requires Member States to establish, maintain, and publish trusted lists for qualified trust service providers and their qualified trust services. - [Commission Implementing Decision (EU) 2015/1505 on trusted-list specifications](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32015D1505&ref=sorena.io) - The implementing decision supports the distinction between qualified services and non-qualified services that Member States may include voluntarily. - [ETSI TS 119 612 Trusted Lists](https://www.etsi.org/standardssearch?ref=sorena.io) - ETSI TS 119 612 defines the trusted-list structure used for provider information, service information, service type identifiers, current status, and status starting date/time. ### [How should LOTL and Member State list checks be captured?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/trusted-lists.md#how-should-lotl-and-member-state-list-checks-be-captured) *Module: [EU eIDAS Trusted Lists FAQ: LOTL, QTSP status, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/trusted-lists.md)* The Commission makes Member State trusted-list publication information available, and ETSI TS 119 612 describes the Commission's central List Of Trusted Lists as a set of links to national trusted-list locations. - Capture the LOTL or Commission trusted-list browser/tooling reference used to locate the Member State list. - Capture the national trusted-list location, scheme territory, scheme operator, and list signing or sealing evidence where available from the validation tool. - Save the provider entry, service entry, service digital identity, service type identifier, service current status, and service status start time used in the decision. - Keep the validation tool output, detailed report, or diagnostic data that connects the certificate or signature to the trusted-list trust anchor. - Avoid closing a validation question with only a screenshot of a supplier web page, an EU trust mark, or a procurement questionnaire answer. Sources for this answer: - [Regulation (EU) No 910/2014 - Article 22 Trusted Lists](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 22 requires secured, electronically signed or sealed trusted lists suitable for automated processing and Commission publication of notified list information. - [ETSI TS 119 612 Trusted Lists](https://www.etsi.org/standardssearch?ref=sorena.io) - The specification grounds practical evidence fields such as scheme information, pointers to other trusted lists, TSP information, service information, current status, and status start time. - [European Commission eSignature building block](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109036/eSignature?ref=sorena.io) - The Commission eSignature page identifies the eIDAS Dashboard resources, including the Trusted List Browser used to search for qualified trust service providers in Europe. ### [When is Trusted List evidence not enough by itself?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/trusted-lists.md#when-is-trusted-list-evidence-not-enough-by-itself) *Module: [EU eIDAS Trusted Lists FAQ: LOTL, QTSP status, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/trusted-lists.md)* Trusted-list status is necessary for qualified-status checks, but relying-party validation still has to connect that status to the actual signature, seal, timestamp, certificate, or website-authentication certificate being relied on. - Do not treat a provider-level qualified status as proof that the particular service, certificate profile, or timestamp token is qualified. - Do not treat a current status lookup as proof for a past transaction unless the validation report addresses the relevant signing or best-signature time and revocation evidence. - Refresh the trusted-list evidence when the provider, service entry, Member State, certificate chain, validation policy, or service status changes. - Escalate discrepancies between supplier claims, certificate metadata, validation-tool output, and the trusted-list entry before relying on the result in a regulated workflow. - For QWAC or SSL-certificate validation, preserve the certificate validation evidence and the trusted-list qualification evidence together, because both are needed to explain the relying-party conclusion. Sources for this answer: - [Regulation (EU) No 910/2014 - Article 21 initiation of a qualified trust service](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 21 ties the start of providing a qualified trust service to qualified status being indicated in the trusted list. - [Regulation (EU) No 910/2014 - Article 20 supervision and withdrawal](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 20 supports refreshing evidence when qualified status is withdrawn for a provider or affected service and the trusted list must be updated. - [European Commission DSS Demonstration WebApp](https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/home?ref=sorena.io) - The DSS demo and documentation hub grounds practical validation evidence such as signature validation, certificate validation, SSL-certificate validation, multiple LOTL/TL loading, revocation handling, validation reports, and diagnostic data. ### [Who is an EUDI Wallet relying party under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md#who-is-an-eudi-wallet-relying-party-under-eidas) *Module: [EUDI Wallet Relying Parties under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md)* A relying party is the service provider side of a wallet interaction: a public or private organisation that requests data from a user's EU Digital Identity Wallet before granting access to a service, verifying a customer, enrolling a student, checking a professional mandate, or receiving a digital document. - Treat the role as triggered by wallet reliance, not by the organisation's sector label. - Map each wallet use case to the service being provided, the establishment Member State, and the specific wallet data needed. - Distinguish a relying party from wallet providers, PID providers, and attestation providers; the relying party is the service side requesting and receiving presented data. - If an intermediary acts on behalf of the relying party, Article 5b treats the intermediary as a relying party and restricts it from storing transaction-content data. Sources for this answer: - [Regulation (EU) 2024/1183 establishing the European Digital Identity Framework](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng?ref=sorena.io) - Recital 17 and Article 5b ground the relying-party registration trigger and the distinction between registration and pre-authorisation. - [European Commission - Wallet for service providers](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/881984674/Wallet+for+service+providers?ref=sorena.io) - Commission service-provider guidance describes service providers as organisations requesting data from a wallet before granting service access. - [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - The ARF explains the technical relying-party role as a service provider requesting wallet attributes subject to user approval. ### [What must be registered before requesting wallet data?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md#what-must-be-registered-before-requesting-wallet-data) *Module: [EUDI Wallet Relying Parties under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md)* Article 5b requires the relying party to register in the Member State where it is established. The registration must include information needed for the party to authenticate to EUDI Wallets, contact details, and the intended wallet use, including the data the relying party will request from users. - Registration jurisdiction: the Member State where the relying party is established. - Identity material: information needed to authenticate the relying party to wallets, including name and official registration details where applicable. - Contact details: the public contact record associated with the wallet relying-party registration. - Purpose and data list: the intended use of the wallet and the user data or attributes to be requested. - Change control: notify the Member State without delay when registration information changes. Sources for this answer: - [Regulation (EU) 2024/1183 establishing the European Digital Identity Framework](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng?ref=sorena.io) - Article 5b lists the registration fields and prohibits requests for data beyond the registered indication. - [European Commission - Wallet for service providers](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/881984674/Wallet+for+service+providers?ref=sorena.io) - Commission guidance restates the practical registration, intended-use, requested-data, no-extra-data, and change-notification obligations for service providers. ### [How should the wallet interaction work for users?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md#how-should-the-wallet-interaction-work-for-users) *Module: [EUDI Wallet Relying Parties under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md)* The relying party should authenticate and identify itself to the user, request only the registered data needed for the service, and let the wallet present the specific requested data before the user confirms. Article 5b also makes the relying party responsible for authenticating and validating the person identification data and electronic attestations of attributes it requests from wallets. - Show the relying-party identity before requesting wallet data. - Display the specific PID fields, attestations, or attributes being requested for the transaction. - Allow the user to confirm or refuse the presentation through the wallet flow. - Validate the authenticity and validity of received PID or EAA data before relying on it. - Accept pseudonyms where Union or national law does not require identification of the user. Sources for this answer: - [Regulation (EU) 2024/1183 establishing the European Digital Identity Framework](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng?ref=sorena.io) - Article 5b assigns user identification, PID/EAA validation, and pseudonym acceptance duties to relying parties. - [European Commission - Wallet for service providers](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/881984674/Wallet+for+service+providers?ref=sorena.io) - The Commission service-provider flow describes wallet display of requested data and user confirmation before service access or document presentation. - [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - The ARF explains technical request controls, including registered attributes, user approval, and wallet warnings for requests outside registered scope. ### [What evidence should a relying party keep?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md#what-evidence-should-a-relying-party-keep) *Module: [EUDI Wallet Relying Parties under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md)* A useful relying-party evidence record should prove that the live wallet request matches the registered purpose and data list. It should also show that the user saw who was requesting the data, what data was requested, and which validation procedure the service applied to the wallet response. - Member State registration record, relying-party name, official registration details where applicable, and contact details. - Registered intended use, requested PID fields or attestation attributes, and the product/service feature that uses each item. - Wallet request configuration, relying-party authentication material, and evidence that the request displays the relying-party identity to the user. - Validation procedure for PID and electronic attestations of attributes, including what is checked before granting service access. - Change log showing when a new service, purpose, data field, intermediary, or establishment fact triggered registration review. - Data-retention note explaining which transaction elements are discarded when no longer needed to reduce linkability and over-collection risk. Sources for this answer: - [Regulation (EU) 2024/1183 establishing the European Digital Identity Framework](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng?ref=sorena.io) - Article 5b supports the evidence fields for registration, change notification, relying-party identification, validation, pseudonym acceptance, and intermediary limits. - [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - The ARF grounds evidence for registered attributes, user approval, and retention controls that reduce relying-party linkability risk. ### [What is the practical difference between a QES and an AdES under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qes-vs-ades.md#what-is-the-practical-difference-between-a-qes-and-an-ades-under-eidas) *Module: [QES vs AdES under EU eIDAS: legal effect, certificates, QTSPs, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qes-vs-ades.md)* An AdES is the eIDAS signature level defined by the four Article 26 requirements: signer linkage, signer identification, signer-control of creation data, and data-integrity linkage. It can be strong evidence, but eIDAS does not give it automatic equivalence to a handwritten signature. - Use AdES language when the evidence question is whether the signer can be identified, the signature is linked to the signed data, and later changes are detectable. - Use QES language only when the record proves the qualified certificate, the qualified trust service provider, the qualified creation device, and the Article 26 AdES requirements. - Do not call a signature QES merely because it uses a digital certificate, a strong login, an audit trail, or a vendor label. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS)](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 3 defines AdES and QES, Article 25 states the legal effects, and Article 26 lists the four AdES requirements. ### [What must be checked before relying on QES status?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qes-vs-ades.md#what-must-be-checked-before-relying-on-qes-status) *Module: [QES vs AdES under EU eIDAS: legal effect, certificates, QTSPs, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qes-vs-ades.md)* For QES, the signature validation record should prove more than successful cryptographic verification. It should show that the supporting certificate was a qualified certificate at the time of signing, that it was issued by a qualified trust service provider and valid at that time, that the validation data matched what was provided to the relying party, and that the signed data's integrity was not compromised. - Keep the signed object or detached signed data with the exact signature package that was validated. - Keep the validation report showing the result, validation time or best-signature-time, certificate chain, revocation status, and security-relevant warnings. - Keep evidence that the certificate was qualified for electronic signature, issued by a QTSP, and valid at the time of signing. - Keep evidence that the signature was created by a QSCD or remote QSCD service where QES status is claimed. - Keep the trusted-list or LOTL evidence used to establish the QTSP, qualified service, certificate, and QSCD status. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS)](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Articles 22, 28, 29, and 32 support the trusted-list, qualified-certificate, QSCD, and qualified-validation checks needed for QES reliance. - [Commission Implementing Decision (EU) 2015/1505 on trusted lists](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32015D1505&ref=sorena.io) - Explains how Member State trusted lists identify qualified trust services, qualified certificate status, and QSCD-related qualifiers. - [European Commission eSignature building block](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109036/eSignature?ref=sorena.io) - Identifies Commission eSignature resources, including the eIDAS Dashboard, Trusted List Browser, and validation tooling for signature verification work. ### [When is AdES enough, and when should a team require QES?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qes-vs-ades.md#when-is-ades-enough-and-when-should-a-team-require-qes) *Module: [QES vs AdES under EU eIDAS: legal effect, certificates, QTSPs, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qes-vs-ades.md)* AdES may be enough where the applicable contract, service design, risk analysis, or law only requires strong evidence of signer identity, signer control, and document integrity. eIDAS preserves the admissibility of non-qualified electronic signatures, but their probative value is assessed from the evidence around the transaction. - For AdES, document the identity proofing and authentication method, signer intent, signer-control evidence, signed-data hash or signature linkage, and tamper-detection result. - For QES, add qualified certificate details, QTSP/trusted-list status, QSCD or remote QSCD evidence, certificate validity or revocation status at signing, and the qualified validation result. - For advanced signatures based on qualified certificates, do not assume QES: eIDAS Article 32a has validation requirements for that middle case, but it lacks the QSCD requirement that distinguishes QES. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS)](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 25 preserves admissibility for electronic signatures generally, Article 32 validates QES, and Article 32a covers AdES based on qualified certificates. ### [When is a provider a QTSP under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qualified-trust-service-provider.md#when-is-a-provider-a-qtsp-under-eidas) *Module: [What is a qualified trust service provider under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qualified-trust-service-provider.md)* A provider is a qualified trust service provider only when it provides one or more qualified trust services and the supervisory body has granted qualified status. The check must cover both levels: the legal entity and the exact service, such as a qualified certificate, qualified timestamp, qualified electronic registered delivery service, qualified validation service, qualified preservation service, qualified electronic attestation of attributes, qualified electronic archiving service, qualified electronic ledger, or qualified remote management of signature or seal creation devices. - Identify the exact qualified trust service used by the workflow, not only the supplier name. - Confirm the Member State supervisory body that granted qualified status. - Check that qualified status applies to the current service, certificate policy, and relying-party use case. - Separate qualified status from adjacent claims such as advanced signatures, non-qualified certificates, hosting, remote signing software, or reseller support. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS), consolidated text](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Defines a qualified trust service provider and sets the Article 21 initiation route for qualified trust services. - [Regulation (EU) No 910/2014 (eIDAS), trusted lists](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 22 requires Member States to publish trusted lists covering QTSPs and the qualified trust services for which they are responsible. ### [How should a relying party verify QTSP status?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qualified-trust-service-provider.md#how-should-a-relying-party-verify-qtsp-status) *Module: [What is a qualified trust service provider under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qualified-trust-service-provider.md)* Start with the relevant trusted list, not with the contract. Each Member State establishes, maintains, and publishes a secured trusted list in a form suitable for automated processing, and the Commission makes trusted-list publication information available through a secure channel. The Commission eSignature building block also points users to the Trusted List Browser for searching qualified trust service providers in Europe. - Use the Commission trusted-list access point or the national trusted list for the provider's Member State. - Record the provider legal name, service name, service type identifier, Member State, service digital identity, current status, and status start date shown in the trusted-list evidence. - Confirm that the status supports the specific outcome you need, such as a qualified certificate for electronic signature, qualified electronic timestamp, QWAC, or qualified validation service. - Keep a dated capture or machine-readable validation result because trusted-list service status can change. - If the workflow depends on long-lived evidence, define how often the trusted-list source and certificate status information are refreshed. Sources for this answer: - [European Commission Digital Building Blocks - eSignature](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109036/eSignature?ref=sorena.io) - Commission eSignature hub references the eIDAS Dashboard and Trusted List Browser used to search qualified trust service providers in Europe. - [ETSI TS 119 612 - Trusted Lists](https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.03.01_60/ts_119612v020301p.pdf?ref=sorena.io) - Explains trusted-list structure and how trusted-list information supports certificate path validation and trust-anchor management. - [Regulation (EU) No 910/2014 (eIDAS), trusted lists](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 22 establishes Member State trusted-list publication and Commission publication of trusted-list location information. ### [What supervision and operating evidence matters?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qualified-trust-service-provider.md#what-supervision-and-operating-evidence-matters) *Module: [What is a qualified trust service provider under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qualified-trust-service-provider.md)* QTSP status is supervised, not self-declared. eIDAS requires qualified trust service providers to be audited at their own expense at least every 24 months by a conformity assessment body, with the conformity assessment report submitted to the supervisory body within three working days of receipt. Supervisory bodies may also audit or require additional conformity assessment at any time. - Conformity assessment report scope, date, assessment body, and the qualified services covered. - Supervisory body grant or withdrawal evidence and any conditions, remediation requests, or change approvals. - Policies for identity verification, attribute verification, certificate issuance, revocation, status services, cryptographic controls, logging, staff competence, subcontractors, and termination. - Incident and disruption notifications where the event significantly affects the trust service or personal data maintained in the service. - Contract and architecture evidence showing the deployed product uses the listed qualified service, not a non-qualified variant or separate reseller service. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS), supervision of QTSPs](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 20 sets recurring conformity assessment and supervisory powers for qualified trust service providers. - [Regulation (EU) No 910/2014 (eIDAS), QTSP requirements](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 24 covers QTSP duties including identity checks, trustworthy systems, incident notification, records, termination planning, and certificate revocation status. - [ENISA - Guidelines on Supervision of Qualified Trust Services](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - ENISA guidance supports supervisory practice and technical oversight of qualified trust service providers. - [ETSI EN 319 401 - General Policy Requirements for Trust Service Providers](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - ETSI baseline policy standard for trust service providers, useful for mapping operational controls to TSP evidence. ### [What does a QWAC prove under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qwac.md#what-does-a-qwac-prove-under-eidas) *Module: [What is a QWAC under the EU eIDAS Regulation?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qwac.md)* A certificate for website authentication makes it possible to authenticate a website and link that website to the natural or legal person to whom the certificate is issued. A QWAC adds the eIDAS qualified layer: the certificate must be issued by a qualified trust service provider and meet Annex IV requirements. - Confirm that the certificate is explicitly indicated as a qualified certificate for website authentication. - Check that the subject identity, address elements, and domain names match the website or service being authenticated. - Record the certificate validity period, serial or certificate identity code, issuer, and status-service location. - Treat QWAC evidence as website identity evidence, not as proof that the whole transaction, application, or message payload has been sealed or signed. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS) - website authentication certificate definitions](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20240520&ref=sorena.io) - Defines certificate for website authentication and qualified certificate for website authentication, including the QTSP and Annex IV elements that make the certificate qualified. - [ETSI EN 319 412-5 - QCStatements for EU qualified certificates](https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.05.01_60/en_31941205v020501p.pdf?ref=sorena.io) - Maps eIDAS Annex IV QWAC requirements to certificate-profile fields, including qualified-certificate indication, subject identity, domain names, validity, serial number, and status-service locations. ### [How should a relying party validate a QWAC?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qwac.md#how-should-a-relying-party-validate-a-qwac) *Module: [What is a QWAC under the EU eIDAS Regulation?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qwac.md)* Validation should combine certificate checks with eIDAS status checks. First confirm that the issuer and service are qualified for the relevant trust service on an EU trusted list, because eIDAS allows a qualified trust service provider to provide a qualified trust service after qualified status appears in the trusted lists. - Use the EU and national trusted-list information to confirm the QTSP and qualified service status. - Check the website domain against the certificate's domain-name information before treating it as the authenticated endpoint. - Use the certificate validity-status service, such as the CRL or OCSP location identified in the certificate profile, before relying on the certificate. - Keep validation logs that show the certificate examined, trusted-list result, revocation or validity status, validation time, and any exception decision. Sources for this answer: - [Regulation (EU) No 910/2014 (eIDAS) - trusted lists and certificate status](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20240520&ref=sorena.io) - Supports checking qualified status through trusted lists and checking qualified-certificate validity or revocation status before relying on a QWAC. - [ETSI TS 119 612 - Trusted Lists](https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.03.01_60/ts_119612v020301p.pdf?ref=sorena.io) - Specifies trusted-list structure and service information used by validators to interpret qualified trust service provider and qualified service status. - [European Commission eSignature building block - trusted-list tooling](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109036/eSignature?ref=sorena.io) - Commission Digital Building Blocks page points users to eIDAS Dashboard resources such as the Trusted List Browser and validation-test tooling. ### [What changed for browsers and QWACs under eIDAS 2?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qwac.md#what-changed-for-browsers-and-qwacs-under-eidas-2) *Module: [What is a QWAC under the EU eIDAS Regulation?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qwac.md)* The eIDAS 2 amendments add browser-facing duties for qualified certificates for website authentication. Providers of web browsers must recognise QWACs issued in accordance with Article 45 and display the identity data and additional attested attributes in a user-friendly way, subject to the small-enterprise exception stated in the Regulation. - For website owners, confirm whether the intended browser and client environment recognises and displays the QWAC identity information needed for the user journey. - For relying-party systems, do not rely on browser display alone; keep machine-readable validation evidence for issuer, service status, certificate status, and domain match. - For incidents, remember that eIDAS allows browser precautionary measures only for substantiated concerns about security breaches or loss of integrity of an identified certificate or set of certificates. - For procurement, ask certificate providers how the QWAC profile, trusted-list status, revocation publication, and renewal process will be evidenced. Sources for this answer: - [Regulation (EU) 2024/1183 - eIDAS 2 browser recognition amendments](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32024R1183&ref=sorena.io) - Amends eIDAS Article 45 and adds browser-recognition and precautionary-measure provisions for qualified certificates for website authentication. - [ETSI EN 319 412-4 - certificate profile for website authentication](https://www.etsi.org/deliver/etsi_en/319400_319499/31941204/01.04.01_60/en_31941204v010401p.pdf?ref=sorena.io) - Explains the website-certificate profile for TLS-accessed websites, useful for distinguishing website authentication from other eIDAS certificate purposes. - [ETSI EN 319 412-5 - certificate type QCStatement](https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.05.01_60/en_31941205v020501p.pdf?ref=sorena.io) - Supports the distinction between website-authentication certificates, electronic-signature certificates, and electronic-seal certificates through certificate-type QCStatements. *Recommended next step* *Placement: before sources* ## Review eIDAS signatures, certificates, wallets, and attestations with cited checks Sorena can help convert eIDAS FAQ answers into validation records, trusted-list checks, relying-party evidence, and cited review notes for product, security, and compliance teams. - [Open Research Copilot for eIDAS](/solutions/research-copilot.md): Ask cited questions about eIDAS signatures, QTSPs, trusted lists, QWACs, EUDI Wallets, attestations, and validation evidence. - [Talk through implementation](/contact.md): Review your eIDAS reliance checks, wallet relying-party flow, trusted-list evidence, and validation records with Sorena. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/items