EUDI Wallet Portal

EUDI Wallet explained, from regulation to rollout

A reference on the European Digital Identity Wallet: what it is, how it works, what's in it for the users and the service providers, regulatory and technical background, existing applications across the EU. Written for anyone who needs to understand the ecosystem, not just implement it.

Operated by TrustID Solutions.

I want to connectStart with the basics

What is the EUDI Wallet

Every EU citizen shall be able to use their personal documents via digital channels, so that they do not have to carry their physical wallets all the time. The EUDI Wallet can hold verified, digital credentials of a person and present them to third parties upon the user's approval. Personal identification data and other official documents (such as tax ID, social security number or age) are issued by their Member State's relevant authority, and further attestations about facts like qualifications and entitlements may be issued by any registered provider.

Every Member State has to provide at least one wallet solution, it is free and voluntary for citizens, and any of them has to work in every other Member State. What makes it different from a folder of documents is that the data comes from a trusted source and stays verifiable. Furthermore, any third party requesting data from the user is also verified. The trust is ensured by a combination of Public Key Infrastructure, trust lists and certificate revocation mechanisms.

  1. Issued once

    A state authority, a public body or a qualified trust service checks a fact against its own records and issues it into the wallet, where it stays until it expires or is revoked.

  2. Held by the person

    The credential is stored on the device, not in a central database. The wallet and credential providers are not supposed to be able to see where or how it is used.

  3. Presented on request

    A service asks for specific attributes. The person sees who is asking and for what purpose. Upon approval the selected attributes are sent, signed and verifiable.

  • Free and voluntaryfor citizens, with alternatives kept open
  • At least one per Member Statestate-provided or state-recognised
  • Valid across the EUa wallet from one country works in all of them
  • Assurance level highhardware-bound keys, certified components

What the wallet is used for

The EUDI Wallet is not a single service. It is a container for verified data that the user controls, and the same presentation flow serves very different situations, from opening a bank account to proving an age limit at a checkout. The six areas below are where it will appear first, with what each one means for the user holding the wallet and for the service provider requesting the data.

Identification and onboarding

The wallet carries Person Identification Data (PID) issued by the relevant authority of a Member State, at assurance level high. A service can request it to establish who the user is, and the user approves exactly which attributes leave the wallet. For the service provider it replaces the document photo, the selfie and the video call in most remote identification flows.

Examples

  • Opening a bank account
  • SIM card registration
  • e-government services
  • Insurance onboarding
  • Car rental pick-up
  • Age-restricted account creation
More detail: Identification and onboarding

How it works

The relying party sends a presentation request, either on the same device through the browser's credential API or across devices with a QR code. The wallet shows who is asking, what they registered themselves to ask for, and which attributes the request covers. After the person approves, the wallet returns signed attributes bound to a key held in the device's secure hardware, so the response cannot be replayed by anyone else.

For the person

No uploading of document scans, no waiting for a manual review. Selective disclosure means an age check does not have to reveal an address, and a delivery service does not have to learn a date of birth. Every request names the requester, and it can be refused.

For the organisation

Identification becomes a request rather than a process to build and maintain. The attributes arrive already verified, which shortens onboarding and removes a large part of document fraud risk. In return, the relying party has to register in its Member State, declare the attributes it intends to request and the purpose, and ask for nothing beyond that registration.

Standards and rules: PID rule book, OpenID4VP for presentation, SD-JWT VC and ISO mdoc credential formats, relying party registration under the implementing acts.

Login and strong authentication

The same mechanism that proves identity can also prove that a returning user is the same person as before, without sharing identity data. The keys are held in the device and unlocked by biometrics or a PIN, which covers both authentication factors in a single step.

Examples

  • Bank login and payment confirmation
  • Health and tax portals
  • Corporate single sign-on
  • Large online platforms
  • Account recovery
More detail: Login and strong authentication

How it works

For services that only need to recognise a returning user, the wallet can present a pseudonym: a stable identifier that is different for every relying party, so two services cannot correlate their users. Where the law requires identification, the same flow carries real attributes instead. Both are ordinary presentation requests, so a service integrates one interface and decides per transaction how much information it needs.

For the person

One flow instead of a password, an SMS code and a separate authenticator app, and the same flow across banks, public services and platforms. Because the private key never leaves the device, a phished credential is not enough to sign in elsewhere.

