How does eIDAS 2.0 affect software vendors and app developers?

Developer's hands near a laptop beside an EU passport and NFC smart card on a glass desk, symbolizing European digital identity verification.

eIDAS 2.0, Regulation (EU) 2024/1183, amends Regulation (EU) 910/2014 and directly affects software vendors and app developers who build applications that handle identity verification, authentication, or document signing for users in the EU. If your app lets users log in, verify their identity, or sign documents, the regulation introduces new technical standards, wallet integration requirements, and compliance obligations you need to plan for. This article walks through the most important questions developers and vendors are asking right now.

Which types of software and apps fall under eIDAS 2.0?

eIDAS 2.0 applies to any software or application that provides or relies on digital identity services within the EU. This includes apps that authenticate users, verify identity, issue credentials, or facilitate electronic signatures. If your product touches any of these functions for EU citizens, residents, or businesses, eIDAS 2.0 is relevant to you.

More specifically, the regulation creates obligations for two broad categories of software actors. The first category is relying parties: apps and services that accept identity data from users, such as banking apps, healthcare portals, government service platforms, or any application with a login or onboarding flow. The second category is trust service providers: companies that issue certificates, electronic signatures, or other trust services.

Beyond these two groups, eIDAS 2.0 also introduces the concept of wallet relying parties. These are apps that will accept or request attributes from the European Digital Identity Wallet. Any developer building a service that wants to verify a user’s age, professional qualifications, or national identity through the EUDI Wallet will fall into this category and must register accordingly with the relevant national competent authority under CIR (EU) 2025/848, adopted on 6 May 2025.

In short, the scope is broad. Consumer-facing apps, enterprise software, identity platforms, and developer tools all have a stake in understanding where they fit within the eIDAS 2.0 framework.

What new technical requirements does eIDAS 2.0 introduce for developers?

eIDAS 2.0 introduces a set of technical requirements centered on interoperability, security, and standardized data formats. The legally binding requirements are set out in the implementing acts adopted by the European Commission. The Architecture and Reference Framework (ARF) provides the technical elaboration of those requirements, defining the protocols, interfaces, and data structures that all EUDI Wallet-compatible systems must support. Developers should treat the ARF as the authoritative technical reference, while understanding that the implementing acts carry legal force.

The key technical requirements developers need to be aware of include:

  • Standardized protocols and interfaces: The ARF specifies which communication protocols must be used for wallet interactions. For credential issuance, the ARF prescribes OID4VCI; for presentation, OID4VP and ISO/IEC TS 18013-7 for online flows, and ISO/IEC 18013-5 for proximity presentation. Apps requesting or presenting identity data must implement these protocols correctly.
  • Credential formats and attestations: Identity data is exchanged in the form of Person Identification Data (PID) and Electronic Attestations of Attributes (EAAs), using the credential formats mdoc and SD-JWT VC as specified in the ARF. Developers need to handle these data formats in their applications.
  • Selective disclosure: Users must be able to share only the specific attributes needed for a transaction. Apps cannot request more data than is strictly necessary, which has implications for how identity requests are designed.
  • Cryptographic verification: All identity data exchanged through the wallet ecosystem must be cryptographically signed and tamper-evident. Verifying a presentation involves three distinct checks: verifying the issuer’s signature against the relevant national trusted list (part of the EU List of Trusted Lists); checking the revocation status through 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.
  • Registration as a wallet relying party: Under CIR (EU) 2025/848, apps that request attributes from EUDI Wallets must formally register as relying parties with the national authority of the Member State in which they are established, before requesting any wallet data. Registration is per intended use: the relying party declares which attributes and attestations it will request, and the wallet checks incoming requests against that registered scope.

The reference implementation published by the European Commission is open source, which gives developers a practical starting point for understanding the technical specifications before building their own integrations.

Do app developers need to become qualified trust service providers?

No, most app developers do not need to become qualified trust service providers (QTSPs). Becoming a QTSP is a specific regulatory status reserved for organizations that issue qualified electronic signatures, qualified certificates, or other high-assurance trust services. It involves formal auditing, supervision by a national competent authority, and inclusion on the relevant national trusted list.

