Integrating with the EUDI Wallet requires your organization to support a specific set of open technical standards, protocols, and infrastructure components defined in the EU’s Architecture and Reference Framework (ARF). These requirements apply to any organization that wants to act as a relying party, meaning any service that will request and verify identity data from a user’s wallet. This article walks through the key technical questions your team needs to answer before starting integration work.
What technical standards does the EUDI Wallet rely on?
The EUDI Wallet is built on a combination of open international standards for digital credentials, cryptographic security, and data exchange. The core standards come from organizations such as ISO, the W3C, and the IETF, and they have been selected to ensure interoperability across all EU Member States and sectors.
The two primary credential formats supported are ISO/IEC 18013-5, which defines the mobile driving licence (mDL) format and underpins the mdoc credential type, and SD-JWT VC. These are not competing alternatives. The ARF supports both, and different use cases may rely on one or the other.
On the cryptographic side, the wallet relies on standards for key management, digital signatures, and certificate infrastructure that align with eIDAS 2.0 requirements. Trust is anchored in national trusted lists, brought together in the EU List of Trusted Lists (LOTL), not in proprietary systems. Organizations integrating with the wallet should treat these standards as non-negotiable baselines.
The ARF is the technical elaboration of the requirements set out in the legally binding implementing acts adopted under eIDAS 2.0, which amends Regulation (EU) 910/2014. The ARF itself is not legislation, but it provides the technical framework that wallet providers, issuers, and relying parties must follow in practice.
What protocols are required for EUDI Wallet credential exchange?
Credential exchange between a wallet and a relying party uses two main protocols: OpenID for Verifiable Presentations (OID4VP) for presenting credentials, and OpenID for Verifiable Credential Issuance (OID4VCI) for issuing credentials into a wallet. Both are IETF-tracked specifications and are mandated in the ARF as the standard communication layer.
For proximity use cases, where a user presents credentials in person, ISO/IEC 18013-5 over NFC or BLE is used. For online presentation scenarios, ISO/IEC TS 18013-7 and OID4VP handle the request and response flow between your service and the user’s wallet app. Implementations following the High Assurance Interoperability Profile (HAIP) should be consulted for the specific parameter constraints that apply.
These protocols define how your service sends a presentation request, how the wallet responds with the appropriate attestation, and how your system verifies the cryptographic proof. Supporting them requires your backend to implement the relevant endpoints and handle signed responses correctly. Organizations already working with OAuth 2.0 or OpenID Connect will find the patterns familiar, though the credential-specific extensions require careful implementation.
What infrastructure does an organization need to become a relying party?
To become a relying party in the EUDI Wallet ecosystem, your organization needs a registered identity in the trust framework, a technical integration layer that supports OID4VP, and the ability to verify cryptographic proofs from wallet-issued attestations. This requires deliberate infrastructure investment.
Under CIR (EU) 2025/848, adopted on 6 May 2025, a relying party must register with the national authority of the Member State in which it is established before it can request wallet data. Registration is per intended use: your organization declares which attributes and attestations it will request for each use case, and the wallet checks incoming requests against that registered scope. A vendor that processes wallet data on behalf of a client does not become the relying party as a result. The registration obligation rests with the organization that delivers the service to the end user.
The key infrastructure components you need to put in place include:
- Relying party registration: Your organization must be registered with the relevant national authority under CIR (EU) 2025/848, so wallets can verify that your service is a legitimate and recognized requester.
- OID4VP endpoint: A backend service capable of generating presentation requests and processing signed attestation responses from wallets.
- Certificate and key management: Your service needs its own cryptographic keys and certificates issued under the eIDAS trust framework to authenticate itself to wallets.
- Attestation verification logic: Software that can parse mdoc and SD-JWT VC credential formats, verify signatures, check revocation status, and validate the wallet unit attestation to confirm the presenting wallet runs on a certified wallet solution.
- Audit and logging infrastructure: Records of credential verification events, required for compliance and data protection purposes.
Note that a relying party does not need a qualified trust service provider (QTSP) for wallet acceptance alone. A QTSP becomes relevant when your use case involves qualified electronic attestations of attributes (QEAAs) or qualified electronic signatures.
The four Large Scale Pilots that ran from April 2023 to 2025 generated practical feedback on exactly these requirements, and their findings have been incorporated into the ARF on an ongoing basis. Organizations in financial services and government were among the most active participants, which means sector-specific guidance is becoming increasingly available.
How does the EUDI Wallet trust model affect system integration?
The EUDI Wallet uses a federated trust model where trust is established through official registries and trusted lists. Governance of this model is a shared responsibility: the European Commission manages the legal framework and adopts implementing acts; Member States certify and notify wallet solutions and supervise actors within their jurisdiction; national competent authorities and registrars manage relying party registration; and qualified trust service providers underpin the cryptographic infrastructure. Your organization, as a relying party, operates within this layered structure.
This means your integration cannot simply trust any attestation presented to it. Your system must verify that the credential issuer appears on a recognized national trusted list, that the cryptographic chain is intact, that the attestation has not been revoked, and that the presenting wallet runs on a certified wallet solution. These are three distinct verification steps, and only the first, checking the issuer’s signature against the relevant national trusted list, can be performed fully offline. Revocation status requires consulting the issuer’s status information, and wallet unit attestation validation requires checking that the wallet solution is currently certified.
The wallet itself performs a symmetric check: it will only present attestations to relying parties that are registered and recognized under CIR (EU) 2025/848. If your organization is not properly registered, the wallet will refuse the transaction.
This model requires that keeping your registration, registered attribute scope, and certificates current is an ongoing operational responsibility. Organizations that are used to managing PKI infrastructure will recognize the discipline required.
What are the data model and schema requirements for EUDI Wallet credentials?
Attestations exchanged via the EUDI Wallet must conform to defined data schemas that specify which attributes are present, what format they take, and how they are named. These schemas are defined per use case. The Person Identification Data (PID) credential, for example, has a standardized schema that all Member States must follow. PID is issued by entities designated under national law, not by general-purpose authentication mechanisms.
For the PID credential, attributes include name, date of birth, nationality, and a unique identifier, all structured according to the ISO/IEC 18013-5 or SD-JWT VC data model. For other attestation types, such as diplomas, health data, or professional qualifications, schemas were developed through the Large Scale Pilots and the ARF process. Issuers of attestations of attributes must also make revocation status information available and support re-issuance when a user moves to a new device, since private keys tied to a wallet unit do not leave the secure cryptographic device and cannot simply be copied.
When your organization requests specific attributes from a wallet, you must request them using the exact attribute names defined in the relevant schema, and only those attributes you have declared in your registered intended use. Selective disclosure is built into the credential format: users can share only the attributes you request, and you can only request what falls within your registered scope. This design enforces data minimization at the protocol level, which directly supports GDPR compliance.
Which security and privacy requirements apply to EUDI Wallet integrations?
EUDI Wallet integrations must meet security and privacy requirements derived from both eIDAS 2.0 and the GDPR. These requirements cover how attestations are verified, how data is stored after verification, and how users are informed about what data is being requested and why.
The key security and privacy obligations for relying parties are:
- Purpose limitation: You may only request attributes that are strictly necessary for the specific service you are providing, within the scope declared during registration. Requesting more data than needed is a compliance violation under both eIDAS 2.0 and GDPR.
- Cryptographic verification: Every attestation response must be verified against the issuer’s entry on the relevant national trusted list, with revocation status checked and the wallet unit attestation validated. Accepting unverified or self-asserted data is not permitted.
- Unlinkability: Where technically possible, your integration should avoid creating persistent identifiers that allow tracking of users across sessions or services.
- Transparent presentation requests: The wallet will display your request to the user before they approve it. Your request must clearly identify your organization and the purpose of the data request. Note that the user’s approval of a presentation request in the wallet is a separate matter from consent as a legal basis under the GDPR. Your organization needs its own GDPR legal basis for processing the data received.
- Data retention limits: Verified attribute data must not be retained longer than necessary for the stated purpose, in line with your data protection obligations.
These requirements call for coordination between your legal, compliance, and engineering teams. Organizations in healthcare and finance, where sensitive personal data is frequently involved, will need to pay particular attention to purpose limitation and retention policies. For health data, a legal basis under Article 9(2) GDPR is required in addition to the general processing ground. Reviewing your integration approach against these requirements early in the project will save significant rework later.
How the ID Connector supports EUDI Wallet integration
Meeting the technical requirements for EUDI Wallet integration involves translating complex standards into working systems, aligning your infrastructure with the trust framework, and ensuring that your legal and compliance obligations are met alongside the technical ones.
The legal deadline for public sector bodies to accept notified EUDI Wallet solutions for online services requiring electronic identification is 24 December 2026. For regulated private sector organizations in areas such as financial services, healthcare, telecoms, energy, and transport, the obligation under Article 5f of eIDAS 2.0 applies from 24 December 2027, where strong user authentication is legally or contractually required. Micro and small enterprises, defined as organizations with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros, are exempt. Very large online platforms (VLOPs) are subject to a separate provision under Article 5f: they must accept the EUDI Wallet where the platform requires user authentication, on voluntary request by the user and for the minimum necessary data. Both dates are legal deadlines, not predicted launch dates. Practical interoperability and national rollout are expected to develop in phases, and organizations should plan their integration work accordingly.
The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
For the technical integration described in this article, the ID Connector handles:
- Verification of issuer signatures against national trusted lists, brought together in the EU List of Trusted Lists
- Revocation status checks against issuer-provided status information
- Validation of wallet unit attestations to confirm the presenting wallet runs on a certified wallet solution
- Enforcement of your registered attribute scope, so that only declared attributes are requested
- OID4VP and OID4VCI protocol handling for both online and proximity presentation flows
- Support for mdoc and SD-JWT VC formats across certified wallets from any Member State
- Qualified signing flows via a connected QTSP, for use cases that require a qualified electronic signature
Organizations in financial services, healthcare, pharma, and government can find sector-specific information on the TrustTech website. To discuss your integration requirements, get in touch with our team.