TL;DR: EUDI trust lists turn participation into a signed, role-specific decision, with Procivis saying the hierarchy from national lists to the EU-level list creates a cryptographic chain of trust. Wallet ecosystems need current publication and validation, or accepted roles can drift from the signed record.
Editorial analysis by NHI Mgmt Group, based on content published by Procivis: “EUDI trust lists: what they are and how they work”.
Key questions
Q: Why do signed trust lists matter more than simple registration records?
A: Signed trust lists matter because they let consumers verify both identity and authority without relying on manual checks or bilateral agreements.
Q: What breaks when trust list refreshes are delayed or missed?
A: The local trust state can become stale, meaning consumers may continue to accept entities that have been suspended or withdrawn.
Q: How should organisations govern trust lists in a federated identity ecosystem?
A: They should treat trust lists as governed control points, not static directories.
Practitioner guidance
- Map every trusted role to its service type Document which entities are authorised as wallet providers, PID issuers, certificate authorities, and relying parties, then verify that each appears in the correct list layer with the correct designation.
- Operationalise trust list refresh checks Set explicit monitoring for next-update pointers and signature validation so local trust state is refreshed before relying parties or issuers drift out of the approved set.
- Separate enumeration from authorisation Ensure teams do not treat presence in any trust list as blanket approval.
Bottom line: EUDI trust lists turn ecosystem participation into a signed, role-specific governance decision rather than a loose recognition process.
Glossary terms: Trust List, Trusted List, Trust anchor, Service Type
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Trust lists are governance objects, not just technical lookups: The core value of an EUDI trust list is that it binds identity to delegated function. That is a stronger control than simple allowlisting, because the ecosystem is asking not only who exists, but who is allowed to issue, attest, or rely in a specific capacity. Practitioners should read this as a lifecycle governance problem across multiple trusted roles, not a directory-management exercise.
A question worth separating out:
Q: How do wallet providers, issuers, and relying parties differ in a trust list model?
A: They are distinct roles with distinct permissions. A wallet provider is not automatically a certificate authority, and a PID issuer is not automatically a relying party. The trust model works only when each entity is registered for the exact function it performs.
👉 Read our full editorial: EUDI trust lists define the chain of trust for wallet ecosystems