What is identity verification orchestration?

Identity verification orchestration connects multiple verification methods and providers behind a single API, automatically routing each user to the best method for their country and use case, with instant fallback when a method fails. Instead of integrating vendors one by one, businesses integrate once and gain access to the full landscape of eIDs, wallets, biometrics and document checks.

How many verification methods does Authologic support?

Authologic supports over 90 verification methods from more than 80 providers, covering over 230 countries and territories - including national eIDs, government identity wallets, BankIDs, biometrics and document-based verification.

Is Authologic ready for eIDAS 2.0 and the EUDI Wallet?

Yes. Authologic supports EUDI Wallet integration alongside national eIDs and government wallets such as mObywatel, Diia, SPID and FranceConnect+, helping regulated businesses prepare for mandatory EUDI Wallet acceptance under eIDAS 2.0.

How does Authologic improve onboarding conversion?

By routing users to electronic identity methods instead of document scans wherever available. eID-based verification removes photo capture and manual review, which shortens onboarding and increases pass rates, with automatic fallback to other methods when needed.

How is Authologic different from traditional KYC providers?

Traditional KYC vendors offer their own verification methods; Authologic is a neutral orchestration layer that connects them all. One integration provides access to over 90 methods from more than 80 providers, with routing, fallback and coverage that no single vendor offers.

Jarek Sygitowicz

August 11, 2026

EUDI Wallet & eIDAS 2.0 Glossary: Who Issues, Who Provides, Who Guarantees (pt. 2)

Last updated: August 11, 2026

EUDI basics, made simple. The supply side of the ecosystem in 3 minutes.

This glossary defines the supply side of the EUDI Wallet ecosystem under eIDAS 2.0: who issues credentials (issuers), who holds them (holders), who provides the wallet itself (wallet providers), who guarantees that any of it can be trusted (trust service providers, qualified and non-qualified), and which sectors are legally required to accept the wallet (the Article 5f catalog).

EUDI Wallet & eIDAS 2.0 Glossary: Part 1 covered the demand side: relying parties, intermediaries and verifiers.

EUDI Wallet & eIDAS 2.0 Glossary pt. 2 - cover with a navy map of Europe circled by golden EU stars

What is an issuer in the EUDI Wallet ecosystem?

The organisation that creates a credential and puts it in your wallet. Your government issues your PID; a university could issue your diploma; a bank could issue proof that you hold an account.

In practice: An issuer signs each credential cryptographically, which is what lets a relying party verify later that the data is genuine and untampered - without calling the issuer back.

Different credentials have different issuers: PID comes from or on behalf of the Member State, while attestations of other attributes (qualifications, licences, memberships) can come from public bodies and private organisations.

Who may issue what, and under which guarantees, is defined by the trust framework - see qualified vs non-qualified trust services below.

Who this applies to: Governments and their agents (for PID), and any public or private organisation that wants its documents to live in wallets as verifiable credentials rather than PDFs.

Legal basis: Regulation (EU) No 910/2014 (eIDAS), as amended by Regulation (EU) 2024/1183 - see Articles 5a (PID provision) and 45b-45h (electronic attestations of attributes).

What is a holder in the EUDI Wallet ecosystem?

The person the wallet belongs to. You hold your credentials, you decide who sees them, and nothing leaves your wallet without your approval.

In practice: The holder is the missing link that makes this architecture different from today's identity flows.

Currently, data moves directly between institutions - a bank queries a registry about you. In the wallet model, data moves through you: the issuer gives the credential to the holder, and the holder presents it to the relying party.

That puts consent and selective disclosure - sharing only the attributes a given service needs - in the holder's hands by design, not as a checkbox.

Who this applies to: Every wallet user. Use remains voluntary: the acceptance obligation binds relying parties, never the holder.

Legal basis: The holder role follows from the wallet's design in Regulation (EU) No 910/2014 (eIDAS), Article 5a, as amended by Regulation (EU) 2024/1183; "user" is the regulation's term.

What is a wallet provider?

The organisation that builds and operates the wallet app itself. Usually the government - but not only.

In practice: Every Member State must provide at least one certified wallet by December 24, 2026, and it can do so in three ways: build it itself, mandate another organisation to build it, or recognise a wallet built independently.

That is why "one wallet per country" is the floor, not the ceiling - accredited private providers can enter the market, and users may end up choosing between several wallets the way they choose banks.

Each wallet, whoever provides it, must pass the same certification and work cross-border. For relying parties this multiplies the integration surface: the credential formats are standardised, but the number of wallets to test against keeps growing.

