Treat relying-party access as an authorisation problem, not only a registration exercise. Define what each organisation may request, require evidence before approval, and make the approved scope machine-readable so wallets can enforce it automatically. Without that, users are left interpreting trust manually, which defeats the point of wallet-based identity.
Why wallet relying party access needs governance, not just onboarding
Wallet ecosystems work best when the relying party is treated as a governed consumer of identity data and assertions, not just a name in a directory. The real control question is whether the organisation is entitled to ask for specific attributes, under what legal or policy basis, and for what user journey. That means access should be scoped, reviewed and revoked like any other trust relationship.
Digital Identity, eID and Identity Wallets Guide explains the wallet trust model, including how relying parties fit into eID and verifiable credential flows. For governance, that matters because the wallet is enforcing an approved trust decision, not inventing one at presentation time.
Approval should therefore attach to concrete request parameters: which organisation, which use case, which attributes, which assurance level, and which presentation methods are permitted. If those terms stay informal, the wallet cannot reliably enforce policy, and users or integrators end up making trust decisions manually. That creates inconsistent access and weakens auditability across the ecosystem.
What good relying party governance looks like in practice
The strongest model is a machine-readable trust policy that can be checked before a wallet releases data or accepts a request. Organisations should define an approval workflow, capture evidence of need, bind the approved scope to technical policy, and make expiration or review dates explicit. Scope should be narrow enough that a wallet can reject unauthorised requests without human interpretation.
IAM and IGA Basics is useful here because relying party governance follows the same core pattern as access governance: define entitlement, review entitlement, and revoke entitlement when purpose or ownership changes. In wallet ecosystems, the entitlement is not a user role but a trusted request path and the attributes it may consume.
Evidence before approval should be proportionate to the data requested. A low-assurance, high-volume request for basic age or membership checks should not be governed the same way as access to government or financial attributes. Practitioners should expect to document the relying party's purpose, data minimisation rationale, technical integration, and operational owner before enabling production access.
Third-Party, B2B and Contractor Access Guide maps closely to this model because relying parties are external consumers of trust, even when they are not traditional vendors. The same governance discipline applies: sponsor the relationship, limit the scope, set time bounds, and review whether the partner still needs the access it was granted.
How to prevent trust sprawl and scope creep
Governance breaks down when the initial approval becomes a permanent default. The most common failure mode is broad, reusable relying party access that quietly expands to new attributes, new journeys, or new subsidiaries without reapproval. Another is treating trust registration as a one-time onboarding task while ignoring the ongoing entitlement lifecycle, including review, suspension and removal.
Ultimate Guide to NHIs — Regulatory and Audit Perspectives reinforces the importance of auditable trust decisions and clear ownership. Even though wallet relying parties are not the same as machine identities, the governance lesson is similar: when access is granted outside a human session, policy discipline and audit evidence matter more, not less.
Scope creep is especially dangerous when the relying party API is technically capable of requesting more than the business case justified. The policy should prevent "ask now, justify later" behaviour by binding the allowed claims, presentation format and relying party identifier ahead of use. If the wallet cannot distinguish approved from unapproved requests in a deterministic way, the trust model is too loose.
Risk and Threat Considerations
Weak relying party governance creates an exposure problem, because broad or ambiguous trust lets an organisation request more identity data than it truly needs and makes abuse harder to detect. The main risk is not only over-disclosure, but also trust confusion, where users or operators cannot tell whether a request is legitimate, excessive or stale.
Failure mechanism: If relying party approvals are informal or static, the ecosystem accumulates excessive trust, stale scopes and inconsistent enforcement. That makes it easier for a compromised or overreaching relying party to collect more data than intended, or to keep operating after its original purpose has expired.
Impact: The result can be unnecessary disclosure, privacy harm, failed user confidence, weak audit trails and a larger blast radius when a relying party is abused or compromised. In regulated environments, the same weakness can also become a compliance problem because the organisation cannot show why access was granted or when it should have been removed.
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-2 — Account Management | Relying party approvals and revocation are lifecycle controls over external access. |
| AC-3 — Access Enforcement | Wallets must enforce approved claim and scope decisions automatically. | |
| AU-2 — Event Logging | Relying party requests and approvals need auditable evidence and traceability. | |
| Recommendation — Track, review, and revoke relying party access as managed accounts or access pathways. Enforce approved relying party scope in policy rather than at manual request review. Log relying party requests, approvals, and scope changes for later review. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Relying party access is an access-control decision over identity data release. |
| A.5.18 — Access rights | Approved relying party access should be granted, reviewed, and removed like other rights. | |
| Recommendation — Define and enforce access rules for each relying party and requested attribute set. Review and remove relying party rights when purpose or ownership changes. | ||
Practitioner Guidance
What to prioritise: Treat the policy model first, not the integration. Before a relying party goes live, make sure the request is expressed in terms the wallet can evaluate automatically: organisation, purpose, attributes, assurance and expiry.
What to verify: Confirm that every approved relying party has an owner, a review date and a bounded scope that matches the business case. If the approval cannot be traced from policy to technical enforcement, the control is not real.
Decision rule: If the relying party needs broader access than the wallet can safely express, narrow the request or split the use case. Do not let convenience drive a permanent expansion of trust.
Practitioner takeaway: The right governance model makes relying party access revocable and machine-enforceable; if a human has to interpret trust at runtime, the ecosystem has already lost most of its security value.
Related resources from NHI Mgmt Group
- How should organisations govern third-party identity access more tightly?
- How should organisations govern identity when digital access and physical access are split across different systems?
- How should organisations govern human and machine identities as identity estates scale across cloud and third-party access?
- How should organisations prepare identity and access processes for the eIDAS 2 digital wallet model?
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 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org