A downstream application or service that accepts identity assertions from an external identity provider. It trusts the incoming authentication event, but it still needs local policy, entitlement checks, and evidence handling to avoid turning federation into uncontrolled access.
Expanded Definition
A relying application is the downstream system that consumes an identity assertion issued by a trusted identity provider. In NHI and agentic AI environments, that assertion may represent a service account, workload, API client, or autonomous agent, but the relying application still owns the final access decision.
The distinction matters because federation is only one layer of trust. A valid token, certificate, or signed response does not automatically justify broad access inside the target system. Good implementations combine external authentication with local authorization, entitlement mapping, session constraints, and evidence retention. That approach aligns with guidance in the NIST Cybersecurity Framework 2.0 and the Zero Trust posture described in NIST Cybersecurity Framework 2.0, where trust is verified continuously rather than assumed at the perimeter.
Definitions vary across vendors when federation, SSO, and application authorization are blended together, but the operational meaning is consistent: the relying application must not treat inbound identity as a free pass. The most common misapplication is accepting an assertion as both authentication and authorization, which occurs when the application fails to re-check local policy after trusting the upstream identity event.
Examples and Use Cases
Implementing relying application controls rigorously often introduces integration overhead, requiring organisations to balance simpler single-sign-on flows against tighter entitlement enforcement and better auditability.
- A SaaS platform accepts a signed login from an identity provider, then applies local RBAC to decide whether the user or service account can invoke administrative functions.
- An internal API gateway trusts a workload identity from an external issuer, but still requires audience checks, token scope validation, and request logging before forwarding traffic.
- An AI agent connects to a ticketing system as an approved client, and the relying application limits it to read-only actions unless a separate approval step grants JIT elevation.
- A partner integration uses federated SSO for convenience, while the downstream application enforces tenant boundaries and denies access to sensitive records unless policy conditions are met.
- An NHI program reviews how a relying application handles secrets and assertions because weak downstream controls can undermine the governance model described in the Ultimate Guide to NHIs.
These patterns are especially important where the upstream identity is strong but the target system has privileged functions. In practice, application teams often use federation to reduce password sprawl, then discover that the real risk sits in the downstream authorization model. For implementation details around trust and token handling, the NIST Cybersecurity Framework 2.0 remains a practical reference point.
Why It Matters in NHI Security
Relying applications are where identity assurance becomes real business impact. If they over-trust upstream assertions, a compromised service account, stolen token, or abused agent session can turn a single identity event into wide downstream access. That is why NHI governance has to include the consuming system, not just the issuer.
This is not a theoretical issue. In Ultimate Guide to NHIs, NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which increases unauthorised access and broadens the attack surface. A relying application that skips local checks effectively amplifies that problem by accepting every assertion at face value. The downstream risk grows further when organisations cannot trace what the application did with the authenticated identity, or when evidence is too thin to support incident response and revocation.
For governance teams, the practical lesson is simple: the identity provider authenticates, but the relying application authorizes, constrains, and records. Organisations typically encounter this consequence only after a token replay, privilege misuse, or agent abuse event, at which point relying application controls become operationally unavoidable to address.
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 address the attack and risk surface, while 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 |
|---|---|---|
| NIST SP 800-63 | Covers federation assurance and relying party responsibilities for accepted identity assertions. | |
| NIST Zero Trust (SP 800-207) | Requires continuous verification and policy enforcement at the consuming application boundary. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Downstream acceptance of identities without local checks increases secret and token abuse risk. |
Combine federation with entitlement controls, logging, and secret hygiene in the relying app.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
