They validate the certificate chain back to an authorised certificate provider and then to a trusted root in the Member State trust framework. That means trust depends on both cryptographic validity and the operational trust list. If either layer is missing or stale, the wallet should not treat the party as trusted.
How wallets decide a certificate is trustworthy
The trust decision is a two-step check. First, the wallet validates the certificate chain to confirm the signature path is cryptographically sound. Second, it checks that the chain ends at an authorised certificate provider and a trusted root in the Member State trust framework. A certificate can be technically valid yet still fail trust if the operational trust list is missing, stale, or inconsistent.
That split matters because wallets are not just verifying math, they are verifying policy. A wallet should treat certificate trust as a governed decision, not a blanket acceptance of any well-formed certificate.
What can make a relying party look valid but still not trusted?
A relying party certificate can fail trust even when the certificate itself is structurally correct. Common failure modes are an unknown issuer, a broken or incomplete chain, revocation or trust-list updates that have not propagated, or a root that is not recognised by the wallet’s local trust configuration. In practice, trust depends on both the public-key chain and the current trust registry.
For wallet operators, the hardest issue is often not the certificate format, but trust-list freshness. If the wallet relies on an outdated trust anchor set, it may reject legitimate parties or, worse, continue to trust a party that should have been removed.
When certificate policy and trust registries are part of the decision, CA/Browser Forum requirements are a useful reference point for how trust anchors, issuance expectations, and revocation discipline are expected to behave in a public trust model.
Why certificate trust is an identity and trust-governance problem
This is not only a cryptography question. It is also a trust-governance question because the wallet is deciding which relying parties are allowed to assert claims into the ecosystem. That decision depends on the legitimacy of the certificate authority path, but also on whether the wallet’s trust framework is current, authoritative, and aligned to the Member State policy set.
For implementers, the lesson is that trust is an active dependency. A wallet that cannot reliably ingest trust list updates, validate chains correctly, and distinguish authorised providers from merely valid certificates will create inconsistent authentication outcomes across users, issuers, and relying parties.
Where the trust decision extends into lifecycle handling and certificate renewal policy, Machine Identity, PKI and Certificate Lifecycle Guide is a strong companion resource on how certificate validity, renewal, and trust maintenance behave over time.
When the trust relationship is implemented through wallet, issuer, and relying-party interaction, Digital Identity, eID and Identity Wallets Guide provides the broader operating context for wallets, verifiable credentials, and trust frameworks.
Risk and Threat Considerations
The main risk is false trust, either rejecting a legitimate relying party because the trust list is stale, or accepting a party whose certificate still chains correctly but should no longer be trusted operationally. That creates exposure at the trust boundary, where a wallet may disclose attributes or proceed with authentication based on an outdated trust state.
Failure mechanism: The wallet accepts a certificate chain without confirming that the issuing path still maps to a trusted provider and a current trust anchor in the Member State framework.
Impact: Trust decisions become inconsistent, which can lead to failed transactions, user friction, or unauthorised reliance on a party that should have been removed from the trust set.
Where trust frameworks are federated or shared across parties, stale revocation or lagging trust-list distribution becomes an availability and integrity issue, not just a configuration nuisance. If the wallet cannot refresh trust state quickly enough, the security model degrades from policy-based trust to “last known good” trust.
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, NIST SP 800-57 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Wallet trust depends on current certificate and trust-anchor handling. |
| IA-9 — Service Identification and Authentication | The wallet authenticates relying parties through certificate-based trust decisions. | |
| Recommendation — Manage certificate and trust-material lifecycle so stale trust anchors are replaced promptly. Verify relying-party identity with certificate-based authentication and trusted anchors. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Wallet trust governs which relying parties may be accepted by policy. |
| Recommendation — Define and enforce trust-acceptance rules for relying parties. | ||
| NIST SP 800-57 | Key Management | Certificate trust relies on proper key and certificate lifecycle management. |
| Recommendation — Rotate and retire keys and certificates in line with lifecycle policy. | ||
| NIST CSF 2.0 | PR.AA-05 — Authentication is enforced for access based on least privilege and risk | Trusting a relying party is a gated access decision based on validated identity. |
| Recommendation — Require validated trust before granting relying-party access. | ||
Practitioner Guidance
What to verify: Confirm that the wallet checks both the certificate chain and the current trust registry before accepting a relying party. A chain that validates cryptographically is not enough if the trust anchor is absent, revoked, or outdated.
Decision rule: If the trust anchor set cannot be verified as current, treat the relying party as untrusted until the wallet has refreshed its trust material and revalidated the chain.
What good looks like: The wallet has a deterministic trust path, clear refresh logic for trust lists, and observable rejection behaviour when either the certificate chain or the operational trust layer fails.
Practitioner takeaway: The control objective is not simply to validate certificates, it is to keep trust anchored to an up-to-date policy source so a valid chain cannot outlive its authorised trust status.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org