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.
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: register, declare intended wallet use and requested data, identify themselves to users, and keep request 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 qualified electronic signature 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.
For acceptance work, do not label a signature as qualified just because the file uses PAdES, XAdES, CAdES, or another advanced-signature format. The qualification depends on the qualified certificate, qualified trust service provider, creation-device requirement, and validation result, not just the container or syntax.
No. Those formats can support advanced electronic signatures and validation interoperability, but qualified status also requires a qualified certificate, a qualified trust service provider, 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.
Trusted lists are not just directories. Member States establish, maintain, and publish trusted lists with information about supervised qualified trust service providers and their qualified services. ETSI describes the 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 qualified trust service provider 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 qualified trust service provider 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 qualified trust service provider 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 qualified trust service provider, 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.
A wallet relying party should 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 ARF then describes operational checks where wallet units can verify whether requested attributes match the relying party registration and warn the user if they do not.
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, access certificate or registration certificate evidence where used, user-facing request text, privacy-policy URL, user approval record where appropriate, and logs showing whether the wallet request matched the registered attributes.
An electronic attestation of attributes links attributes or credentials to an identified person. A qualified electronic attestation of attributes is issued by a qualified trust service provider 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 authorized 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.
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"
"validation and preservation"
"Attestation Provider"
"organisations can request data from wallet users"
"qualified electronic attestation of attributes"
"qualified certificates for website authentication"