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

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. Developers must align their systems with the Architecture and Reference Framework (ARF), which defines the protocols, interfaces, and data structures that all EUDI Wallet-compatible systems must support.

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. Apps requesting or presenting identity data must implement these protocols correctly.
• Verifiable credentials and attestations: Identity data is exchanged in the form of Person Identification Data (PID) and Electronic Attestations of Attributes (EAAs). 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 verifiable. Developers need to implement the relevant verification logic.
• Registration as a wallet relying party: Apps that request attributes from EUDI Wallets must formally register as relying parties, which involves meeting specific security and transparency requirements.

The good news is that 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 authority, and inclusion on the EU Trusted List.

For the majority of software vendors and app developers, the relevant obligation is not becoming a trust service provider but rather integrating with them. 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 rather than becoming one yourself.

Where things get more nuanced is when a software vendor wants to issue its own digital credentials or 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), which carries its own set of requirements under eIDAS 2.0, though these are generally less demanding than full QTSP status.

The practical takeaway is this: most developers need to focus on wallet integration and relying party registration, not on becoming trust service providers. Understanding TrustTech’s identity solutions can help clarify which role your organization plays in the broader eIDAS 2.0 ecosystem.

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 replace or supplement current approaches.

Under eIDAS 2.0, certain categories of services are required to accept the EUDI Wallet as a valid means of authentication. These include public sector digital services and some regulated private sector services. For apps in these categories, wallet acceptance is not optional.

For other apps, the wallet represents a significant opportunity. Instead of asking users to upload documents, complete lengthy identity checks, or re-verify themselves from scratch, your app can request verified attributes directly from the user’s wallet. The user has already been verified by their government or a trusted issuer, and that verified data can be reused securely. This reduces onboarding friction, improves data quality, and lowers the cost of compliance.

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, and how do you handle the response? This is a meaningful architectural change for many existing applications, and it is worth planning for now rather than retrofitting later.

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 and user consent principles that align closely with GDPR. Apps that continue to collect more identity data than necessary, or that lack proper consent mechanisms, carry increased data protection risk.
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 not just regulatory. It is also 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 core deadlines for eIDAS 2.0 are already in motion. Member States are legally required to make the EUDI Wallet available to all citizens, residents, and businesses by 2026, which means the infrastructure is being built and tested now. For software vendors, 2026 is the practical readiness threshold, though preparation should already be underway.

The large-scale pilot projects that tested the EUDI Wallet across 26 Member States ran through 2025, generating the technical specifications and feedback that now form the basis of the final implementation standards. These specifications are publicly available, 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 2026 to start leaves very little margin for the testing, certification, and integration work that compliance requires.

For vendors serving the public sector or operating in regulated industries such as healthcare or government services, the urgency is even higher. These sectors face the earliest and strictest obligations under the regulation, and their technology partners need to be ready in step with them. Exploring TrustTech’s resources on EUDI Wallet readiness can help you build a realistic preparation timeline for your organization.

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

Preparing for eIDAS 2.0 is not just a compliance exercise. It is a technical and strategic transition that affects how your product handles identity, trust, and data. TrustTech supports software vendors and app developers through every stage of that transition, from initial assessment to production-ready implementation.

Concretely, TrustTech offers:

• EUDI Wallet integration support: Connecting your application to the wallet ecosystem using the correct protocols, data formats, and relying party registration requirements.
• Verifiable credential infrastructure: Enabling your platform to issue, verify, and manage electronic attestations of attributes in line with eIDAS 2.0 standards.
• Qualified electronic signatures: Integrating identity-linked signing capabilities that meet the highest eIDAS assurance levels, with a complete audit trail.
• Reusable compliance flows: Replacing repeated identity checks with a single verified identity that travels securely across your organization’s touchpoints.
• Sector-specific expertise: Deep knowledge of the regulatory requirements facing organizations in healthcare, finance, government, and other regulated industries.

TrustTech’s platform is built on European digital identity standards and is eIDAS 2.0 ready by design, which means you are not building on a foundation that will need to be replaced as the regulation matures. Whether you are starting from scratch or adapting an existing application, TrustTech provides the expertise and infrastructure to get you there efficiently.

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.