They should treat trust infrastructure as an operating capability, not a document set. That means onboarding relying parties, verifying their identity, governing status changes, and making authorisation discoverable at transaction time. In practice, the registry has to work with trusted lists, certificate services, and credential catalogues so wallets and verifiers can establish trust across borders and keep pace with a changing participant base.
What trust infrastructure has to do in an EUDI Wallet ecosystem
Trust infrastructure is the mechanism that lets a wallet ecosystem decide which parties can be trusted at the moment of use. For national programmes, that means moving beyond static policy and maintaining an operational trust layer that can verify relying parties, publish their status, and support cross-border trust decisions as participants change.
That operational layer matters because wallets are not just presenting credentials, they are entering transactions with verifiers whose legitimacy, authorisation scope, and current status can change over time. If the trust model is not live, the ecosystem becomes brittle: a party may still look valid on paper while being suspended, removed, misconfigured, or no longer authorised for a specific transaction.
At a minimum, the trust layer needs three functions to work together: participant onboarding and identity vetting, authoritative status management, and discovery services that let wallets and verifiers resolve trust data when a transaction starts. In practice, that usually means a registry, trusted lists, certificate services, and credential catalogues that describe who may rely on what, under which conditions.
Why operational trust beats static trust documents
National programmes often begin with governance documents, trust frameworks, and bilateral agreements, but those artefacts do not by themselves establish transaction-time assurance. An EUDI Wallet ecosystem needs trust to be machine-readable and continuously current, because the deciding question is not whether a party was approved once, but whether it is approved now for this interaction.
This is especially important in federated ecosystems where a relying party may span multiple sectors or jurisdictions. The operational problem is not merely publishing rules, it is ensuring that wallets, issuers, and verifiers can consume the same trust signals and make consistent decisions without manual interpretation at each exchange.
That is why discovery and status publication are core functions rather than administrative extras. If a verifier cannot reliably check current authorisation, or if a wallet cannot discover the trust anchor it needs for a cross-border transaction, the ecosystem falls back to ad hoc exceptions, slower user journeys, and inconsistent acceptance decisions.
How to design the trust layer so it keeps pace with the ecosystem
The practical design choice is to treat the trust infrastructure as a lifecycle service. Onboarding should validate entity identity and role, status changes should be governed through a formal update path, and revocation or suspension should propagate quickly enough that stale trust cannot be used as an access path.
That lifecycle view should extend to the ecosystem’s supporting artefacts. Trusted lists, certificate services, and credential catalogues should not be isolated registers; they should be aligned so that a relying party’s eligibility, its cryptographic trust material, and its allowed use cases tell the same story. Where those layers drift apart, implementers start compensating with local exceptions, and trust becomes inconsistent across participants.
Cross-border interoperability also depends on clear boundaries between policy and evidence. National programmes should make it easy for a verifier to discover what it needs to trust, but they should avoid letting every implementation invent its own trust logic. The goal is a common trust fabric that is authoritative, queryable, and updated as the participant base changes.
Risk and Threat Considerations
Weak trust infrastructure creates a straightforward exposure: a wallet ecosystem may continue to accept relying parties that should no longer be trusted, or reject legitimate ones because trust data is stale or incomplete. The result is both security risk and operational fragility, especially when trust status is used as a gate for high-value transactions.
Failure mechanism: stale registries, delayed revocation, broken status propagation, or inconsistent trust-source interpretation let a removed, compromised, or unauthorised party continue participating in transactions, or force local exceptions that bypass the intended trust model.
Impact: fraudulent acceptance, cross-border interoperability failures, transaction delays, and a loss of confidence in the wallet ecosystem’s ability to distinguish legitimate relying parties from unsafe ones.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Rules which relying parties may transact under current trust status. |
| IA-5 — Authenticator Management | Trust infrastructure depends on lifecycle control of certificates and other trust material. | |
| Recommendation — Enforce current authorisation before a wallet transaction is accepted. Manage trust credentials with timely issuance, rotation, and revocation. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Trust infrastructure needs governed identity records for participating parties. |
| A.5.17 — Authentication information | Wallet ecosystems depend on controlled trust material such as certificates and keys. | |
| A.5.19 — Information security in supplier relationships | Relying parties and trust services act as external ecosystem dependencies. | |
| Recommendation — Maintain authoritative identities for all trusted ecosystem participants. Protect and lifecycle-manage the credentials used to establish trust. Apply supplier controls to external parties that participate in the trust fabric. | ||
Practitioner Guidance
What to prioritise: Build the trust layer as an operational service with explicit ownership, not as a governance appendix. If a relying party cannot be onboarded, status-managed, and discovered by machine at transaction time, the trust model is not yet production ready.
What to verify: Confirm that status changes propagate through the registry, trusted lists, and certificate or catalogue services within a defined operational window, and that wallets and verifiers consume the same authoritative source of truth.
Practitioner takeaway: The decisive test is whether trust can be answered automatically at the moment of use, because static approval without live status control is not enough for a cross-border wallet ecosystem.
Related resources from NHI Mgmt Group
- How does trust infrastructure affect identity governance programmes?
- Why do device trust signals create risk in digital identity programmes?
- How should organisations govern identity trust in national digital platforms?
- Why do national identity systems matter when organisations are trying to improve digital trust and reduce fraud?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