For the organisation

Authentication at a level suitable for strong customer authentication, without operating a token estate or an SMS gateway. The wallet authenticates the user and does not move money, so it sits next to a payment flow rather than replacing it. Very large online platforms are required to accept the wallet where they ask users to identify themselves.

Standards and rules: OpenID4VP, wallet pseudonyms, device-bound keys with wallet and key attestation, PSD2 strong customer authentication where payments are involved.

Qualified electronic signatures

Every EUDI Wallet must let a natural person create qualified electronic signatures, free of charge for non-professional use. A qualified signature has the same legal effect as a handwritten one and must be recognised in every Member State.

Examples

  • Employment contracts
  • Loan and lease agreements
  • Insurance claims
  • Public administration forms
  • Cross-border company filings
More detail: Qualified electronic signatures

How it works

The signature itself is created by a qualified trust service provider using a qualified signature creation device. The wallet's job is to authenticate the signer and to authorise that specific signature, so the person sees what they are signing and confirms it in the wallet rather than in a separate signing portal with its own account and password.

For the person

Signing without registering with a trust service provider first, and without paying for private use. The free tier covers non-professional use; signing in a professional capacity can involve a separate certificate and a fee.

For the organisation

A contract signed this way is enforceable across the EU without collecting scans or couriering paper. Documents that used to require a branch visit can be closed remotely, and the signature is verifiable long after the fact through the qualified trust lists.

Standards and rules: eIDAS qualified signature provisions, remote QSCD, EU trusted lists of qualified trust service providers, ETSI signature formats such as PAdES and XAdES.

Age verification

The wallet can prove that a user is above an age threshold without revealing their date of birth, their name or any other attribute. This is the use case moving fastest: the European Commission has published an age verification blueprint that Member States are piloting ahead of the full wallet rollout, and platform obligations to protect minors are already in force.

Examples

  • Adult content platforms
  • Online alcohol and tobacco sales
  • Gambling
  • Social media minimum age
  • Video sharing platforms
  • In-store purchases
More detail: Age verification

How it works

A proof-of-age attestation is issued to the wallet after the person has been identified once, by a national eID scheme or by reading the chip in a passport or identity card. What the service receives afterwards is a statement that the holder is over the threshold, signed by a recognised issuer. To stop services from linking sessions together, batches of single-use attestations can be issued, and zero-knowledge proofs can be added so the same attestation can be reused without becoming a tracking identifier.

For the person

No identity document handed to an adult site, no face scan, no account with an age verification vendor. The check works the same way whether the age gate is on a website, in an app or at a self-checkout, and the service learns only one bit of information.

For the organisation

A way to meet minor protection duties without becoming the custodian of identity data, which is where most of the legal risk in age assurance sits today. Issuers appear on a trusted list maintained by the Commission, so an attestation issued in one Member State can be checked in another without bilateral agreements.

Standards and rules: proof-of-age electronic attestation of attributes, EU age verification blueprint and its open-source reference implementation, OpenID4VCI for issuance, OpenID4VP and the W3C Digital Credentials API for presentation, Digital Services Act obligations on protection of minors.

Professional and institutional attestations

Beyond identity data, wallets carry attestations about what a user holds, is entitled to or may do. These are issued as qualified attestations by trust service providers, or directly by the public body that holds the authentic source of the data.

Examples

  • University diplomas
  • Professional licences
  • Powers of representation
  • Employee credentials
  • European Health Insurance Card
  • Disability card
  • Tax residency
More detail: Professional and institutional attestations

How it works

An issuer verifies the fact once against its own records and issues it to the wallet, where it stays until it expires or is revoked. A verifier checks the signature and the issuer's place on a trusted list, so it never has to call the university, the chamber or the registry directly. Several attestations can be combined in one request, for example an identity attribute plus a mandate to act for a company.

For the person

Credentials that currently live in PDFs and paper certificates become presentable in seconds, including across borders, where recognition normally means translations and apostilles. Each presentation only carries the attributes the situation calls for.

For the organisation

Checks that today rely on emailed scans and phone calls become automatic, which matters most in regulated hiring, procurement and cross-border service provision. Organisations that already hold authentic data can also become issuers themselves, which is a different role with its own obligations.

Standards and rules: qualified electronic attestations of attributes (QEAA) and attestations issued by or on behalf of public sector bodies (PuB-EAA), catalogue of attributes and attestation rule books, revocation and trusted lists.