For the majority of software vendors and app developers, the relevant obligation is integrating with trust services. If your app needs to verify a user’s identity at a high assurance level, or enable qualified electronic signatures, you connect to a QTSP through their APIs. A relying party does not need a QTSP simply to accept wallet presentations. A QTSP becomes relevant when your use case involves qualified electronic signatures or qualified attestations of attributes (QEAAs).

Where things get more nuanced is when a software vendor wants to issue its own digital attestations. For example, a company that wants to issue employee credentials or professional qualifications into a user’s EUDI Wallet. In that case, the vendor may need to become a provider of Electronic Attestations of Attributes (EAAs). The regulation distinguishes between qualified EAAs (QEAAs), public body EAAs (PuB-EAAs), and non-qualified EAAs, each carrying its own set of requirements. Issuing attestations of attributes is itself a trust service under eIDAS 2.0.

The practical takeaway: most developers need to focus on wallet integration and relying party registration. It is also worth noting that a software vendor or technology supplier that processes wallet data on behalf of a client does not thereby become the relying party. The registration obligation sits with the organization that delivers the service to the end user.

How does the EUDI Wallet affect apps that currently use login or identity verification?

The EUDI Wallet introduces a new, standardized channel through which users can authenticate and share identity attributes with apps. For applications that currently handle login or identity verification, this means adding wallet-based flows alongside existing methods, and in some cases it may eventually supplement or replace current approaches.

Under eIDAS 2.0, certain categories of services are required to accept the EUDI Wallet as a valid means of authentication. From 24 December 2026, public sector bodies must accept notified EUDI Wallets for online services that require electronic identification. From 24 December 2027, Article 5f extends an acceptance obligation to relevant regulated private sector services where strong user authentication is legally or contractually required. The sectors covered include banking and financial services, healthcare, telecoms, energy, transport, education, social security, drinking water, postal services, digital infrastructure, and digital services. Very large online platforms (VLOPs) are covered by a separate provision of Article 5f: for VLOPs, the obligation applies where the platform requires user authentication, on the voluntary request of the user and for the minimum necessary data. 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 exempted.

It is worth noting that EUDI Wallets are provided or mandated by individual Member States, each of which certifies and notifies its own wallet solution. Governance is a shared responsibility: the European Commission manages the legal framework and adopts implementing acts, Member States are responsible for their national wallet solutions and for supervising actors within their jurisdiction, and the European Digital Identity Cooperation Group supports cross-border alignment. A relying party must be capable of accepting every relevant notified wallet, regardless of which Member State issued it, and does not select a preferred wallet provider.

For apps outside the mandatory categories, the wallet represents a meaningful opportunity. Your app can request verified attributes directly from the user’s wallet, using selective disclosure to obtain only the attributes the transaction requires. The user approves each presentation individually. This reduces onboarding friction, improves data quality, and can lower the cost of compliance. Use of the wallet remains voluntary for users.

The shift also changes the UX design challenge. Rather than building your own identity verification flow, you design a wallet interaction: what attributes do you need, how do you request them within your registered scope, and how do you handle the response? This is a meaningful architectural change for many existing applications, and it is worth planning for now.

What are the compliance risks for software vendors that ignore eIDAS 2.0?

Software vendors that ignore eIDAS 2.0 face a combination of legal, operational, and competitive risks. The most immediate legal risk is non-compliance with mandatory requirements, particularly for vendors serving regulated sectors or public sector clients where wallet acceptance and specific assurance levels are legally required.