Who this applies to: Member States and organisations seeking accreditation as wallet providers; indirectly, every relying party planning acceptance - see the EUDI Wallet Readiness Checklist.

Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 5a(2) (the three provision models), as amended by Regulation (EU) 2024/1183.

What is a trust service provider (TSP)?

A company or institution that provides the services trust is built on: issuing attestations of attributes, timestamps and certificates, and creating and validating electronic seals and signatures.

In practice: Trust services are the plumbing under the ecosystem. When a credential is signed, a signature is validated, or a document is sealed and timestamped, a trust service performs it.

eIDAS defines the catalog of these services and splits providers into two tiers with very different legal weight: non-qualified TSPs can serve advanced (non-qualified) signature flows, while the qualified tier - qualified signatures, seals and attestations - is reserved for QTSPs (see the next entry).

The register of who provides what is public: each Member State maintains a trusted list, and the EU aggregates them.

Who this applies to: Providers of signatures, seals, certificates and attestations; and anyone deciding which tier of trust service a use case requires.

Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 3(16) (trust service) and Article 3(19) (trust service provider), with the two tiers in Chapter III, as amended by Regulation (EU) 2024/1183.

What is the difference between qualified and non-qualified trust services?

Both tiers can provide largely the same services - the difference is the regime behind them. Qualified providers (QTSPs) operate under stricter security requirements, supervision and liability rules, and in exchange their services carry legal presumptions: a qualified electronic signature equals a handwritten one across the whole EU.

In practice: The catalog of services is largely shared between the two tiers - the same service simply exists in two versions.

Attestations of attributes, timestamps and certificates can each be issued by a non-qualified TSP, or in their qualified versions (like QEAA) by a QTSP only.

What changes with qualified status is the regime: conformity assessment, national supervision, stricter security requirements - and legal presumptions in return, with liability presumed on the provider's side if a qualified service causes damage.

Both tiers appear on the EU trusted list, and listing always means operating under accepted policies and procedures; what differs is the status recorded against each entry.

The practical question for any flow: does the use case legally require the qualified tier? Under AMLR, for example, qualified trust services (QES, QEAA) are recognised verification pathways alongside notified eID schemes at substantial or high assurance and the EUDI Wallet itself.

Who this applies to: Compliance teams mapping which tier their processes need; providers deciding whether to seek qualified status.

Legal basis: Regulation (EU) No 910/2014 (eIDAS), Articles 3(17), 3(20) and Chapter III Section 3, as amended by Regulation (EU) 2024/1183; recognition under AMLR: Regulation (EU) 2024/1624, Article 22(6).

What is the Article 5f sectoral catalog?

The list of sectors whose private-sector players must accept the EUDI Wallet: transport, energy, banking and financial services, social security, health, drinking water, postal services, digital infrastructure, telecommunications and education - plus very large online platforms designated under the DSA. If you are on the list and the law requires strong user authentication for your service, wallet acceptance is not optional after December 24, 2027.

In practice: The obligation has two triggers that both must fire: your organisation operates in a listed sector, and the law - EU or national - requires strong user authentication for the service in question. "Strong user authentication" here is the eIDAS 2.0 concept; the most common source of such a requirement in practice is Strong Customer Authentication (SCA) under PSD2 and the incoming PSR, which is why banks and payment providers are the clearest example: if your organisation holds a banking, payment or e-money licence, the acceptance obligation applies to your SCA flows. In-person point-of-sale and ATM transactions are generally read as out of scope; remote flows - account access, payment initiation, onboarding with mandated authentication - are in.

Who this applies to: Private relying parties in the listed sectors. To map your own position, start with Section 1 of the SCA & AMLR Readiness Checklist.

Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 5f, as amended by Regulation (EU) 2024/1183.

How do issuers, wallet providers and trust services fit together with relying parties?

An issuer creates a credential and signs it; the holder keeps it in a wallet built by a wallet provider; trust service providers - qualified or not - supply the signatures, certificates and attestations that make any of it verifiable. On the other side of the exchange sit the roles from EUDI Wallet & eIDAS 2.0 Glossary: Part 1: the relying party that requests the data, the verifier infrastructure that checks it, and the intermediary that operates that infrastructure for many relying parties at once. The Article 5f catalog determines who on the demand side has no choice but to take part.

Part 3 will open the wallet itself: PID in depth, attestation types (EAA, QEAA, PuB-EAA) and selective disclosure.

For the infrastructure vocabulary - orchestration, routing, fallback - see the Identity Orchestration Glossary.

Changelog