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.
This page helps separate legal effect, technical validation, trust-list status, wallet registration, and evidence records before accepting a signature, certificate, attestation, or wallet presentation.
Structured answer sets in this page tree.
Cited legal and guidance references.
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.
These focused FAQ modules break this artifact into narrower answer sets so teams can move straight to the right source-backed guidance.
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.
eIDAS creates the EU framework for electronic identification and trust services. In practical terms, it covers electronic signatures, electronic seals, electronic time stamps, electronic registered delivery services, certificate services for website authentication, electronic attestations of attributes, electronic archiving, electronic ledgers, and the European Digital Identity Wallet.
The first classification question is whether the product is only consuming a trust service, providing a trust service, relying on a qualified trust service, or acting as a wallet relying party. Those roles lead to different checks: relying parties usually need validation and evidence that the provider or certificate status is trustworthy, while providers need policies, supervision, conformity assessment, and operational controls.
No. Electronic signatures are one important part of eIDAS, but the framework also covers electronic identification, seals, time stamps, registered delivery, website authentication certificates, electronic attestations of attributes, archiving, ledgers, and the European Digital Identity Wallet.
Check the service type, whether qualified status is claimed, the relevant trusted-list entry and service status, the certificate or attestation validity at the relevant time, the validation result, and whether the data presented to the user or relying party matches the intended transaction.
An advanced electronic signature is an electronic signature that meets the Article 26 requirements, including linkage to the signatory, signatory identification, sole control of signature creation data, and detection of later data changes. A is a higher category: it is an advanced electronic signature created by a qualified electronic signature creation device and based on a qualified certificate for electronic signatures.
PAdES, XAdES, CAdES, and other advanced-signature formats do not establish qualified status by themselves. Qualification depends on the qualified certificate, , creation-device requirement, and validation result.
Commission Implementing Regulation (EU) 2025/1945 has applied since 20 October 2025 and sets reference standards for validating QES and advanced signatures based on qualified certificates. Compliance with those standards supports a presumption that the validation process meets the referenced eIDAS requirements; it does not turn an AdES into a QES without the qualified certificate and QSCD conditions.
No. Those formats can support advanced electronic signatures and validation interoperability, but qualified status also requires a qualified certificate, a , a qualified signature creation device, and successful validation against the eIDAS requirements.
Save the signed file or hash, validation report, certificate chain, qualified certificate status, trusted-list evidence for the issuing service, signing time or validation time used, integrity result, signatory data result, and any pseudonym or qualified-device indication shown to the relying party.
A trust service provider is qualified only when the supervisory process has granted qualified status to the provider and the qualified service. Under eIDAS, qualified trust service providers may begin providing the qualified service after that qualified status is indicated in the trusted list.
establish which supervised trust service providers and services have qualified status. Member States establish, maintain, and publish them. ETSI describes national trusted lists as having constitutive effect: a provider or service benefits from qualified status only if listed as qualified.
For eIDAS reliance, the practical answer is no. The provider and the specific qualified service should be checked in the relevant trusted list because qualified status is tied to the trusted-list entry and service status.
Keep the trusted-list source used, provider and service identifiers, service type, current and historical status evidence, status date or time shown by the list, and a link between that evidence and the signature, seal, certificate, attestation, or validation report being accepted.
A qualified certificate for website authentication, commonly called a QWAC, is a website authentication certificate issued by a and meeting the eIDAS requirements for that certificate type. eIDAS 2 adds browser recognition and user-friendly display obligations for identity data attested in qualified website authentication certificates.
Website teams should avoid treating QWAC as a normal TLS procurement label. The check is whether the certificate is a qualified certificate for website authentication, whether the issuing and service status can be verified, and whether the website identity data being relied on is the identity data actually attested in the certificate.
No. A QWAC is a qualified certificate for website authentication issued by a and meeting the eIDAS certificate requirements. A normal TLS certificate may support encrypted website connections without being a qualified eIDAS website authentication certificate.
Keep the certificate, chain, revocation check, domain and subject identity data, issuing , trusted-list status for the issuing service, and the time and method of validation.
The European Digital Identity Wallet is an electronic identification means that lets users store, manage, validate, and present person identification data and electronic attestations of attributes to relying parties, and sign or seal through qualified electronic signatures or seals. A relying party is the person or organization relying on electronic identification, a wallet, another eID means, or a trust service.
Article 5b requires a wallet relying party to register in the Member State where it is established when it intends to rely on wallets for public or private services by digital interaction. The registration information includes the intended use of wallets and the data the relying party intends to request from users.
The harmonised registration process in Commission Implementing Regulation (EU) 2025/848, as amended by Commission Implementing Regulation (EU) 2026/1730, applies from 24 December 2026. Until then, teams should treat Article 5b as the controlling duty but verify whether the relevant Member State has opened its register and issued national procedures. The ARF describes the operational model in which wallet units compare requested attributes with registration information and warn the user about requests outside that scope.
The Commission describes the wallet rollout as an end-of-2026 milestone, but that does not make acceptance mandatory for every private service. Article 5f ties private-sector acceptance to Union, national, or contractual strong-authentication requirements, excludes microenterprises and small enterprises, and applies only when the user voluntarily requests wallet use.
No. The relying party should align wallet requests with its registered intended use and registered attributes. The ARF describes wallet checks that compare requested attributes with the relying party registration and inform the user if a request goes beyond what was registered.
Keep the relying-party registration, intended use, requested attribute list, user-facing request text, privacy-policy URL, user approval record where appropriate, and logs showing whether the wallet request matched the registered attributes. Under the harmonised rules applying from 24 December 2026, also keep the access certificate and automatically issued registration certificate evidence.
No. Article 5f applies the private-sector acceptance duty where Union or national law or a contract requires strong user authentication for online identification. It excludes microenterprises and small enterprises and makes wallet acceptance conditional on the user's voluntary request. A service should document the legal or contractual trigger instead of relying on the end-of-2026 wallet rollout date alone.
An electronic attestation of attributes allows attributes of a natural person, legal person, or object to be authenticated. A qualified electronic attestation of attributes is issued by a and must meet eIDAS Annex V requirements. eIDAS also recognizes attestations issued by or on behalf of public sector bodies responsible for authentic sources.
Validation evidence should answer three questions: who issued the credential or certificate, whether the issuer and service were authorised for that type of trust service or attestation, and whether the credential, certificate, signature, or wallet presentation was valid at the time relied on. For long-lived records, preserve enough data to repeat or explain the validation result after certificates, algorithms, or trusted-list statuses change.
Commission Implementing Regulation (EU) 2025/1569 now supplies issuance, revocation, list, catalogue, and authentic-source verification rules for QEAAs and public-sector authentic-source attestations. Most provisions have applied since 19 August 2025; Articles 6 to 9 on provider lists, catalogues, and attribute-verification mechanisms apply from 19 August 2026. Commission Implementing Regulation (EU) 2026/1735 enters into force on 11 August 2026 and updates the applicable standards and technical specifications; its Article 1(3), which adds specifications for Article 9 verification mechanisms, applies from 1 January 2027.
Not automatically. eIDAS distinguishes electronic identification from attestations of attributes. Where electronic identification and authentication are required for a public-sector online service, person identification data in an attestation does not supersede electronic identification unless the Member State specifically allows it.
A useful validation record contains the object validated, validation policy or method, time of validation or reliance, issuer and service identity, certificate or attestation status, trusted-list evidence where qualified status matters, integrity result, user or relying-party result, and the source used for the rule being applied.
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.
Ask cited questions about eIDAS signatures, QTSPs, trusted lists, QWACs, EUDI Wallets, attestations, and validation evidence.
Review your eIDAS reliance checks, wallet relying-party flow, trusted-list evidence, and validation records with Sorena.
"technical specifications and formats relating to trusted lists"
"XML, CMS or PDF advanced electronic signature"
"automatically and without undue delay"
"validation and preservation"
"Attestation Provider"
"organisations can request data from wallet users"
"qualified electronic attestation of attributes"
"electronic identification and trust services for electronic transactions"
"qualified certificates for website authentication"