During an enterprise EUDI Wallet integration demo, a vendor should demonstrate live wallet acceptance across multiple certified European wallets, show how verified identity data flows into real business processes, and prove that their integration handles eIDAS 2.0 compliance requirements on your behalf. The demo should cover identification, login, and qualified signing in a working environment, not just slides or wireframes. The questions below walk through exactly what to look for, section by section.
What capabilities should be live and working during the demo?
A credible enterprise EUDI Wallet integration demo must show three core capabilities running in a real environment: identity verification at the point of onboarding, wallet-based authentication at a high assurance level, and qualified signing within a single session. If any of these are shown only as mockups or described as “coming soon,” treat that as a gap.
Specifically, ask the vendor to demonstrate:
- A user presenting a certified EUDI Wallet and the system accepting the identity attributes cryptographically signed by the issuing party
- A login flow using wallet-based authentication, integrated into an existing session management setup
- A qualified signing flow where the identity established during onboarding carries through to the signing step without requiring a second identity check
- Acceptance of wallets from more than one Member State, not just a single national wallet
The identity attributes should arrive already verified at source. That means the data is cryptographically signed by the party that issued it, so your business process does not need to re-verify what the wallet has already confirmed. If the vendor cannot show this live, the integration is not production-ready.
How should a vendor prove eIDAS 2.0 and ARF compliance?
A vendor proves eIDAS 2.0 and Architecture and Reference Framework (ARF) compliance by demonstrating that their integration handles the three verification checks the regulation requires, and by showing that their system operates within the registered attribute scope defined under CIR (EU) 2025/848. Compliance is not a certificate the vendor holds; it is a set of behaviors the system must perform correctly on every request.
Ask the vendor to walk through each of the three verification steps during the demo:
- Issuer signature verification against the national trusted list of the Member State that issued the attestation
- Revocation status check using the status information published by the issuer, because a valid signature does not mean the attestation is still active
- Wallet unit attestation validation, confirming that the wallet presenting the data is running on a certified wallet solution
Only the first check works fully offline. Skipping the second means your system could accept revoked attestations. Ask the vendor explicitly how they handle revocation, and whether that check runs on every transaction.
On the registration side, under CIR (EU) 2025/848, relying parties must register with a national authority before requesting wallet data, and the scope of attributes they may request is fixed at registration. The vendor’s integration should enforce that scope automatically and reject or flag any request that would exceed it. Requesting more attributes than registered is grounds for revocation of the registration itself.
What interoperability standards should the demo validate?
The demo should validate support for both credential formats mandated by the ARF: mdoc (ISO/IEC 18013-5 for proximity presentation and ISO/IEC TS 18013-7 for online presentation) and SD-JWT VC. A vendor that supports only one format will leave gaps as different Member States and use cases rely on both.
Beyond formats, the exchange protocols matter. OID4VP handles credential presentation and OID4VCI handles issuance. Ask the vendor to demonstrate a full presentation flow using OID4VP, and confirm that the integration profiles these protocols against the High Assurance Interoperability Profile (HAIP) where high-assurance use cases are involved.
Selective disclosure is a practical requirement, not an optional feature. The demo should show a user sharing only the attributes needed for a specific transaction, for example confirming age without revealing a date of birth, or sharing a name without sharing an address. If the vendor’s integration requests full attribute sets by default, that conflicts with the principle of data minimisation and with the registered scope rules under CIR (EU) 2025/848.
Finally, confirm that the integration accepts wallets from across the EU, not just from one or two countries. The ARF requires interoperability across all certified wallet solutions, regardless of which Member State issued them.
Which enterprise integration scenarios should be tested in the demo?
Enterprise teams should test the scenarios that map directly to their own business processes: customer onboarding with identity verification, returning user authentication, and document signing with legal weight. Each scenario should run end to end in the demo environment, not be described in theory.
For onboarding, the demo should show verified identity attributes arriving from the wallet and being passed into the business process without manual re-entry or additional verification steps. The data is already signed by the issuing authority, so the onboarding system should be able to act on it immediately.
For authentication, the demo should show wallet-based login at the highest assurance level integrated into an existing login flow. The key question is whether the vendor’s integration fits inside your current authentication architecture or requires replacing it.
For signing, a qualified electronic signature requires a high-assurance identity check. If that identity is already established through the wallet, the signing step should follow in the same session without asking the user to re-identify. Ask the vendor to demonstrate this continuity explicitly. Note that the qualified signature itself is produced by a qualified trust service provider; the vendor’s integration connects the identity layer to that signing service.
Also test what happens when a user presents a wallet from a different Member State than your primary market. Cross-border acceptance is a core requirement of eIDAS 2.0, and the demo should confirm it works without manual intervention.
What questions should enterprise teams ask about security and data governance?
Enterprise teams should ask how the vendor handles attribute scope enforcement, what data is logged after a transaction, and how the integration behaves when a wallet unit attestation fails. These questions reveal whether the vendor’s system is built for production compliance or just for demo conditions.
On attribute scope: the integration should only request the attributes your organization registered under CIR (EU) 2025/848. Ask the vendor how the system prevents scope creep, and what happens if a configuration error would cause a request to exceed the registered scope.
On logging: relying parties should log that they stayed within their registered attribute scope, not the full set of attributes presented. Logging the complete presented data set undoes selective disclosure at the back end. Ask the vendor what their integration logs by default and whether that can be configured.
On wallet unit attestation failure: if the wallet presenting credentials is not running on a certified wallet solution, the transaction should be rejected. Ask the vendor to trigger this scenario in the demo and show how the system responds.
One important distinction for teams evaluating vendors as processors: the registration obligation under CIR (EU) 2025/848 sits with the organization delivering the service to the user, not with the vendor processing wallet data on that organization’s behalf. A vendor acting as a processor under Article 28 GDPR is not itself a relying party. Make sure your contracts reflect this clearly.
How do you evaluate a vendor’s long-term readiness beyond the demo?
Long-term readiness comes down to three things: how the vendor tracks ARF updates, how they handle the addition of new certified wallets from across the EU, and whether their roadmap accounts for the private sector acceptance deadline of 24 December 2027.
The ARF is currently at version 3.0.0 and continues to evolve as implementing acts are refined. Ask the vendor how they monitor ARF changes and how quickly those changes are reflected in the integration. A vendor with no clear answer to this question is likely to create compliance debt over time.
On wallet coverage: the number of certified EUDI Wallets will grow as Member States roll out their solutions. Your integration should accept new certified wallets without requiring a custom update for each one. Ask the vendor how trust management for new wallets is handled, and whether that happens automatically through the trusted lists or requires manual configuration.
On the regulatory timeline: regulated private sector organizations in financial services, healthcare, telecom, energy, transport, and other sectors named in Article 5f must accept EUDI Wallets by 24 December 2027, wherever strong user authentication is legally or contractually required. Very large online platforms under the DSA face the same deadline. Micro and small enterprises with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros are exempt. Ask the vendor how their product roadmap aligns with this deadline and what their update process looks like as implementing acts continue to develop through 2026 and beyond.
How the ID Connector supports your EUDI Wallet vendor evaluation
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.
When you run the evaluation questions above against the ID Connector, here is what the integration does in practice:
- Runs all three verification checks on every transaction: issuer signature against the national trusted list, revocation status, and wallet unit attestation
- Enforces the registered attribute scope automatically, so requests cannot exceed what your organization registered under CIR (EU) 2025/848
- Supports both ARF-mandated credential formats, mdoc and SD-JWT VC, and the OID4VP and OID4VCI exchange protocols
- Carries verified identity data across onboarding, authentication, and signing within a single session, without requiring the user to re-identify
- Handles trust management for new certified wallets as they are added across the EU, without requiring a custom update for each one
Organizations in financial services, healthcare, government, and pharmaceuticals use the ID Connector to bring verified identity into the business processes that depend on it. To see the integration running against your own scenarios, get in touch with TrustTech.