A source-grounded architecture guide for teams implementing or integrating with the European Digital Identity Wallet under the amended eIDAS framework.
Covers ARF roles, wallet units, PID and attribute attestations, relying-party registration, trust anchors, access certificates, wallet-unit attestations, selective disclosure, logs, pseudonyms, and security controls.
Structured answer sets in this page tree.
Cited legal and guidance references.
Under the amended eIDAS framework, the EUDI Wallet is an electronic identification means. It lets users store, manage, validate, and present and electronic attestations of attributes, interact with relying parties, and sign with qualified electronic signatures or seal with qualified electronic seals. The (ARF) maps the ecosystem and its technical interactions, but the Regulation and implementing acts control where they differ.
Treat the binding baseline and the ARF as different layers. Regulation (EU) 2024/1183 amends eIDAS and defines the EUDI Wallet, the Article 5a wallet functions, relying-party authentication, certification, security breach handling, and supervision. The ARF describes the ecosystem architecture, roles, components, trust model, presentation flows, attestation formats, certification context, and risk-management concepts used to implement that framework. The Commission states that the current ARF reflects the adopted EUDI Regulation and the implementing regulations adopted to date, so teams should identify the ARF version used rather than relying on an undated copy.
A technical architecture record should therefore separate legal requirements from implementation choices. The legal layer identifies the role and obligation; the architecture layer explains how wallet units, providers, relying parties, attestations, certificates, and trust lists interact.
Member States must provide at least one wallet within 24 months after the relevant implementing acts entered into force, which the Commission describes as an end-of-2026 rollout. Commission Implementing Regulation (EU) 2025/848 applies from 24 December 2026 for harmonised relying-party registration. Use those dates as architecture-readiness gates, while checking the establishment Member State for its actual registrar, certificate authorities, endpoints, and onboarding procedure.
The architecture should distinguish the provider's wallet solution from the individual user's . Implementing Regulation (EU) 2024/2979 describes a wallet solution as the combination of software, hardware, services, settings, and configurations needed to operate the wallet. A wallet unit is the unique configuration for an individual wallet user, including the wallet instance and security components.
The wallet instance is the application or environment the user interacts with. Critical assets are protected through wallet secure cryptographic applications (WSCAs) linked to wallet secure cryptographic devices (WSCDs). That distinction matters because PID and attestation issuers must be able to verify they are issuing to a genuine , and relying parties need a way to validate wallet-unit authenticity and status.
(PID) is the identity dataset associated with the wallet under the relevant eID scheme. Electronic attestations of attributes (EAAs) are separate attestations that authenticate attributes such as a characteristic, right, permission, qualification, or other attribute. The amended eIDAS text defines both concepts, while Implementing Regulation (EU) 2024/2977 sets rules for issuing PID and EAAs to wallet units.
The architecture must support issuance, storage, presentation, validation, revocation, and privacy-preserving use of PID and attestations. It should not collapse PID, qualified electronic attestations of attributes, public-sector authentic-source attestations, and non-qualified attestations into one generic credential type, because the issuer, legal effect, verification source, and revocation model can differ.
A relying party is the service provider that relies on the wallet, electronic identification, or a trust service. In wallet architecture, the relying-party integration is security-critical because it determines what data is requested, whether the relying party is registered for that purpose, how the relying party authenticates to the wallet, and what the user sees before approving disclosure.
The ARF trust model is built around mutual authentication, registration, revocation, authorization, trusted lists or lists of trusted entities, access certificate authorities, and wallet-unit attestations. A relying-party request should therefore be checked against the relying party's registered intended use, access certificate, requested attributes, embedded disclosure policy, and the wallet user's approval.
The amended eIDAS framework requires common protocols and interfaces for issuance, relying-party requests and validation, sharing and presentation online and offline, wallet-to-wallet interaction, relying-party authentication, wallet authenticity validation, erasure requests, suspicious-request reporting, and qualified electronic signatures or seals. The ARF references technical building blocks such as ISO/IEC 18013-5 mobile-document flows, SD-JWT VC, OpenID4VCI, OpenID4VP, and related OpenID profiles, but an implementation should verify the current adopted implementing acts and conformance specifications before freezing a protocol stack.
Certificates appear in several places. Wallet-unit attestations carry keys for validating a . Wallet-relying party access certificates identify relying parties and certain providers to wallet units. Qualified certificates, qualified signature creation devices, and signature creation applications are separate trust-service elements when the wallet is used to create qualified electronic signatures or seals.
Privacy is a design constraint, not a later notice. eIDAS requires user control, selective disclosure, local encrypted pseudonyms, transaction visibility, and separation of wallet-service personal data from other provider data. Implementing Regulation (EU) 2024/2979 adds privacy-oriented requirements around wallet-unit attestations, embedded disclosure policies, transaction logs, pseudonym generation, portability, and wallet-unit revocation.
Security controls should be mapped to the wallet component they protect and the trust decision they support. The ARF risk discussion highlights impersonation, key compromise, unauthorized attestation issuance, overbroad relying-party requests, relying-party linkability, and attestation-provider linkability as architecture risks that need concrete mitigations.
No. The ARF is an informative . It is useful for designing roles, components, interfaces, and trust flows, but binding requirements come from eIDAS as amended by Regulation (EU) 2024/1183, implementing regulations, and adopted standards or certification schemes.
Separate the wallet solution from each . The solution is the provider's overall software, hardware, services, settings, and configurations. A wallet unit is the unique setup for one user, including wallet instances, WSCAs, WSCDs, wallet-unit attestations, PID, attestations, logs, and user-controlled presentation behavior.
It should be registered for the wallet use case, identify itself with the supported authentication mechanism or access certificate, request only the attributes tied to its registered intended use, and give the wallet enough information to inform the user before selective disclosure.
This guide helps review wallet-unit boundaries, PID and attestation issuance, relying-party registration, certificate validation, privacy controls, and security evidence before building or procuring an EUDI Wallet integration.
Ask questions tied to cited sources about EUDI Wallet roles, ARF architecture, PID, attestations, relying parties, and trust-service evidence.
Review an EUDI Wallet integration plan against the ARF, implementing regulations, trust model, certificate checks, and privacy controls.
"wallet-relying party access certificate"
"data protection by design and by default"
"Relying Party linkability"
"Not request any extra user data than what was specified during registration."
"full control over their data"