Topic starter
24/10/2026 8:50 pm
TL;DR: Issuer type governs eIDAS 2.0 electronic attestations as much as content does, because EAA, PuB-EAA and QEAA carry different legal effects, according to Procivis. Trust and verification must track source and legal status, or acceptance rules drift across use cases.
Editorial analysis by NHI Mgmt Group, based on content published by Procivis: “Electronic attestations of attributes in eIDAS 2.0”.
Key questions
Q: Why does qualified attestation require a different governance model?
A: Qualified attestation depends on external supervision, audited key handling and trusted-list validation, so assurance is not contained inside the issuer's application alone.
Q: What breaks when attestation types are treated as interchangeable?
A: You lose the link between issuer authority and legal effect, which can cause a verifier to accept a claim that does not meet the required assurance level.
Q: How should organisations decide between EAA, PuB-EAA and QEAA?
A: Choose based on who is allowed to issue the attribute, where the source of truth sits and what legal effect the relying party needs.
Practitioner guidance
- Define issuer classes by legal effect Map every attestation use case to EAA, PuB-EAA or QEAA before implementation so the issuer authority and acceptance conditions are explicit.
- Separate qualified signing from ordinary issuance Keep QEAA key storage and signature generation inside the audited qualified trust service provider path rather than on the issuing application server.
- Operationalise trusted list consumption Build verification processes that continuously consume Article 22 trusted lists and invalidate acceptance when qualified status changes.
Bottom line: eIDAS 2.0 electronic attestations are governed by issuer type as much as by content, so trust architecture must distinguish private, public and qualified claims.
Glossary terms: Electronic Attestation Of Attributes, Qualified Electronic Attestation Of Attributes, Qualified Electronic Attestation Of Attributes, Trusted List
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:12 am
Issuer type is the security boundary, not the credential shell: eIDAS 2.0 treats EAA, PuB-EAA and QEAA as materially different trust objects, and that difference is what identity architects should design around. If a programme models them as interchangeable signed claims, it will miss the legal and supervisory conditions that make a credential acceptable across organisational and national boundaries. The practitioner takeaway is to govern by issuer authority first and format second.
A question worth separating out:
Q: How do teams handle cross-border acceptance for electronic attributes?
A: They should anchor cross-border use cases in the issuer model first, then validate whether the attribute requires qualified status to be accepted without further checking by another Member State. That keeps architecture aligned to legal effect rather than to formatting convenience.
👉 Read our full editorial: eIDAS 2.0 attestations hinge on issuer type and legal effect
This post was modified 6 days ago by NHI Mgmt Group