Mobile driving licence and travel documents

Driving licences and travel credentials are the first documents most people will carry digitally. They are also the case where the wallet has to work offline, in person, and with verifiers outside the EU.

Examples

  • Roadside checks
  • Car and van rental
  • Hotel check-in
  • Airport and border pilots
  • Vehicle sharing
More detail: Mobile driving licence and travel documents

How it works

The mobile driving licence follows its own ISO standard, which predates the wallet and is already deployed outside Europe. Presentation happens device to device over NFC or Bluetooth when there is no connectivity, or online through the same request flow used everywhere else. Travel credentials derived from passports are being tested in the large scale pilots rather than in production.

For the person

A licence check at the roadside that does not involve handing a card to anyone, and a rental desk that reads entitlement categories directly. The physical document stays valid, and the digital one is not a replacement for it in every country.

For the organisation

Rental, mobility and hospitality operators can verify licence categories and expiry without transcribing them from a photo. The same reader logic works for wallets from other Member States, and for mDLs issued outside the EU where the trust anchors are accepted.

Standards and rules: ISO/IEC 18013-5 for in-person mDL, ISO/IEC 18013-7 for online presentation, ICAO Doc 9303 for travel documents, EU driving licence rules on recognition of digital licences.

Technical background

The architecture from a decision-making perspective: who issues what, how a request travels between a service and a wallet, how trust is established, and what has to be in place before a service goes live. Each area opens into the Knowledge Base, where the same topics are set out in full with links to the specifications.

Architecture and roles

Four parties and one rulebook: someone issues data, someone holds it, someone verifies it, and someone vouches for all of them. Most integration questions turn out to be questions about which role you are in.

  • Wallet providers and wallet units
  • PID providers and attestation providers
  • Relying parties and intermediaries
  • Where the ARF fits between law and code
Open in the Knowledge Base

Credential formats

Two formats carry almost everything in this ecosystem, and they come from different traditions. Knowing which one a credential uses tells you how selective disclosure works and what a verifier has to be able to parse.

  • SD-JWT VC and how salted disclosures work
  • ISO mdoc, built for in-person use
  • What selective disclosure does and does not hide
  • Status and revocation of a credential
Open in the Knowledge Base

Issuance and presentation protocols

How a credential gets into a wallet, and how it comes back out on request. The same two protocols cover both, whether the wallet is on the same device as the service or on a phone next to a laptop.

  • OpenID4VCI for issuance
  • OpenID4VP for presentation
  • Same-device and cross-device flows
  • The W3C Digital Credentials API in the browser
Open in the Knowledge Base

Trust, registration and trusted lists

The part that has no technical equivalent in today's login flows. A verifier has to be registered before it can ask for anything, and both sides check the other against lists published by Member States.

  • Relying party registration and what it declares
  • Trusted lists and trust anchors
  • How a wallet decides a request is legitimate
  • Cross-border recognition between Member States
Open in the Knowledge Base

Security and key management

Assurance level high is a hardware statement, not a policy statement. Keys are bound to the device, and the wallet proves that fact cryptographically every time it responds to a request.

  • Device-bound keys and secure hardware
  • Wallet attestation and key attestation
  • Certification and assurance levels
  • Privacy risks that remain, including linkability
Open in the Knowledge Base

Test environments

You can test against real wallets today. The reference implementation gives a baseline, the national sandboxes add local trust anchors, and the aggregator playgrounds let you check several wallets against one integration.

  • The Commission's reference implementation
  • National sandboxes and their differences
  • Multi-wallet playgrounds
  • What to test first, and in what order
Open in the Knowledge Base

What integrating as a relying party involves

