Over the past months we have published insights on the key roles and mechanisms that make the EUDI ecosystem work: relying party registration, wallet attestations, and relying party certificates. Each covers a specific layer: who is allowed in, how a wallet proves itself, how trust is cryptographically asserted.
But all of these layers rest on a common foundation: trust lists. Every entity in the ecosystem, be it wallet providers, PID issuers, certificate authorities, relying parties, must be formally enumerated and published for others to verify.
Trust lists are how that happens.
What a trust list is
A trust list is a signed, machine-readable document that enumerates the entities a given authority officially recognizes as trusted participants in the ecosystem. Each entry carries the entity’s name and its designated role, the trust anchor needed to verify its outputs, and a validity period.
The role element matters: a trust list does not just confirm that an entity exists; it confirms what that entity is designated to do. A certificate authority designated to issue Wallet-Relying Party certificates appears under a different service type than a wallet provider or a PID issuer. A wallet verifying a credential does not just ask ‘is this entity known?’, but it asks ‘is this entity designated to perform this specific function?’
The authority publishing the list — the Trusted List Provider — signs each version so any party that downloads it can verify it has not been tampered with. The list is public, versioned, and carries a ‘next update’ pointer so consumers know when to refresh.
This is not new infrastructure. The EU has operated Trusted List infrastructure for qualified trust services since eIDAS 1.0. What eIDAS 2.0 does is extend it to the wallet ecosystem: wallet providers, relying party certificate authorities, attestation providers (PID issuers), and national relying party registries all find their place in this framework.
The hierarchy: Trust Lists, Lists of Trusted Lists, Lists of Trusted Entities
Each Member State publishes a national Trust List (TL): the authoritative register of entities designated to operate under its jurisdiction. This includes the certificate authorities designated to issue Wallet-relying party certificates, approved wallet providers, and PID issuers.
Above that sits the List of Trusted Lists (LoTL), published by the European Commission. The LoTL is a meta-list: rather than containing individual entity entries, it contains pointers to each Member State’s TL, together with the trust anchor needed to verify each national list’s signature. The Commission signs the LoTL itself, anchoring the entire chain.
This means a wallet only needs one pre-configured root — the expected Commission’s LoTL anchor — to participate in cross-border verification anywhere in the EU. Every other trust relationship is derived dynamically from that single root. No bilateral agreements, no manual lookups: the trust chain from the LOTL to any credential signature is fully automated and cryptographically verifiable.
At a more granular level, Lists of Trusted Entities (LoTEs) capture entity-level entries — including the authorities, such as Providers of Access Certificates, whose issued certificates WRPs carry when interacting with wallets. The LoTE is the reference point that allows a wallet to verify the issuing authority behind a relying party's certificate. These registries are part of the same family of signed, queryable, machine-readable datasets that wallets use to confirm a relying party is registered and to retrieve what it is designated to do.
Higher-level entities must also be registered. The trust list hierarchy does not only protect end users from illegitimate relying parties; it governs every layer. A certificate authority designated to issue WRP certificates must itself appear in the relevant national TL. A wallet provider must be listed and approved. A PID issuer must be registered as a recognized attestation provider. Every entity that plays a role in the trust infrastructure has to be enumerated, verified, and formally included at the appropriate level, giving the ecosystem full auditability from the LOTL down to the individual transaction.
Publishing and subscribing to trust lists
Trust list participation has two sides: publishing and subscribing.
A Trusted List Provider maintains the entry database, signs each new publication, and exposes it at a stable public endpoint. Consumers such as wallets, verifiers, intermediaries, fetch relevant lists on a regular schedule, verify signatures, and update their local trust state. When a certificate authority is suspended or a relying party is withdrawn, the updated list carries that change automatically to every consumer that has fetched the latest version.
Procivis One is built to operate on both sides. For authorities acting as Trusted List Providers — Member States, national supervisory bodies, QTSPs — Procivis One manages the full publishing workflow: maintaining the entry database, producing signed publications on schedule or on update, and exposing the required endpoints. For wallets, verifiers and issuers, Procivis One consumes trust lists as part of standard operation, keeping local trust state current without manual intervention.
What comes next
Trust is not static: organizations join and leave the ecosystem, certificates expire, wallets are certified and occasionally de-certified. The next edition of our insights covers revocation and lifecycle management: how status changes propagate through the system and what it takes to keep a living trust infrastructure consistent.
To explore how Procivis One handles trust list management, relying-party registration, and certificate issuance as an integrated infrastructure, explore the documentation or request trial access.
