eIDAS 2 and EU Digital Identity Wallets: What Changes for eSignature Workflows

A contractor proves their identity with an EU Digital Identity Wallet. Does that mean they have signed the service agreement? No. The workflow still needs to establish their authority, present the approved agreement, capture the signing action, and validate the resulting document.

Wallets add a way to exchange trusted identity information and access signing services. The practical opportunity is to reduce repeated identity-document collection while keeping each decision connected to the right agreement.

What is changing, and what is available today?

The Commission’s EUDI framework overview says Member States must provide wallets by the end of 2026. Wallets support identity data, attestations of attributes, and qualified electronic signatures. That timetable does not mean every organization, wallet, or signing provider already supports every intended transaction.

The Commission’s trust-services guidance maintains the distinction between electronic, advanced, and qualified signatures. A qualified electronic signature has the legal effect of a handwritten signature across the EU. Free wallet-based qualified signatures for natural persons apply to non-professional purposes; do not assume that a business signing route is free.

Scope reviewed: November 9, 2026. Confirm the applicable national rules, transaction requirements, and actual provider availability before implementation.

FormKiQ capability boundary: the current eSignature Integration module connects to DocuSign. The wallet workflow below is an integration design example, not a claim of native EUDI Wallet support or built-in cryptographic or qualified-signature validation.

Example: onboard a contractor and sign a service agreement

A company is onboarding a contractor who will sign for a small supplier. Its approved process requires verified identity, evidence of authority to represent that supplier, and a specified signature level. The initial design adds wallet identity verification before an established signing service. Use five stages, with a clear result at each handoff.

1. Fix the agreement and the identity request

Create a transaction reference and select the approved agreement version. Record the expected signer role, supplier, signature requirement, and necessary identity attributes. Request only what the process needs; a name or verified attribute may be sufficient without collecting a full identity-document copy.

The organization receiving wallet information is the relying party. Plan its registration, authentication, and verification responsibilities, whether implemented directly or through an intermediary. The official EUDI Architecture and Reference Framework trust model describes relying-party registration, user-approved disclosure, and presentation verification.

2. Verify the wallet presentation and signing authority

The contractor approves the requested disclosure in their wallet. The receiving integration checks the presentation using the applicable protocol and trust rules, including issuer trust, validity or status checks, holder binding, and binding to the current request. Store the verification outcome and relevant references against the onboarding transaction.

Identity does not establish authority to bind a supplier. Verify that separately through an appropriate attestation or another approved source. If authority cannot be established, route the case for review rather than treating successful wallet authentication as permission to sign.

3. Present the agreement and choose the signing route

Show the approved agreement and make the requested signing action clear. Link the signing transaction to the verified person and the agreement version. Approval to disclose wallet attributes is a separate action from agreement acceptance.

An established signing service may remain the appropriate route. Where required and supported, a wallet-enabled qualified-signature service may be another route. Confirm the provider’s actual signature capability and integration contract; a wallet identity check does not upgrade an ordinary signature to a qualified one.

If the agreement changes after review, require the revised version to be reviewed and signed. Do not carry an earlier signing decision onto different content.

4. Validate the returned result before activation

Reconcile the returned document, expected signers, transaction references, and provider status. Assign cryptographic validation to an appropriate validator or trust service. Where qualified status matters, its assessment must cover the relevant certificate and trust-service status, not just the provider’s completion callback.

Retain the validation report with the exact signed artifact, validation time, and policy used. Keep technical validation separate from the business decision to activate the agreement. A failed or indeterminate result should have an owner and review path.

5. Preserve the agreement and necessary evidence

Connect the signed artifact, approved source version, identity-verification outcome, authority decision, signing references, and validation report. Retain only the identity information justified by the process and applicable retention rules, with access appropriate to its sensitivity.

Assign responsibility for later validation and preservation measures, such as archival timestamps where needed. Ordinary document storage does not by itself provide qualified preservation. The organization should be able to retrieve and explain the record after changing wallet, identity, or signing providers.

Start with wallet verification, then the existing signing route

For a FormKiQ implementation, a practical first scope is to add wallet-based identity verification before the existing DocuSign integration, provided that route meets the transaction’s signature requirements. This is proposed integration work to scope and implement. It requires a wallet verification service and application logic connecting its result to the agreement workflow.

1. Request and verify identity through a wallet service

   Integrate a specialist verification service or implement the relying-party interface directly. Confirm supported wallets, credentials, registration responsibilities, and the checks the service performs. Connect its verification result to the onboarding transaction.

2. Connect the verified person to the signing request

   The application checks that verification is current, resolves the signer’s authority, and associates the person with the intended recipient and approved document version. It then creates the DocuSign envelope and recipient signing view through the existing integration. A successful wallet check alone does not establish who completed a later signing session; agree how that connection is maintained with the signing provider.

3. Return the result to the governed agreement

   Process provider status events, retrieve the signed output and agreed evidence, and obtain the required validation result. Configure how FormKiQ stores and relates those records, limits access, applies retention, and routes exceptions before agreement activation.

Add wallet-enabled qualified signing when required. If the initial signing route does not meet the required signature level, scope a connection to a suitable signing provider. Confirm document submission, the user’s signing interaction, returned artifacts, status events, and validation evidence. The signing provider may supply validation, or a separate service may be needed to meet the required scope and independence.

Choose that provider and verify its actual capabilities before estimating the work. The wallet identity connection can be useful on its own; qualified signing adds a separate integration scope and does not follow automatically from identity verification.

Agree on responsibility at each boundary

Test the handoffs before enabling the route

• Reject disclosure in the wallet. Show that the agreement remains unsigned and the case has a permitted next step.
• Submit an expired credential or replay a presentation from another transaction. Show that verification prevents it from satisfying the current request.
• Verify identity without proof of supplier authority. Show the separate authority review.
• Change the agreement or return an indeterminate validation result. Show that activation waits for the required review and valid signing result.
• Remove access to the signing provider’s portal. Retrieve the signed record and the evidence needed to explain its acceptance.