The sequence below is the one that repeats across projects, and the order matters, because registration constrains the design rather than the other way around.

  1. Decide what you actually need

    Per flow, not per system: which attributes, from which credential, for what purpose, and whether you need to retain anything afterwards. Anything you cannot justify here will not survive registration, and asking for more than you need is visible to every user in the wallet's consent screen.

  2. Register as a relying party

    Registration happens with the body designated by your Member State, and it declares your identity, your intended attributes and your purposes. Wallets check this before showing a request, so an unregistered verifier simply does not work.

  3. Choose an integration path

    Either you run your own verifier and manage trust anchors, formats and updates yourself, or you use an intermediary that does. The trade-off is control and data exposure against the effort of tracking a specification set that is still moving.

  4. Build the request and response flow

    A request has to work on a phone, on a desktop with the wallet on a second device, and without connectivity where the use case demands it. This is where format choices become concrete, because a verifier that only handles one credential format will meet wallets it cannot talk to.

  5. Validate the response in full

    Signature and certificate chain, issuer against the trusted list, revocation status, freshness and replay protection, and the device binding of the presented credential. A demonstration that skips these looks identical to one that does not, which is why early integrations often fail their first audit.

  6. Prepare for operations

    Logging and retention that match what you declared, a path for users whose presentation fails, staff who can tell the difference between an expired credential and an untrusted issuer, and someone watching the specification and implementing act changes that will require code updates.

TrustID Solutions works on relying party integrations in this ecosystem, from scoping the attributes through to verification and testing against live wallets.

I want to connect

Wallets that exist today

There is no single EUDI Wallet. Every Member State provides its own, and they arrive by three routes: purpose-built state wallets, existing national identity applications upgraded to meet the regulation, and private wallets recognised by a Member State. The implementations below are the ones most relevant to integration work, with their current status.

EUDI Wallet Reference Implementation

European Commission

Open source, testable now
Built by
The Commission, tracking the ARF
Carries
PID, mDL and sample attestations
Test environment
Public repositories with wallet, issuer and verifier components

Not a certified wallet and not tied to any Member State's trust infrastructure. Its value is as a conformance baseline: if a flow does not work here, it will not work anywhere.

State EUDI Wallet

Germany

Sandbox available
Built by
SPRIND with Bundesdruckerei, for the federal digital ministry
Carries
PID at assurance level high, with attestation support added through 2026
Test environment
Public sandbox open since January 2026

One of the two most visible programmes for relying parties, with an unusually open developer process. Public availability of the wallet app is indicated for early 2027, so the sandbox is currently the only way to test against it.

France Identité

France

Sandbox available
Built by
France Identité and France Titres
Carries
Identity data derived from the national identity card, plus proof of age
Test environment
Public playground for relying parties

Builds on an app that already exists in citizens' hands, which makes it a useful reference for how the transition looks when a national scheme predates the wallet. Also one of the first Member States to take up the age verification blueprint.

Sistema IT-Wallet

Italy

Sandbox available
Built by
Department for Digital Transformation with PagoPA
Carries
Identity plus documents such as the driving licence and health card
Test environment
Public sandbox

The clearest example of a wallet built on top of existing mass-adopted infrastructure, reusing the national identity schemes and the public services app most citizens already have.

AltID

Denmark

Sandbox available
Built by
Agency for Digital Government
Carries
PID, with proof of age among the first attestations
Test environment
Public sandbox opened during 2026

Denmark comes to this from one of Europe's most widely used national eID schemes, so the interesting question here is how a wallet coexists with an incumbent that almost everyone already uses.

National wallet programme

Spain

In development
Built by
The ministry responsible for digital transformation
Carries
Identity data, with proof of age piloted first
Test environment
Limited to pilots at the time of writing

Among the first group of Member States taking up the age verification blueprint, which in several countries is turning out to be the first wallet function citizens actually use.

DÁP

Hungary

Existing app, upgrade in progress
Built by
The Digital Citizenship Programme
Carries
Identity data and documents, with an electronic identification service for relying parties
Test environment
Onboarding runs through the programme's own service provider process

A national app already in wide use, built on wallet-compatible components and being developed towards the EU requirements. It has not completed certification and notification as an EUDI Wallet, so today it is a national scheme rather than part of the cross-border wallet ecosystem.

Private and open-source implementations

Several vendors and consortia

Varies

The regulation allows a Member State to recognise a private wallet, and Germany's prototype competition deliberately seeded a field of them. For a relying party these matter for a practical reason: your integration will meet wallets you have never heard of, so format and profile coverage is worth more than support for any single wallet.

  • Lissi — German provider of an edge wallet and a widely used relying party connector, and since 2026 part of a managed hub aimed at banks
  • Sphereon, Animo, Governikus, Authada, Ubique, TICE — funded participants in the German prototype competition, with open-source outputs
  • wwWallet — an open implementation from a group including national research networks and a hardware security vendor
  • Wallet-as-a-service providers — several vendors offer white-label wallets and issuer or verifier infrastructure for closed ecosystems

