A minimum viable architecture for eIDAS 2.0 compliance consists of four core components: a verified identity layer, at least one integrated qualified trust service, a relying party registration mechanism, and a connection point for EUDI Wallet interactions. You do not need to implement every element of the full framework to become compliant, but you do need to cover these foundations before you can legally accept or issue identity data under eIDAS 2.0. The sections below walk through each building block, the trade-offs between a minimal and a full compliance architecture, and the practical steps to get started.
What components make up an eIDAS 2.0-compliant architecture?
An eIDAS 2.0-compliant architecture is built around four interconnected layers: identity verification and issuance, trust service integration, wallet interoperability, and a policy and audit layer. Together, these layers allow your organization to issue, receive, and verify digital identity data in a way that meets the legal and technical requirements set by eIDAS 2.0, which amends Regulation (EU) 910/2014.
The Architecture and Reference Framework (ARF), developed with the support of the European Digital Identity Cooperation Group (EDICG) and the European Commission, provides the technical elaboration of the requirements set out in the implementing acts adopted under eIDAS 2.0. These specifications cover everything from how credentials are formatted and exchanged to how wallet solutions are certified and how relying parties are registered. The implementing acts are legally binding; the ARF provides the technical detail that supports their application.
In practical terms, a compliant architecture needs to handle the following:
- Identity proofing and credential issuance: verifying who a person or organization is and issuing cryptographically signed credentials
- Trust service integration: connecting to qualified trust services such as qualified electronic signatures (QES) or qualified electronic attestations of attributes (QEAAs)
- Relying party registration: formally registering your organization as a party that requests and accepts identity data from wallets, in accordance with the applicable national registration framework under CIR (EU) 2025/848
- EUDI Wallet compatibility: implementing the protocols and interfaces required to interact with certified wallet solutions
- Audit and evidence trail: maintaining tamper-evident records of identity transactions to support compliance reporting
Many organizations work with specialist providers who already have the certified infrastructure in place, which can significantly reduce time to production and compliance risk.
What is the difference between a minimum viable and a full eIDAS 2.0 architecture?
A minimum viable eIDAS 2.0 architecture covers the components required to legally accept wallet-based identity credentials and issue basic attestations. A full architecture extends this to cover all supported use cases, including cross-border identity matching, advanced attribute sharing, qualified preservation services, and deep integration with sector-specific compliance requirements.
The distinction matters because organizations often feel pressure to implement everything at once. A phased approach is both practical and permitted. A minimum viable setup allows you to meet your immediate regulatory obligations, test your processes, and build confidence in the ecosystem before expanding.
A minimum viable architecture typically includes:
- Relying party registration with the relevant national authority under CIR (EU) 2025/848
- Integration with at least one qualified trust service provider (QTSP), where your use case requires qualified trust services such as QES or QEAA
- Support for the core wallet protocols defined in the ARF
- A basic credential verification flow with an audit trail
A full architecture adds layers such as cross-border identity matching, support for multiple credential formats, integration with sector-specific attestation schemes, and automated policy enforcement at scale. Most organizations will grow into this over time.
Which eIDAS 2.0 trust services must be integrated from the start?
From the start, organizations must integrate with trust services that directly support their core use case. For many organizations, this means connecting to a Qualified Trust Service Provider (QTSP) for at least one of the following: qualified electronic signatures (QES), qualified electronic attestations of attributes (QEAAs), or qualified electronic registered delivery services (QERDS). Note that accepting credentials from a certified EUDI Wallet does not automatically require a QTSP connection. A QTSP becomes relevant when your use case involves qualified signing or the issuance or verification of qualified attestations.
eIDAS 2.0 introduces several new categories of qualified trust services beyond those in the original framework. These include qualified electronic ledgers, qualified electronic archiving services, and qualified remote signing and sealing. Not all of these are required from day one, but those that support your primary compliance obligation should be in place before you go live.
For organizations in financial services, qualified electronic signatures are typically the most urgent. For public sector bodies, the priority is often issuing and accepting person identification data (PID) and electronic attestations of attributes (EAAs), which may be issued as QEAAs, publicly issued EAAs (PuB-EAAs), or non-qualified EAAs depending on the issuer and the applicable scheme. For healthcare organizations, consent-linked signatures and secure attribute sharing tend to be the primary focus.
The practical starting point is to identify which trust services your specific use case requires, confirm that your chosen QTSP is listed on the relevant national trusted list (national trusted lists are brought together in the EU List of Trusted Lists, or LOTL), and ensure your integration follows the implementing regulations covering protocols, interfaces, and certification requirements.
How does the EUDI Wallet fit into a minimum viable architecture?
The EUDI Wallet fits into a minimum viable architecture as the primary channel through which users present verified identity credentials to your organization. In technical terms, your system needs to function as a registered relying party, a service that can request and verify credentials from a certified wallet, without storing more data than necessary.
Member States are legally required to make at least one certified EUDI Wallet available to all citizens, residents, and businesses by 24 December 2026. This is the legal deadline for Member States’ wallet obligations. It does not guarantee that every national wallet will reach the same level of maturity on that date, or that every possible cross-border use case will be fully operational throughout Europe from that point. In practice, national rollout, certification, notification, and operational interoperability are likely to develop in phases across Member States. Public sector bodies and public service providers are also required to accept notified wallets as a means of identification from 24 December 2026, for online services where electronic identification is required. For private organizations in regulated sectors, including banking, healthcare, telecoms, energy, transport, education, social security, drinking water, postal services, digital infrastructure, digital services, and very large online platforms (VLOPs) with more than 45 million users in the EU, the obligation under Article 5f of eIDAS 2.0 applies from 24 December 2027. For regulated private sector organizations, this obligation applies within contexts where strong user authentication is legally or contractually required. For VLOPs, the obligation applies where the platform requires user authentication, on the voluntary request of the user and for the minimum necessary data. The 24 December 2026 deadline is therefore an important milestone for testing wallet interactions and preparing your systems ahead of your own acceptance deadline.
For your architecture, integrating EUDI Wallet support means implementing the protocols and interfaces defined in the ARF. This includes support for OID4VP and OID4VCI, which govern how credentials are presented and issued. For proximity presentation, the relevant standard is ISO/IEC 18013-5; for online presentation, ISO/IEC TS 18013-7 applies. Your system also needs to handle selective disclosure, the wallet’s ability to share only the specific attributes you need, rather than a full identity document.
Verifying a credential presented from a wallet involves three distinct checks: verifying the issuer’s signature against the relevant national trusted list; checking the revocation status via the issuer’s status information; and validating the wallet unit attestation to confirm that the presenting wallet runs on a certified wallet solution. Only the first of these checks can be performed fully offline.
Selective disclosure is one of the most significant user-facing benefits of the wallet model. A user proving their age does not need to share their full date of birth, address, or document number. Your architecture should be designed to request only the minimum necessary attributes, both for regulatory compliance and to build user trust. Explore the available solutions to see how this can be implemented in practice.
What are the biggest compliance gaps organizations face when building for eIDAS 2.0?
The biggest compliance gaps organizations face when building for eIDAS 2.0 are relying party registration delays, underestimating the certification requirements for wallet interactions, and failing to establish a tamper-evident audit trail from the start. These gaps are not always visible until an organization tries to go live, which is why early architecture decisions matter.
Registration as a relying party is a formal process governed by implementing regulations, specifically CIR (EU) 2025/848 of 6 May 2025, and administered through the applicable national registration framework. Under this framework, a relying party registers per intended use, specifying which attributes and attestations will be requested. The wallet checks incoming requests against this registered scope. Many organizations treat registration as a final step, but delays can block your entire go-live timeline. It should be treated as a parallel workstream from the start.
A second common gap is underestimating what it means to be wallet-ready. Supporting the EUDI Wallet is not simply a matter of adding an API connection. It requires certified protocols, correct credential format handling for mdoc and SD-JWT VC, alignment with the ARF specifications, and the ability to accept every relevant notified wallet regardless of which Member State issued it. Organizations that build on uncertified infrastructure risk non-compliance even if their user experience looks correct.
The third gap is the audit trail. eIDAS 2.0 requires that identity transactions are verifiable and that evidence of compliance is maintained. Many existing systems were not designed with this requirement in mind. Retrofitting an audit layer after the fact is significantly harder than building it in from the beginning.
Other gaps worth noting include insufficient attention to cross-border identity matching requirements, incomplete handling of attribute revocation, and a lack of clarity around which national supervisory body governs your specific trust services. Cross-border interoperability under the EUDI Wallet framework operates at the level of certified wallets and registered relying parties. National registration requirements, sector-specific legislation, and the legal consequences of credentials in a given jurisdiction remain governed at national or sector level and do not disappear simply because a credential originates from another Member State.
When should organizations start building their eIDAS 2.0 architecture?
Organizations should start building their eIDAS 2.0 architecture now. With the legal deadline for Member States’ EUDI Wallet obligations set for 24 December 2026 and implementing regulations already in force, the window for preparation is narrowing. Organizations that wait risk rushed implementations, missed registrations, and costly retrofits. There will be no single European go-live moment, as national rollout and operational interoperability will develop in phases.
The regulatory timeline has moved faster than many expected. The large-scale pilot programs concluded their core testing phase, the ARF has been updated to reflect the adopted implementing regulations, and Member States are progressing toward meeting their wallet obligations by 24 December 2026. The technical specifications are stable enough to build against.
A practical starting point is a readiness assessment: map your current identity infrastructure against the minimum viable architecture requirements, identify your primary use case, and determine which trust services and wallet interactions you need to support. From there, you can prioritize your build sequence and avoid over-engineering in the early stages.
Organizations in regulated sectors such as banking, healthcare, telecoms, energy, transport, education, social security, drinking water, postal services, digital infrastructure, and digital services face additional urgency because sector-specific requirements, including the acceptance obligation under Article 5f of eIDAS 2.0, which takes effect on 24 December 2027, layer on top of the baseline obligations. Note that micro and small enterprises with fewer than 50 employees and an annual turnover or balance sheet total not exceeding 10 million euros are exempted from the Article 5f acceptance obligation. The earlier you start, the more time you have to align your compliance, legal, and technical teams before deadlines arrive. You can find sector-specific guidance for government organizations and other regulated industries to help frame your planning.
How TrustTech helps with eIDAS 2.0 compliance
Building an eIDAS 2.0-compliant architecture involves navigating a complex set of technical specifications, regulatory requirements, and integration challenges. 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.
The ID Connector is built to address the practical requirements of eIDAS 2.0 compliance, including:
- Wallet acceptance across Member States — the ID Connector accepts every relevant notified wallet regardless of the issuing Member State, so your organization does not need to manage separate integrations per wallet solution
- Verification against trusted lists — issuer signatures are checked against the relevant national trusted lists, brought together in the EU List of Trusted Lists (LOTL), as part of the credential verification flow
- Revocation status checks — the ID Connector performs revocation checks via issuer status information as part of each verification, alongside wallet unit attestation validation
- Registered attribute scope enforcement — requests to wallets are kept within the attribute scope registered under CIR (EU) 2025/848, so your organization only requests what it is authorized to receive
- Qualified signing via a connected QTSP — where your use case requires QES, the ID Connector connects to a qualified trust service provider to support qualified signing flows
- Tamper-evident audit trail — every identity transaction is logged in a tamper-evident record to support regulatory reporting and supervisory requirements
TrustTech works with organizations in financial services, government, healthcare, and other regulated sectors. Whether you are starting from scratch or updating an existing architecture, the ID Connector gives you a single integration point for EUDI Wallet acceptance and the broader identity ecosystem. Get in touch to discuss your eIDAS 2.0 readiness and find out what your next step should be.