A federated app is an application that relies on an external identity provider for authentication, usually through single sign-on. This centralises login control and makes access governance easier than in isolated systems. However, federation alone does not solve authorisation, lifecycle, or offboarding problems across the full SaaS estate.
Expanded Definition
A federated app is an application that outsources authentication to an external identity provider, commonly through single sign-on and standards such as SAML or OpenID Connect. The app trusts the identity assertion, but it still needs its own authorisation logic, session handling, and account lifecycle controls. In NHI environments, that distinction matters because federation can simplify login without eliminating the governance burden for service accounts, API users, and machine-to-machine access.
Definitions vary across vendors when federation is discussed alongside identity brokerage, but the operational meaning is consistent: the app does not own the primary login ceremony. In a mature architecture, federation should be paired with privilege controls, entitlement mapping, and offboarding processes so that access can be revoked even when credentials live outside the application boundary. The NIST Cybersecurity Framework 2.0 reinforces this separation between identity assurance and ongoing access governance.
The most common misapplication is assuming federated login equals complete access control, which occurs when teams stop at SSO integration and leave stale entitlements, shared roles, or unmanaged service identities in place.
Examples and Use Cases
Implementing federated app access rigorously often introduces dependency on the external identity provider, requiring organisations to weigh centralized control against outage risk and integration complexity.
- An internal SaaS dashboard uses corporate SSO so employees authenticate through the enterprise IdP instead of local passwords, but the application still enforces role-based access based on department and duty.
- A developer portal federates login for human users while separately managing API keys and service accounts for automated pipelines, since those non-human identities are governed differently.
- A partner-facing platform accepts identities from an external tenant through federation, but the application must still map partner claims to least-privilege entitlements.
- A cloud-admin console is federated through the primary directory, yet privileged actions require additional approval and session logging to reduce standing access.
- During M&A integration, a federated app allows rapid onboarding of acquired staff, while the security team validates that old accounts are disabled and orphaned access is removed.
For broader NHI governance context, Ultimate Guide to NHIs is useful when federated applications also rely on service principals, secrets, or automated workflows. Standards guidance for identity assertions and relying-party trust can also be compared with the NIST Cybersecurity Framework 2.0 when mapping authentication to downstream access decisions.
Why It Matters in NHI Security
Federated apps are important in NHI security because they often conceal the real control gap: authentication may be centralised, but authorisation and lifecycle management remain fragmented. That gap becomes dangerous when service accounts, API tokens, or automation identities are attached to federated workloads but are not tracked with the same discipline as human users. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
These failures matter because federated login can create a false sense of control. If a user leaves, a partner relationship changes, or an automation path is retired, access must still be removed at the app layer and in connected systems. Guidance across identity programs and the Ultimate Guide to NHIs points to a common pattern: identity federation is only one control plane, not the whole access model.
Organisations typically encounter the impact only after an audit failure, breach investigation, or partner offboarding event, at which point federated app governance becomes 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 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 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 apps still need identity, privilege, and lifecycle controls for NHIs. |
| NIST SP 800-63 | AAL2 | Federation depends on assurance in the upstream identity assertion. |
| NIST CSF 2.0 | PR.AC-1 | Federated access must still be authorized and governed after authentication. |
| NIST Zero Trust (SP 800-207) | GV.AC-1 | Zero Trust treats identity as one signal, not a blanket trust decision. |
| CSA MAESTRO | Federated apps in agentic systems need policy, trust, and tool-access governance. |
Verify the app's federated identities, then govern every service account and token with least privilege.
Related resources from NHI Mgmt Group
- Who is accountable when a SaaS app accepts the wrong federated identity?
- What is the difference between app-specific passwords and modern federated authentication for cloud applications?
- Why can a single SaaS app create such a large blast radius?
- What is the difference between a service account and an OAuth-connected app?
