In our previous explorations of the EUDI (European Digital Identity) ecosystem, we worked through some of the roles that the ARF (Architecture Reference Framework) defines: wallet-relying party registration, wallet instance and key attestations, relying party certificates and trust lists.
Together, these roles form the trust layer of the EUDI ecosystem.

This article moves to the issuer side and to the electronic attestation of attributes.

An attestation is a signed statement about a person or an organisation. Age, address, professional qualification, company registration status to name a few. eIDAS 2.0 recognises three types, and they are often treated as interchangeable. The difference matters, because the type of attestation decides who is permitted to issue it and what legal weight it carries to the party relying on it.

EAA

Non-qualified Electronic Attestations of Attributes (EAAs) can be issued by any trust service provider, company or similar entity. Article 45b of Regulation (EU) 2024/1183 establishes that it cannot be denied legal effect for being electronic or for being non-qualified, and the rules that govern it in practice come from sector frameworks or from the contract between the parties.

Most private sector attributes will be EAAs. An employer issuing a professional membership, an insurer issuing proof of cover, an airline issuing a customer status. Trust here comes from the existing relationship or an attestation/sector-specific rulebook.

QEAA

Issued by a qualified trust service provider (QTSP) against Annex V requirements and signed with a qualified electronic seal or signature. The QTSP is listed on a Member State's Article 22 trusted list, which is what lets a verifier confirm the issuer's qualified status. Legal effect is equivalent to a lawfully issued paper attestation across the Union.

The use case is an attribute that has to be accepted by an authority in another Member State without further checking, such as a professional qualification presented by a pharmacist registering to practice abroad.

PuB-EAA

Issued by or on behalf of a public sector body responsible for an authentic source, under Article 45f. The issuing body is not a qualified trust service provider. It signs using a qualified certificate obtained from one, and the result carries the same legal effect as a QEAA.

The typical case is an attestation drawn directly from an official register: a residence confirmation, a civil registry extract, a driving license. This is the type most Member States will use for the credentials citizens receive from the state, which makes it the one public sector projects need to plan for first.

Choosing between the three is a risk decision. Qualified status brings supervision, conformity assessment and cost, which is proportionate for a diploma and disproportionate for a gym membership.

EAA, PuB-EAA and QEAA: Issuing all three with Procivis One

Procivis One Issuer covers all three attestation types from one issuance and lifecycle stack, in both SD-JWT VC and ISO 18013-5 mdoc.

The difference between issuing an EAA and a QEAA is a matter of configuration, not a separate integration. The requirements for a QEAA are naturally higher. The qualified seal must be created in an audited environment, so key storage and signature generation happen at the QTSP rather than on the issuing server. Procivis One Issuer integrates the Cloud Signature Consortium (CSC) API to call into the QTSP for signing and handles issuance and lifecycle around it. Revocation, certificate handling and trust list consumption work the same across all three attestation types.

Procivis took part in the ETSI Electronic Attestation of Attributes Plugtests, run remotely from 4 May to 30 June 2026, testing the QEAA and PuB-EAA profiles of ETSI TS 119 472-1 in SD-JWT VC and ISO 18013-5. Credentials issued from Procivis One were verified 869 times by 27 participating implementations.

What comes next

Next in this series: Person Identification Data, the identity set issued by a designated PID provider under Article 5a, and QES: qualified electronic signatures, where the wallet is used to sign rather than to prove. Procivis One supports all, alongside the trust infrastructure roles covered in the earlier articles.

To see how issuance, formats and trust list handling work together, explore the documentation or request trial access.