eIDAS 2 Roles
eIDAS 2 Issuer Requirements
How to Issue Credentials Under eIDAS 2
Issuers are the governments and businesses that create credentials in the eIDAS 2 ecosystem. This guide covers what an issuer is, the five credential types, the full compliance checklist, the issuance protocols and formats, and how to build compliant issuance infrastructure.
On this page
An eIDAS 2 issuer is a government or business that attests claims about a person or organisation — such as a name, qualification, or entitlement — and issues them as a digital credential into an EU Digital Identity Wallet (EUDI Wallet). To do so compliantly, an issuer must register in the eIDAS 2 trust ecosystem, issue credentials in the mandated formats and protocols, and manage each credential's full lifecycle.
What is an eIDAS 2 issuer?
An issuer cryptographically signs a set of attributes about a user and delivers it to their EUDI wallet. Trust is established through official EU Trusted Lists: every issuer must be registered so that wallets and verifiers can confirm the credential came from a legitimate source. The credential follows a mandated format (SD-JWT VC, ISO/IEC 18013-5, or W3C VC) and is delivered over the OID4VCI protocol.
The five credential types an eIDAS 2 issuer can issue
eIDAS 2 (Regulation (EU) 2024/1183) defines five categories of attestation, in descending order of assurance and legal weight. The category determines who can issue it and which requirements apply.
| Credential | Full name | Issued by | Legal weight |
|---|---|---|---|
| PID | Person Identification Data | Government-appointed PID Providers | Core digital ID; required to activate a certified EUDI wallet |
| LPID | Legal Person Identification Data | LPID Providers | Core digital ID for companies and organisations |
| PuB-EAA | Public Sector Body Electronic Attestation of Attributes | Public-sector bodies (registries, tax, immigration) | Same legal value as the paper original |
| QEAA | Qualified Electronic Attestation of Attributes | Qualified Trust Service Providers (QTSPs) | Same legal value as the paper original |
| EAA | (Non-Qualified) Electronic Attestation of Attributes | Any business (Non-Qualified EAA Provider) | Defined by the credential's rulebook |
The concrete attributes and rules for each credential — and any sector-specific requirements, such as those for banking — are defined in dedicated attestation rulebooks. Attribute definitions for PID and EAAs are set in Regulation (EU) 2024/2977.
eIDAS 2 issuer requirements: the compliance checklist
Every eIDAS 2 issuer, regardless of credential type, must meet the same core obligations. The checklist below is the baseline for compliance.
- Register as an issuer in the eIDAS 2 Trusted Lists to become a trusted actor in the ecosystem, and obtain an access certificate.
- Verify the user's identity at Level of Assurance (LoA) High before issuance — typically through document verification, biometric checks, or by reusing the user's existing PID.
- Authenticate the wallet unit before issuing: verify the Wallet Unit Attestation (WUA) signature, confirm it has not been revoked, and check proof of key possession.
- Issue in the mandated formats: SD-JWT VC (IETF) and ISO/IEC 18013-5 (mdoc) are mandatory for PID, PuB-EAA and QEAA; W3C VC (VCDM 2.0) is optional and only for EAAs.
- Implement OID4VCI V1 with the HAIP profile for credential delivery, and ISO/IEC 18013-7 for mdoc remote flows.
- Bind the credential cryptographically to the wallet's secure element (WSCD).
- Manage status and revocation: publish status information (Attestation Status Lists, Attestation Revocation List) so verifiers can check validity, and support short-lived credentials and revocation on request.
- Conform to the attestation rulebook for the credential's structure, identifiers, and metadata.
- Apply privacy-enhancing measures: prevent batch issuance from being correlated, and optionally embed disclosure policies that limit which verifiers may receive a credential.
eIDAS 2 issuer requirements by credential type
While the baseline is shared, the obligations tighten with the assurance level of the credential. This table maps the key differences.
| Requirement | PID / LPID | PuB-EAA | QEAA | EAA |
|---|---|---|---|---|
| Register as a trusted issuer | Required | Required | Required | Required |
| Identity proofing at LoA High before issuance | Required | Required (can reuse PID) | Required (can reuse PID) | Per rulebook |
| Authenticate the wallet before issuance | Required | Required | Required | Required |
| Support SD-JWT VC & ISO/IEC 18013-5 | Required | Required | Required | Required |
| Support W3C VC (VCDM 2.0) | – | – | – | Optional |
| Support OID4VCI / ISO 18013-7 | Required | Required | Required | Required |
| Credential must carry a revocation status (if valid > 24h) | Required | Required | Required | Per rulebook |
| Align with the attestation rulebook | Required | Required | Required | Required |
| Embedded disclosure policies | – | Optional | Optional | Optional |
Source: eIDAS 2 Implementing Acts and the Architecture and Reference Framework (ARF). A full role-by-role breakdown is available in the eIDAS 2 Implementers Guide.
How credential issuance works under eIDAS 2
Issuance follows a defined sequence built on the OID4VCI (OpenID for Verifiable Credential Issuance) protocol with the HAIP profile:
- Trust establishment — the issuer presents its access certificate so the wallet can authenticate it against the EU trusted lists.
- Wallet authentication — the issuer verifies the Wallet Unit Attestation (WUA) and confirms the wallet controls its private key, the key is in a secure environment and the Wallet Provider is trusted.
- Identity proofing — the user's identity is verified at LoA High, often by reusing the PID already in their wallet.
- Attribute sourcing — attributes are fetched from an authentic source (e.g. a registry or tax authority) or another trusted data-source (e.g. a database) and validated.
- Signing and binding — the credential is signed with the issuer's key and cryptographically bound to the wallet.
- Delivery — the credential is delivered into the wallet over OID4VCI, in the mandated format.
Issuers must also keep credentials valid over time — supporting updates, suspension, and revocation through a published status mechanism.
Build vs buy: how to meet eIDAS 2 issuer requirements
Becoming a compliant issuer means implementing credential standards, exchange protocols, key management, revocation, certificate management, and rulebook conformity — and keeping all of them current as the ARF and Implementing Acts evolve. There are three paths:
- Build apps, buy infrastructure (recommended) — build only the application layer and use a standards-compliant issuance provider (such as the walt.id Enterprise Stack). Fastest time to market, lowest regulatory and technical risk.
- Build apps, own infrastructure — use open-source solutions (such as the walt.id Community Stack) to retain full control while avoiding implementing OID4VCI and the credential formats from scratch.
- Build everything in-house — implement and maintain the full stack internally. Viable only for organisations with a dedicated identity engineering team.
How walt.id helps issuers comply
The walt.id Issuer delivers what the requirements demand, out of the box:
- Issuance of every credential type — PID, LPID, PuB-EAA, QEAA, and EAA — in SD-JWT VC, ISO/IEC 18013-5, and W3C VC formats over OID4VCI with the HAIP profile.
- Automated trust and certificate management — access certificates and Trusted List validation handled by a shared Trust Service.
- Credential lifecycle and revocation — Token Status List and Bitstring Status List support, short-lived credentials, and revocation built into the issuer API.
- Rulebook schema conformity — credential data validated against the official eIDAS 2 rulebook schemas during issuance.
- Single, batch, deferred, and re-issuance modes, with flexible attribute mapping from existing backends and authentic sources.
Explore the eIDAS 2 infrastructure layer or talk to the team about a specific issuance use case.
Frequently asked questions
What is an eIDAS 2 issuer?
An eIDAS 2 issuer is a government or business that attests claims about a person or organisation and issues them as a digital credential into an EU Digital Identity Wallet. Issuers must register in the eIDAS 2 Trusted Lists, issue credentials in the mandated formats (SD-JWT VC, ISO/IEC 18013-5, or W3C VC) using the OID4VCI V1 protocol with the HAIP profile, and manage the full lifecycle of each credential including revocation.
What are the requirements to become an eIDAS 2 issuer?
An eIDAS 2 issuer must: register in the Trusted Lists and obtain an access certificate; verify the user's identity at Level of Assurance High; authenticate the wallet unit before issuance; issue in the mandated credential formats; implement OID4VCI with the HAIP profile; cryptographically bind credentials to the wallet; publish a revocation status; and conform to the relevant attestation rulebook.
What credential types can an eIDAS 2 issuer issue?
There are five: PID (Person Identification Data) and LPID (the equivalent for legal entities), both issued by government-appointed providers; PuB-EAA, official government documents issued by public-sector bodies; QEAA, qualified attestations issued by Qualified Trust Service Providers; and EAA, everyday credentials that any business can issue.
Which protocols and formats must an eIDAS 2 issuer support?
Issuers must support OID4VCI V1 with the HAIP profile for credential delivery, and ISO/IEC 18013-7 for mdoc remote flows. SD-JWT VC (IETF) and ISO/IEC 18013-5 (mdoc) are mandatory credential formats for PID, PuB-EAA, and QEAA. W3C VC (VCDM 2.0) is optional and can only be used for non-qualified EAAs.
Do banks and universities count as eIDAS 2 issuers?
Yes. Any organisation that issues a credential into an EUDI Wallet is an issuer. A university issuing diplomas, a bank issuing an account or SCA attestation, and a public registry issuing a company formation document are all issuers — each falling into the credential type (QEAA, EAA, or PuB-EAA) that matches the credential's legal status and the issuing body.
How long does it take to become eIDAS 2 compliant as an issuer?
The timeline depends on the build-versus-buy decision. Implementing OID4VCI, the mandated credential formats, key management, and revocation in-house represents months of specialised engineering. Using a standards-compliant issuance solution like walt.id removes most of that work, leaving registration, attribute sourcing, and integration as the main tasks.
Continue exploring eIDAS 2
Build compliant issuance with walt.id
Issue PID, QEAA, PuB-EAA and EAA credentials over OID4VCI — with trust, certificate, and revocation management built in. EU trusted. Standard & regulatory compliant. Gov & enterprise proven.