A downstream service that accepts an identity assertion from an upstream provider instead of running the authentication ceremony itself. The relying party depends on the provider’s assurance model, so policy, revocation, and authenticator governance must be understood at the federation boundary.
Expanded Definition
A federated relying party is the downstream application, API, or service that trusts an upstream identity provider to authenticate the subject and assert claims such as subject ID, audience, and assurance level. It does not run the authentication ceremony itself; instead, it validates tokens or assertions under a federation protocol such as SAML, OAuth 2.0, or OpenID Connect, with policy enforced at the trust boundary.
In NHI and IAM programs, the relying party is where identity assertions become operational access. That makes its configuration just as important as the provider’s controls: audience restriction, token validation, revocation handling, claim mapping, and session duration all shape the actual security posture. Definitions vary across vendors on whether service-to-service consumers, workload brokers, and delegated API gateways are all “relying parties,” so teams should document the exact federation role in scope. For baseline identity governance, NIST Cybersecurity Framework 2.0 is useful for mapping authentication and access decisions to broader control outcomes, while NIST Cybersecurity Framework 2.0 helps anchor the access-governance discussion.
The most common misapplication is treating the relying party as a passive consumer, which occurs when teams validate the token format but ignore claim semantics, audience scope, and revocation behavior.
Examples and Use Cases
Implementing federated trust rigorously often introduces dependency on another team’s assurance model, requiring organisations to weigh authentication centralisation against local control over access decisions.
- An internal dashboard accepts OpenID Connect tokens from a corporate identity provider and authorises access based on scoped claims.
- An API gateway acts as the relying party for machine identities issued by an external federation partner, using audience checks to prevent token replay across services.
- A SaaS integration verifies SAML assertions from a workforce IdP before granting session access, then enforces tenant-specific policy locally.
- A workload identity broker consumes short-lived assertions and exchanges them for downstream credentials, reducing secret exposure in pipelines, a pattern discussed in the Ultimate Guide to NHIs.
- A partner portal relies on federated login for contractors, but still applies step-up checks for privileged actions because the federation event alone does not prove ongoing risk status.
For protocol-level handling, implementers commonly align token validation and assertion processing with RFC 6749 and related identity guidance, while using the Ultimate Guide to NHIs to frame lifecycle and governance obligations around non-human subjects.
Why It Matters in NHI Security
Federated relying parties are where upstream identity assertions become real privilege, so mistakes here can turn a valid token into overbroad, durable access. If the relying party accepts stale claims, fails to check audience restrictions, or over-trusts the provider’s assurance, the result is hidden privilege escalation at the federation boundary. That matters especially for NHIs, where service accounts, API clients, and agents may be able to call sensitive systems continuously and at scale.
The NHI risk picture is severe: NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges in modern enterprises. Those conditions make the relying party a governance choke point, not just an implementation detail. Access review, token lifetime, claim minimisation, and revocation propagation should be treated as operational controls, not optional hardening. The Ultimate Guide to NHIs is especially relevant when federated trust extends to third parties or CI/CD systems, where exposure often persists unnoticed until misuse is detected. Organisationally, this term becomes unavoidable after a token is reused, a partner is offboarded, or a workload continues to authenticate after its trust should have been withdrawn.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Federated trust depends on correct identity and assertion validation at the relying party. |
| NIST CSF 2.0 | PR.AC-4 | Federation is an access-control decision that must enforce least privilege. |
| NIST SP 800-63 | CSP-1 | Federated assertions rely on the identity provider’s assurance and binding practices. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires policy enforcement at every access decision, including federation. |
| OWASP Agentic AI Top 10 | A-04 | Agentic systems using federated identities must constrain delegated tool and API access. |
Limit claims, scopes, and session duration for agents acting through federated relying parties.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
