Search every question across sub-FAQs

An electronic attestation of attributes is a regulated way to prove facts about a natural person, legal person, or object 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.

The attestation type controls the legal and validation checks. A non-qualified EAA can still have legal effect and evidentiary value, but a qualified electronic attestation of attributes (QEAA) must meet Annex V requirements and be issued by a qualified trust service provider. A separate category covers attestations issued by, or on behalf of, a public sector body responsible for an authentic source; those must meet Annex VII and the additional Article 45f requirements.

Commission Implementing Regulation (EU) 2025/1569 adds the operational rules for QEAAs and public-sector authentic-source attestations. Its issuance and revocation provisions have applied since 19 August 2025. Articles 6 to 9, which cover the public-sector provider list, attribute and scheme catalogues, and authentic-source 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.

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. Articles 6 to 9 of Commission Implementing Regulation (EU) 2025/1569 apply from 19 August 2026, while the specifications added to Article 9 by Commission Implementing Regulation (EU) 2026/1735 apply from 1 January 2027; availability before the relevant date can still depend on the Member State and authentic source.

A public-sector authentic-source attestation is different: it is issued by, or on behalf of, a public sector body responsible for the authentic source. The Member State must ensure those bodies meet a reliability and trustworthiness level equivalent to qualified trust service providers, notify them to the Commission, and make the public list available through a secure signed or sealed channel.

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.

Cryptographic verification alone does not complete a relying-party check. The EUDI Wallet Architecture and Reference Framework describes an ecosystem in which wallets let users request attestations from trusted issuers, store them, and present them to relying parties with user control, selective disclosure, relying-party authentication, issuer authorisation checks, and revocation/status checks.

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.

Article 21 links the start of qualified service provision to the qualified status being indicated in the trusted list. Article 23 also connects the EU trust mark to the relevant trusted list, so a trust-mark claim should still be checked against the list entry.

Commission Implementing Decision (EU) 2025/2164 has applied since 29 April 2026. It updates the common trusted-list template to ETSI TS 119 612 V2.4.1 and expands the interpretation rules for newer qualified trust services and certificate qualifiers. Validators should use the amended decision and current template instead of assuming that an older 2015 profile is sufficient.

The Commission makes Member State trusted-list publication information available, and ETSI TS 119 612 V2.4.1 describes the central List Of Trusted Lists as a signed or sealed list of pointers to national trusted-list locations.

A useful audit record should therefore preserve both the list-discovery route and the actual service-status result, so a reviewer can distinguish a stale supplier assertion from a reproducible trusted-list check.

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.

DSS validation material illustrates the practical split: a validation process may need certificate-chain validation, revocation data, timestamp or long-term validation material, and a qualification determination based on trusted-list interpretation.

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.

For Article 5b, the trigger is the intention to rely on the wallet for public or private services by means of digital interaction. Once that trigger is present, the relying party must register in the Member State where it is established. Because the harmonised national-register rules apply from 24 December 2026, a team preparing earlier must verify whether its Member State has already opened a registration route instead of assuming that an EU-wide registration portal exists.

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.

From 24 December 2026, Commission Implementing Regulation (EU) 2025/848 harmonises the registration process. It requires national registers and policies, accurate registration data, prompt updates, verification against supporting documents or authentic sources, and cancellation when the relying party stops relying on wallets under that registration.

Article 5b limits the live request: relying parties must not ask users for data beyond what they indicated during registration. The registered purpose and attribute list therefore form a control boundary for product, legal, privacy, and engineering teams.

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.

The ARF adds a useful technical control point: the wallet can use relying-party registration information or certificates to help verify whether a request fits the registered attributes and warn the user if it does not. That technical model supports the legal purpose, data-minimisation, and transparency checks, but the binding obligation remains in eIDAS and applicable data-protection law.

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.

Avoid storing more wallet transaction content than the service needs. The ARF highlights relying-party linkability risks from unique fixed attestation elements, and Article 5b specifically says intermediaries acting for relying parties must not store data about transaction content.

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.

A QES is an AdES that also uses a qualified certificate for electronic signatures and a qualified electronic signature creation device. eIDAS Article 25 gives a QES the equivalent legal effect of a handwritten signature, while any electronic signature remains admissible and cannot be rejected only because it is electronic or not qualified.

That handwritten-signature equivalence does not remove separate requirements that Union or national law may impose on a transaction, such as witnessing, notarisation, registration, or a prescribed form. Check the law governing the document before treating QES as the only formality.

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.

Trusted lists matter because eIDAS requires Member States to establish, maintain, and publish trusted lists with information about qualified trust service providers and their qualified trust services. The trusted-list interpretation rules also explain how qualified certificate and QSCD-related status can be represented through service entries, certificate statements, and qualifications.

Commission Implementing Regulation (EU) 2025/1945 has applied since 20 October 2025. It sets reference standards for validating QES and the middle category of AdES based on a qualified certificate. A process that complies with those standards benefits from the regulation's presumption of compliance for the referenced validation requirements, but the result still has to distinguish QES from AdES without QSCD proof.

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; the weight given to that evidence depends on the applicable law and transaction record.

Require QES when the applicable law, public-service requirement, customer mandate, procurement clause, or organisation risk decision specifically requires qualified status or handwritten-signature equivalence. Then check separately for any witnessing, notarisation, registration, or other form requirement. A normal AdES audit trail is incomplete for a QES claim unless it also proves the qualified certificate, QTSP, QSCD, and validation conditions.

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.

Do not treat a marketing claim, ISO certificate, ETSI standard reference, reseller statement, or parent-company brand as proof of QTSP status. Under eIDAS, a provider intending to start a qualified trust service notifies the supervisory body and submits a conformity assessment report; the supervisory body grants qualified status when the provider and service meet the eIDAS requirements.

Providers that already held qualified status before 20 May 2024 had a separate transition duty: Article 51(4) required them to submit, by 21 May 2026, a conformity assessment report proving compliance with the amended identity and attribute verification rules in Article 24(1), (1a), and (1b). A current supplier review should check whether that transition evidence was submitted when it applies.

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.

For technical validation, ETSI TS 119 612 explains how trusted-list information can feed certificate path validation and trust-anchor management. A relying party should validate the trusted-list source, select entries under its trust policy, and check regularly for service status changes or new entries.