Before adopting a managed EUDI Wallet connector, IT teams should ask about compliance coverage, data handling, integration effort, vendor dependency, and security standards. These questions determine whether a connector genuinely handles the technical and regulatory complexity of eIDAS 2.0 acceptance, or leaves your team to figure out the hard parts alone. The sections below work through each question in turn.
What does a managed EUDI Wallet connector actually do?
A managed EUDI Wallet connector is an integration layer that connects your existing systems to certified European Digital Identity Wallets, so your services can accept wallet-based identification, login, and qualified signing without building that infrastructure from scratch. The connector handles the technical requirements for wallet acceptance on your behalf, including trust verification and protocol support.
In practical terms, the connector sits between your business processes and the wallet ecosystem. When a user presents their EUDI Wallet, the connector verifies the cryptographic signature of the issuing authority against the relevant national trusted list, checks the revocation status of the attestation, and validates the wallet unit attestation to confirm the presenting wallet runs on a certified wallet solution. Identity attributes arrive already signed by the party that issued them, so the data is tamper-evident when it reaches your system.
A well-built connector also covers identity methods beyond the EUDI Wallet. 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.
Which eIDAS 2.0 compliance requirements does the connector need to meet?
A compliant EUDI Wallet connector must support the credential formats and exchange protocols mandated by the Architecture and Reference Framework (ARF): mdoc (ISO/IEC 18013-5 for proximity, ISO/IEC TS 18013-7 for online) and SD-JWT VC. It must also implement OID4VP for presentation and OID4VCI for issuance flows, and apply the three verification checks that eIDAS 2.0 requires for every wallet interaction.
Those three checks are non-negotiable:
- Verify the issuer’s signature against the national trusted list of the relevant Member State.
- Check the revocation status of the attestation using the status information the issuer publishes separately.
- Validate the wallet unit attestation to confirm the wallet presenting the credential runs on a certified wallet solution.
Skipping the second check means your system may accept attestations that have already been revoked. Skipping the third means you cannot confirm the wallet itself meets certification requirements.
Beyond verification, your organisation also has registration obligations. Under CIR (EU) 2025/848 of 6 May 2025, relying parties must register with a national authority in their Member State of establishment before requesting wallet data. At registration, you declare exactly which attributes and attestations you will request per intended use. The wallet checks every request against that registered scope and stops the presentation if you request more than you declared. Requesting attributes outside your registered scope is an explicit ground for revocation of your registration. Ask any connector vendor whether their product enforces scope boundaries automatically or leaves that to your team.
The private sector acceptance obligation under Article 5f applies from 24 December 2027 to regulated sectors where strong user authentication is legally or contractually required, including financial services, healthcare, telecoms, energy, transport, and very large online platforms under the DSA. 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.
How does a managed connector handle data privacy and sovereignty?
A managed EUDI Wallet connector should support selective disclosure, meaning users share only the attributes your service actually needs, and your system receives only those attributes. The connector must not request more than your registered scope, and your own logging practices must reflect that boundary too.
There is an important distinction to keep in mind. The wallet’s transaction dashboard belongs to the user: it shows which party received which data, and the user can submit a deletion request to the relying party from there. That dashboard is not a logging facility for your organisation. For your own records, log that you stayed within your registered attribute scope, not the full set of attributes presented. Logging the full presented set undoes the selective disclosure you offered at the front end.
On the processor side: if you use a vendor to run wallet verification on your behalf, that vendor is a data processor under Article 28 GDPR, not a relying party. The registration obligation stays with your organisation. Confirm this split of responsibilities in your data processing agreement before go-live.
Also ask whether the connector stores verified identity data between sessions. Reusing verified data across interactions reduces friction for returning users, but the connector must handle that data under your GDPR obligations, not its own. Understand exactly where data is processed, how long it is retained, and on what legal basis.
What integration effort should IT teams realistically expect?
The integration effort for a managed EUDI Wallet connector depends primarily on how your existing authentication and onboarding flows are built. A connector that exposes a single API endpoint for all wallet types and identity methods reduces the scope significantly compared to building separate integrations per wallet or per Member State.
Realistic factors to assess before starting:
- Existing identity infrastructure: If your systems already handle national eIDs or bank IDs through an identity provider, adding wallet acceptance through the same interface is a smaller lift than starting from scratch.
- Credential format support: Your backend needs to handle both mdoc and SD-JWT VC responses. If your current stack only processes one format, plan for that work.
- Registration process: Completing registration under CIR (EU) 2025/848 takes time and requires you to define your attribute scope per intended use before you can test in production.
- Testing environment: Ask whether the vendor provides a sandbox that covers certified European wallets from multiple Member States, not just a single reference implementation.
- Scope of rollout: Identification, login, and qualified signing each involve different flows. Qualified signing requires a qualified trust service provider to issue the signature; the connector facilitates the identity check that precedes it, but the QES itself comes from a QTSP.
A managed connector should abstract the trust management layer, so your team does not need to maintain connections to individual national trusted lists or track wallet certification status across 27 Member States. If the vendor expects you to manage that yourself, the integration effort is substantially higher than advertised.
How should IT teams evaluate vendor lock-in and long-term flexibility?
Vendor lock-in risk is real in the EUDI Wallet space because the technical specifications are still evolving. The ARF is currently at version 3.0.0 and undergoes revision rounds. A connector that hard-codes assumptions from an earlier version may require significant rework as implementing acts are updated.
Key questions to put to any vendor:
- How do you handle ARF version updates, and what is the process for rolling out changes to customers?
- Does the connector use open, standardised protocols (OID4VP, OID4VCI, SD-JWT VC, mdoc) throughout, or does it introduce proprietary layers?
- Can your organisation switch to a different connector without rebuilding your identity flows from scratch?
- What happens to your registered attribute scope and access certificates if you migrate to another provider?
Standardised protocols are your best protection against lock-in. A connector built entirely on OID4VP, OID4VCI, and the ARF-mandated formats gives you a migration path if you ever need one. Proprietary data models or custom authentication layers make that path much harder.
Also consider the vendor’s update cadence relative to the regulatory timeline. The private acceptance obligation takes effect on 24 December 2027, and implementing acts will continue to be refined before and after that date. A vendor that lags behind the specification cycle creates compliance risk for your organisation, not just a technical inconvenience.
What security and availability standards should the connector meet?
A managed EUDI Wallet connector processes verified identity data at a high assurance level, which means the security and availability requirements are correspondingly high. The EUDI Wallet operates at assurance level high under eIDAS 2.0, and your connector must be capable of handling that level of trust without introducing weaknesses.
On the security side, ask for evidence of the following:
- Certification: ISO 27001 is a baseline for information security management. For healthcare contexts, NEN 7510 is the relevant Dutch standard. Ask which certifications the vendor holds and when they were last audited.
- Cryptographic handling: Private keys associated with attestations must never leave the secure cryptographic device of the wallet unit. Your connector should not store or replicate those keys. Confirm how the vendor handles key material on their infrastructure.
- Tamper-evident logging: The connector should produce audit logs that confirm you operated within your registered attribute scope, without recording the full set of presented attributes in a way that defeats selective disclosure.
On availability, consider what happens if the connector is unreachable during a user authentication attempt or a signing session. Ask for documented SLAs, incident response procedures, and whether the connector architecture includes redundancy across regions. For sectors like financial services and healthcare, downtime in the identity layer has direct operational consequences.
Finally, ask how the vendor handles the revocation check. Revocation status requires a live call to the issuer’s status endpoint. If the connector caches revocation data, understand the maximum staleness of that cache and whether that is acceptable for your risk profile.
How the ID Connector helps with EUDI Wallet integration
The ID Connector from TrustTech 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.
For IT teams working through the questions above, the ID Connector addresses the core integration challenges directly:
- Trust management behind wallet acceptance is handled automatically, including signature verification against national trusted lists, revocation checks, and wallet unit attestation validation.
- Verified identity data is reusable across interactions, so a user who has already been identified does not need to repeat the process for a subsequent login or signing session.
- The connector covers identification, login at a high assurance level, and qualified signing via a connected QTSP, within a single integration.
- One interface covers certified European wallets alongside the eIDs, bank IDs, and identity documents your users already have today.
The ID Connector is used by organisations in financial services, healthcare, pharmaceuticals, and government, where verified identity and regulatory compliance are operational requirements. Contact TrustTech to discuss how the ID Connector fits your existing systems and your timeline for eIDAS 2.0 acceptance.