Yes, organisations can integrate EUDI Wallet identification and electronic signing into a single workflow. The wallet provides verified identity data at assurance level high, and that same verified identity can feed directly into a qualified electronic signature process handled by a qualified trust service provider. The sections below unpack the technical components, regulatory requirements, compatible formats, and practical considerations for building this combined flow.
What does a combined identification and signing workflow actually look like?
A combined identification and signing workflow uses the EUDI Wallet to verify who the user is and then passes that verified identity directly to a signing step, all within one continuous user journey. The user opens the wallet, approves a presentation of their personal identification data, and is then prompted to sign a document, without re-entering credentials or switching between separate systems.
In practice, the flow works in three stages. First, the relying party sends a presentation request to the wallet. The user reviews which attributes are being requested and approves the disclosure. Second, the relying party receives the verified identity data and confirms the user’s identity at assurance level high. Third, the signing component, operated by a qualified trust service provider, uses that confirmed identity to generate a qualified electronic signature on the document.
The key advantage of combining these steps is that the identity check does not need to be repeated. Once the wallet has presented the user’s personal identification data and the relying party has verified it, that data can be reused within the same session for the signing step. The user experiences one coherent flow rather than two separate processes.
What are the technical components needed to connect EUDI Wallet to a signing workflow?
Connecting an EUDI Wallet to a signing workflow requires four core technical components: a presentation layer that requests and receives wallet attributes using OID4VP, a verification layer that checks the validity of what the wallet presents, a signing component operated by a qualified trust service provider, and a session layer that carries verified identity data between the identification and signing steps.
On the wallet side, the presentation protocol is OID4VP. For proximity use cases, the credential format is mdoc as defined in ISO/IEC 18013-5; for online remote flows, ISO/IEC TS 18013-7 applies. SD-JWT VC is the second supported credential format. The relying party’s system must be able to handle both formats, since different wallet solutions across Member States may use either.
Verification involves three checks, not one:
- The issuer’s signature on the credential is validated against the national trusted list of the issuing Member State, as maintained under ETSI TS 119 612 and aggregated in the EU List of Trusted Lists.
- The revocation status of the credential is checked against status information published by the issuer. Skipping this step means the relying party may accept credentials that have been revoked.
- The wallet unit attestation is verified to confirm that the presenting wallet instance runs on a certified wallet solution.
Only the first check works fully offline. The other two require a live connection at the time of verification.
For the signing step, the relying party connects to a qualified trust service provider that operates a qualified signature creation device. The QTSP uses the verified identity to issue a qualified certificate and generate the signature. The relying party does not generate the signature itself.
How does EUDI Wallet identification satisfy the requirements for qualified electronic signatures?
EUDI Wallet identification satisfies the identity requirements for a qualified electronic signature because the wallet delivers personal identification data at assurance level high, which is the level required for the identity binding in a qualified certificate. The qualified trust service provider uses this verified identity to issue a qualified certificate, which is one of the three components a qualified electronic signature requires.
A qualified electronic signature under eIDAS 2.0 requires three elements: the four advanced electronic signature conditions (unique link to the signatory, capability to identify the signatory, data used under the signatory’s sole control, and a link to the signed data such that any subsequent change is detectable), a qualified certificate for electronic signatures, and a qualified signature creation device. The EUDI Wallet addresses the identity part of the qualified certificate requirement by providing verified, high-assurance identity attributes.
Under article 25(2) of Regulation (EU) 2024/1183, a qualified electronic signature has the same legal effect as a handwritten signature. This makes the combined wallet identification and signing workflow legally equivalent to a traditional wet-ink process for most document types. The important boundary to note is that eIDAS governs the legal effect of the signature itself, not whether a particular transaction is legally valid. Notarial deeds and transfers of registered property remain subject to national form requirements that a qualified electronic signature alone does not satisfy.
What signing formats are compatible with EUDI Wallet-based workflows?
Signing formats compatible with EUDI Wallet-based workflows are the AdES family of formats: PAdES for PDF documents, XAdES for XML, CAdES for general data, and JAdES for JSON. These formats are defined under the eIDAS framework and are the standard output of qualified trust service providers operating in the EU.
The choice of format depends on the document type and the downstream requirements of the receiving system. PAdES is the most widely used format for contracts, agreements, and forms because PDF is the standard document format in most business and government contexts. XAdES is common in structured data exchange, particularly in public procurement and tax reporting. CAdES applies where the signed object is a binary file rather than a structured document.
What the EUDI Wallet itself does not determine is the signing format. The wallet provides the identity presentation; the qualified trust service provider generates the signature in the appropriate AdES format. The relying party’s workflow must specify which format is required and ensure the QTSP it connects to supports that format.
For long-term validity, AdES formats support extended profiles that embed validation data, including the certificate chain, revocation information, and timestamps, directly into the signed document. This is relevant for organisations in sectors such as healthcare and financial services where signed documents must remain verifiable over years or decades.
Which sectors benefit most from integrating identification and signing into one flow?
The sectors that benefit most from a combined EUDI Wallet identification and signing workflow are those where identity verification and a legally binding signature are both required in the same transaction. Financial services, healthcare, pharmaceuticals, and government services are the clearest examples, because each sector regularly requires both a confirmed identity and a signed document before a process can proceed.
In financial services, account opening, loan agreements, and investment mandates all require identity verification and a signed contract. Combining these into one wallet-based flow reduces friction and removes the need for separate identity verification steps. The new Anti-Money Laundering Regulation, which applies from July 2027, adds further pressure to get identity verification right at the point of onboarding. Whether a financial institution may rely on a wallet-based identity check to satisfy its AML obligations depends on the AMLR and applicable sector rules, not on eIDAS alone.
In healthcare and pharmaceuticals, patient consent forms, prescription authorisations, and clinical trial agreements require both identity confirmation and a signature. A wallet-based flow allows these to be completed remotely without compromising the assurance level of the identity check.
Government services benefit because public sector organisations are required to accept certified EUDI Wallets from 24 December 2026. Many government processes, such as permit applications, benefit claims, and official declarations, require both identification and a signed statement. Combining these steps into one digital flow reduces processing time and eliminates the need for in-person visits.
What should organisations consider before implementing this integration?
Before implementing a combined EUDI Wallet identification and signing workflow, organisations should address four areas: registration obligations, attribute scope definition, QTSP selection, and the boundary between what eIDAS covers and what national or sector law adds on top.
On registration, relying parties must register with a national authority under CIR (EU) 2025/848 before they can request wallet data. Registration requires specifying exactly which attributes and attestations will be requested for each intended use. The wallet checks every request against the registered scope and stops the presentation if the request exceeds it. Requesting more than registered is an explicit ground for revocation of the registration. This makes scope definition one of the most consequential decisions in the implementation process.
On QTSP selection, the relying party does not generate the qualified electronic signature. It connects to a qualified trust service provider that operates a qualified signature creation device. The relying party must select a QTSP whose services are listed on the relevant national trusted list, confirm that the QTSP supports the required signing format, and integrate the QTSP’s signing API into the workflow so that verified identity data from the wallet flows through correctly.
On the limits of eIDAS, organisations should be clear about what the regulation does and does not cover:
- eIDAS governs the legal effect of the signature, not whether the underlying transaction is valid under national law.
- Whether a wallet-based identity check satisfies AML or KYC obligations depends on the AMLR and sector-specific rules, not on eIDAS.
- Notarial acts and transfers of registered property remain subject to national form requirements.
Finally, organisations should consider the private sector acceptance deadline. For regulated private relying parties in sectors such as banking, healthcare, telecom, and energy, the obligation to accept certified EUDI Wallets applies from 24 December 2027 under article 5f of Regulation (EU) 2024/1183. Micro and small enterprises with fewer than 50 employees and an annual turnover or balance sheet total of no more than ten million euros are exempt. For organisations within scope, 24 December 2027 is the planning date, not 2026.
How TrustTech supports EUDI Wallet identification and signing workflows
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.
For combined identification and signing workflows specifically, the ID Connector handles the following:
- Requesting and receiving wallet presentations using OID4VP, for both mdoc and SD-JWT VC credentials.
- Running all three verification checks: issuer signature against the national trusted list, revocation status, and wallet unit attestation.
- Passing verified identity data to a connected qualified trust service provider for the signing step, so the identity check does not need to be repeated.
- Keeping the relying party within its registered attribute scope on every request.
- Making verified identity data reusable across interactions within the same session.
Organisations in financial services, healthcare, pharmaceuticals, and government use this setup to run identification and signing as one continuous flow rather than two separate processes. Contact TrustTech to discuss how the ID Connector fits into your workflow.