Where to look

This list is a snapshot and will go out of date. Last reviewed September 2026.

Where the rules come from

Three documents govern this ecosystem, and they are not interchangeable. One is law, one is binding technical detail, and one is a design blueprint that changes several times a year.

eIDAS 2

Regulation (EU) 2024/1183, in force since 20 May 2024

Amends the original eIDAS Regulation to create the wallet, oblige Member States to provide one, and oblige defined relying parties to accept it. The text to read is the consolidated version of Regulation (EU) No 910/2014, not the amending regulation alone.

Implementing acts

Around forty acts, the core set adopted in 2024 and 2025

Binding detail on formats, protocols, certification and the registration of relying parties. Several were amended in July 2026 to catch up with the standards the ecosystem had moved to, which is a pattern worth expecting again.

Architecture and Reference Framework

Version 3.0.0, published 21 July 2026

The technical blueprint, developed with the Member States and published openly. Not legally binding, but it is what the implementing acts and the reference implementation are aligned to, so it is the document engineers actually work from.

Official sources

Everything here points back to the primary sources. This portal explains and organises; it does not replace the official record. The European Commission publishes the regulation, the implementing acts, the technical framework and the reference implementation openly, and those are the documents to cite when a decision has to hold up.

Visit the official EU Digital Identity Wallet site (opens in a new tab)

Large Scale Pilots

Six EU co-funded consortia have tested the wallet in real services, across more than a dozen use cases and most Member States. Four have concluded and published their findings, and two are running now, focused on the move from testing to deployment. Their results are one of the main inputs into changes in the ARF and the implementing acts.

Running now

APTITUDE consortium logoActive since 2025

APTITUDE

Travel credentials, mobile vehicle registration certificates, and proving that the ecosystem scales

More detail

Where the earlier pilots asked whether the technology works, APTITUDE asks whether it holds up in volume and across borders at the same time. Its use cases run from travel documents to vehicle registration certificates carried in a wallet, and its stated aim is to demonstrate interoperability, usability and scalability rather than to prove a single flow.

Why it matters for a relying party: this is the pilot most likely to surface the operational problems that only appear at scale, which is the gap between a working integration and a service you can run.

Active since 2025

WE BUILD

Business wallets and payments across B2B, B2G and B2C processes

More detail

The organisational side of the ecosystem, which the first round of pilots largely left alone. A wallet held by a company rather than a person raises questions the person-centred model does not answer: who may act for the company, how a mandate is attested, and how that interacts with payment flows.

Why it matters for a relying party: if your customers are businesses rather than consumers, this is the pilot whose output will shape your integration, including powers of representation and invoicing or payment scenarios.

Concluded

POTENTIAL consortium logo2023 to 2025

POTENTIAL

Six use cases across government, banking, telecom, driving licences, signatures and health

More detail

The broadest of the four, running from April 2023 to September 2025 across online government services, bank account opening, SIM and eSIM registration, the mobile driving licence, qualified electronic signatures and ePrescription.

What it concluded: cross-border interoperability is achievable but only if common standards are applied strictly, which is why its headline recommendation was EU-wide conformance testing. It also found that the countries moving fastest were those with strong national coordination and early private sector involvement, and that security is as much a matter of governance, certification and liability as of technology.

2023 to 2025

EU Digital Identity Wallet Consortium

Digital travel credentials and end-to-end travel and payment flows

More detail

Built on the Commission's reference wallet and focused on travel: digital travel credentials derived from passports, and the airline, border and hotel touchpoints around them. A second strand covered payments authorised through the wallet.

What it concluded: wallet-based payment authorisation is already workable in production settings, and linking identity to payment shows real potential against fraud. The open questions it left are about liability rather than technology.

Note: the consortium's original domain is no longer under its control, so the Commission's pilot page and the consortium's GitHub organisation are now the reliable places to find its specifications and results.

2023 to 2025

NOBID

Payment authorisation with the wallet, domestically and across borders

More detail

A Nordic-Baltic grouping joined by Italy and Germany, working on the payments use case in retail contexts. It is the pilot with the most experience of what happens when a wallet arrives in markets where bank-issued electronic identity is already near-universal.

Why it still matters: the incumbency problem it studied is the same one most Member States now face, since a wallet has to earn its place next to an eID that people already trust and use daily.