The compliance risks break down into several practical areas:

  1. Regulatory penalties: eIDAS 2.0 is an EU regulation, meaning it has direct legal force across all Member States. Non-compliant services operating in regulated sectors can face enforcement action from national supervisory authorities.
  2. Loss of public sector contracts: Government and public sector clients will increasingly require eIDAS 2.0 compliance as a procurement condition. Vendors without wallet integration or the correct assurance levels risk being excluded from these opportunities.
  3. Inability to serve regulated industries: Sectors such as finance, healthcare, and pharmaceuticals are moving toward eIDAS 2.0-aligned identity infrastructure. Software vendors that are not ready will struggle to meet the requirements of clients in these industries.
  4. Data protection exposure: eIDAS 2.0 reinforces data minimization principles that align closely with GDPR. Apps that continue to collect more identity data than necessary carry increased data protection risk. A relying party also needs its own lawful basis under GDPR for processing identity data received from the wallet. Approving a wallet presentation is not the same as giving consent as a GDPR legal basis.
  5. Competitive disadvantage: As wallet-ready competitors offer faster, more trusted onboarding experiences, vendors that have not adapted will find it harder to win and retain customers.

The risk is both regulatory and strategic. Organizations in financial services and other regulated sectors are already planning their eIDAS 2.0 roadmaps, and they will expect their software vendors to be ready alongside them.

When do software vendors need to be ready for eIDAS 2.0?

The legal deadline for Member States to make the EUDI Wallet available to all citizens, residents, and businesses is 24 December 2026. That deadline governs Member States’ obligations under the regulation, but it does not guarantee that every national wallet will have reached 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. Practical interoperability and national rollout are likely to develop in phases, as individual Member States certify and notify their wallet solutions and relying party registration frameworks become operational at national level.

For software vendors, preparation should already be underway. The first four Large Scale Pilots ran from April 2023 to 2025 and have concluded. They covered a range of use cases across the consortia: EWC focused on digital travel credentials, payments, and organisational digital identity; POTENTIAL covered government services, bank account opening, SIM registration, mobile driving licences, remote qualified signing, and e-prescriptions; NOBID addressed payments; and DC4EU covered education and social security. A second wave of pilots started in 2025, with WE BUILD addressing business wallets and payments, and APTITUDE covering travel, ticketing, vehicle registration, and payments. The technical specifications and feedback from the first pilots are publicly available and now form the basis of the final implementation standards, which means developers have the information they need to start building.

A realistic timeline for software vendors looks like this: organizations that have not yet assessed their eIDAS 2.0 exposure should do so immediately. Those that have identified the need for wallet integration or relying party registration should be in active development or planning. Waiting until late 2026 to start leaves very little margin for the testing, certification, and integration work that compliance requires, and national frameworks in some Member States may reach operational readiness earlier than others.

For vendors serving the public sector or operating in regulated industries such as healthcare or government services, the urgency is higher. These sectors face the earliest obligations under the regulation, and their technology partners need to be ready in step with them.

How TrustTech helps software vendors and app developers prepare for eIDAS 2.0

Preparing for eIDAS 2.0 is a technical and strategic transition that affects how your product handles identity, trust, and data. TrustTech’s product for this is the ID Connector: 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.

Concretely, the ID Connector handles:

  • EUDI Wallet acceptance: Connecting your application to the wallet ecosystem using the correct protocols, credential formats, and relying party registration requirements under CIR (EU) 2025/848.
  • Trust management and verification: Verifying issuer signatures against the relevant national trusted lists, checking revocation status through issuer-provided status information, and validating wallet unit attestations to confirm that a presenting wallet runs on a certified wallet solution.
  • Attribute scope enforcement: Ensuring that your application requests only the attributes declared in your registered intended use, in line with the selective disclosure requirements of the regulation.
  • Qualified electronic signing: Integrating signing capabilities linked to verified identity, connected to a qualified trust service provider, meeting the highest eIDAS assurance levels with a tamper-evident audit trail.
  • Reusable verified identity: Enabling verified identity data to be reused securely across your organization’s services, reducing repeated identity checks for users in financial services, healthcare, pharma, and government.

TrustTech’s platform is built on European digital identity standards and is designed for eIDAS 2.0 from the ground up, which means you are building on a foundation that keeps pace with the regulation as it matures. Whether you are starting from scratch or adapting an existing application, the ID Connector gives you a defined integration path to wallet acceptance and compliant identity verification.

Ready to understand what eIDAS 2.0 means for your specific product or platform? Get in touch with TrustTech and let’s map out your path to compliance together.