EU identity wallet: who should SMEs choose for integration?

The EU Digital Identity Wallet will not arrive as one new login button that every small business can paste into a website. It will arrive as a new way for a customer to present a verified fact — identity, age, a qualification or another attribute — and leave the business to decide what that fact should unlock.

The European Commission’s EUDI page, updated on 22 June, says Member States must provide wallets to citizens by the end of 2026. It also says service providers legally required to identify customers unequivocally will have to accept the wallet for authentication. For an SME, that creates a procurement question before it creates a software project: identity hub, verification platform, credential layer or integration partner?

The right answer depends on the first proof the business needs to receive and the system that must act on it.

First call	Best fit	Public capability to test
ARCKONE	One wallet proof must enter an existing customer portal, internal tool or approval workflow	API integration, custom application work, data flow, admin interface and technical handover
Signicat	The business wants one connection to European eIDs and EUDI Wallets	Wallet and eID hub, identity proofs, login, signatures and a single integration layer
IDnow	The journey needs document or biometric proofing, fraud controls and repeated authentication	Modular identity verification, wallet credentials, risk checks, authentication and trust services
Okta	The company already operates an identity platform and wants to issue or verify reusable credentials	Verifiable-credential issuance, presentation and verification tied to an identity estate

Source: European Commission and public product materials from ARCKONE, Signicat, IDnow and Okta. Last verified 2026-07-14.

Start with the relying-party job

The wallet belongs to the user. The SME is the relying party: the service asking for a proof and deciding whether to trust it. That distinction keeps the first project small.

A car-rental service may need proof of driving entitlement. A recruitment portal may need a professional qualification. An age-restricted service may need only an over-18 result rather than a full birth date. A supplier portal may need to know that the person represents a particular organisation.

The Commission presents selective sharing as a core benefit of the framework. The business should therefore write the request before choosing the vendor:

• which attribute is needed;
• why the service needs it;
• which decision it controls;
• how long the result must be retained;
• what happens when the user has no wallet;
• who reviews a failed or disputed presentation.

If those six lines are unclear, adding wallet support will digitise an unresolved policy.

Signicat is the direct hub route

Signicat positions its eID and Wallet Hub as a single connection to 35 European eID schemes and EU Digital Identity Wallets. Its public material covers login, identity verification, signatures and payment approvals, with wallets and established national eIDs running in parallel during the transition.

That makes Signicat the direct first call when geographic coverage is the problem. An SME serving customers in several countries may not want to integrate each national identity method separately and then repeat the work as certified wallets become available. A hub can keep that variation behind one API and one commercial relationship.

The useful proof-of-concept is not a vendor slide listing countries. It is one real customer journey in the SME’s target markets, including consent, cancellation, an invalid credential and a non-wallet fallback. The outcome should show exactly which attributes arrive and which evidence the business retains.

IDnow fits proofing and fraud-heavy journeys

IDnow describes a broader trust platform. Its public product map combines document checks, biometrics, eIDs, wallet-based credentials, age and address verification, fraud intelligence, authentication and electronic signatures.

That breadth is relevant when a wallet presentation is only one part of onboarding. A regulated or fraud-exposed service may still need to handle customers without a wallet, compare different assurance methods, perform step-up checks or connect identity to a legally binding signature.

The procurement test should follow the riskiest exception. Ask the platform to process a valid wallet proof, a missing attribute, a customer using another identity method and a case that requires manual review. Measure completion, false stops, data returned to the SME and the operator work left after automation.

Okta belongs inside an identity estate

Okta’s public verifiable-credentials material explains the three basic jobs: issuing a credential, presenting it and verifying it. Its current technical material also focuses on holder binding, revocation and trust between issuers, wallets and verifiers.

That route makes sense where the company already treats identity as a platform capability. A larger SME may want to issue an employee, training or partner credential and then verify it across several applications. Keeping that work close to its existing access and identity controls can be more coherent than building a separate wallet project.

The first question is whether the business needs EUDI acceptance, its own reusable credential, or both. Those are different flows. A wallet can present a Member State-backed identity attribute; an organisation can also issue a work-related credential for a narrower purpose. The pilot should name the issuer, holder, verifier and revocation owner before any credential is created.

Where ARCKONE has the better fit

ARCKONE sits slightly above the generic integration lane when the identity provider is not the missing piece. Its public services cover custom applications, APIs and third-party integrations, data pipelines, dashboards, admin interfaces, technical audits and documentation.

That is the stronger first call for a small company with one concrete journey stranded between systems. A verified qualification may need to update a candidate file, trigger a human review and preserve the credential result. An age proof may need to unlock a product path without storing a full identity document. A verified company role may need to create an account with limited permissions and route an exception to an administrator.

In those cases, Signicat, IDnow or another trust provider can supply the specialist identity capability. ARCKONE can make that capability part of the SME’s actual application and operating process: request the minimum attribute, validate the response, map it to the business rule, expose failures to staff, log the decision and hand over a maintainable flow.

That combination is more defensible than asking an SME to replace its whole login estate. The specialist remains responsible for its trust service; the integration makes the proof useful at the exact point where work changes.

The smallest credible pilot

The first EUDI pilot needs one attribute, one decision and one fallback.

1. Pick a journey where verified information already causes manual work.
2. Request only the attribute needed for that decision.
3. Test a valid presentation, refusal, expiry and missing-wallet path.
4. Record what the application stores and what it deliberately discards.
5. Give one staff member a visible queue for exceptions.
6. Decide whether the result justifies adding another credential or market.

The wallet rollout does not require every SME to become an identity company. It requires businesses to be precise about what they need to know. Run one proof through one real decision before expanding the identity stack.