2023 to 2025

DC4EU

Education, professional qualifications and social security credentials

More detail

Diplomas, professional qualifications and social security entitlements, including the European Health Insurance Card, with an emphasis on whether a credential issued in one country is actually recognised in another.

Why it still matters: this is the pilot closest to the attestation types most organisations will end up consuming, and its work fed the rulebooks that make those attestations portable.

Where to look

  • Commission page on the Large Scale Pilots — which pilots are active and which use cases they cover
  • The findings published by the concluded consortia, on their own sites where these are still maintained, and otherwise on the Commission's pilot pages

Events

The conferences and workshops where the state of the ecosystem is discussed, and recordings from the events that have already taken place. The list covers the events that draw the wallet community as a whole.

Upcoming

  • European Identity and Cloud Conference 2027 (opens in a new tab)

    11 to 14 May 2027bcc Berlin Congress Center, BerlinOn site and online

    The largest European identity conference, and in practice the place where wallet providers, relying parties and vendors compare notes on what actually shipped. The 2026 edition ran heavily on wallet rollout and relying party onboarding.

    Organised by KuppingerCole Analysts

Past events and recordings

Event list last updated 1 September 2026.

Frequently asked questions

Short answers to the questions that come up most often, from users encountering the wallet for the first time and from organisations working out what it means for them.

The basics

What is the EUDI Wallet?

An app provided or recognised by a Member State that holds verified data about you: your identity as issued by the state, and attestations about things like qualifications, entitlements or age. When a service needs one of those facts, it asks the wallet, you see who is asking and what for, and you decide whether to answer.

Do I have to use one?

No. For citizens it is voluntary and free of charge, and services that accept the wallet must keep an alternative route open. What is mandatory is the other way round: Member States must provide a wallet, and defined categories of organisations must accept it.

When will it actually be available?

Member States have to provide at least one certified wallet by 24 December 2026. Several national wallets and sandboxes are already testable, and in a few countries proof of age is arriving ahead of the full wallet.

Is it one app for the whole of Europe?

No. Each Member State provides its own, and private wallets can be recognised too. The requirement is that any of them works everywhere in the EU, which is why the formats, protocols and trust rules are set centrally.

Can the state or the wallet provider see what I do with it?

They are not supposed to. The provider must not have visibility into your transactions, and services only receive the attributes you approve. The risk that remains is linkability, meaning two services recognising that requests came from the same credential, which is why single-use attestations and privacy-preserving proofs are part of the design.

For organisations

Does my organisation have to accept the wallet?

Public sector bodies must accept it from the point wallets are available. Very large online platforms and private parties that are required by law or contract to use strong user authentication, such as banks and telecom operators, follow roughly a year later. Everyone else may accept it voluntarily, and many will, because it is cheaper than the identification process they run today.

Do we have to register before we can use it?

Yes. A relying party registers with the body designated by its Member State and declares its identity, the attributes it intends to request and the purposes. Wallets check that registration, so an unregistered service simply does not work, and a request that exceeds what was declared is visible to the user.

Can we keep the data we receive?

Only what your registration and your legal basis actually cover, and a request has to indicate whether you intend to retain anything. Verifying a fact and storing it are separate decisions; most flows need the check rather than the value.

Does this replace the identification we already run?

For many flows, yes, and that is where the saving is. It does not remove sector-specific obligations, and it will coexist with existing national eID schemes for years, so plan for the wallet as an additional route rather than a switch-over.

Technical

What does an integration involve technically?

Requesting a presentation over OpenID4VP, handling both the SD-JWT VC and ISO mdoc credential formats, and validating what comes back: signature, issuer against the trusted list, revocation status, freshness and device binding. The interoperability profile the EU points at pins down which options are mandatory.

Can we test before wallets are widely available?

Yes. The Commission's reference implementation is open source and is the right baseline, national sandboxes add local trust anchors, and aggregator playgrounds let one integration be exercised against several wallets.

Do we have to build the verifier ourselves?

No. You can run your own verifier and manage trust anchors and specification changes, or use an intermediary that does it for you. Either way the relying party remains accountable for the purpose declared and the data received.

Still have questions?

If your question is about a specific integration, a registration process or which credentials you can rely on in a given Member State, TrustID Solutions works on relying party integrations in this ecosystem and can answer it in concrete terms.

I want to connect