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.
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.