An unfederated application is a service or tool that users access without the identity provider controlling the session end to end. That can happen through local accounts, direct OAuth grants, or vendor-specific login flows. Once access bypasses federation, revocation and auditability become partial at best.
Expanded Definition
An unfederated application is any service that authenticates users outside central federation control, so the identity provider does not govern the full session lifecycle. In practice, that includes local usernames and passwords, application-managed tokens, direct OAuth consent, and vendor-specific login mechanisms that bypass enterprise policy.
That distinction matters because federation is not just about sign-in convenience. It is about who can assert identity, revoke access, enforce MFA, and produce an audit trail that survives a breach review. When an app is unfederated, identity governance shifts from a central control plane to scattered application settings and local admin processes. That makes the term especially relevant in NHI security, where service accounts, API keys, and automation paths often end up adjacent to the same access model as human logins. NIST’s NIST Cybersecurity Framework 2.0 frames this as an access control and visibility problem, not just an authentication choice.
Definitions vary across vendors on whether a partially integrated SSO app still counts as federated, but the operational test is simple: if the enterprise cannot centrally enforce session control and revocation, it is unfederated in practice. The most common misapplication is treating an app as federated because it supports SSO at login, when local accounts or vendor tokens still let sessions persist after access should have been removed.
Examples and Use Cases
Implementing strict control over unfederated applications often introduces onboarding friction, because teams must balance fast adoption against the cost of central identity governance and lifecycle enforcement.
- A SaaS collaboration tool supports Google login for users, but retains local admin accounts for break-glass access, making revocation incomplete after offboarding.
- An internal analytics platform accepts direct OAuth grants from users but stores long-lived refresh tokens that persist beyond the enterprise IdP session.
- A legacy developer portal uses local credentials for both humans and automation jobs, which blurs the boundary between application access and NHI access management.
- A vendor console allows SSO for most users, yet API clients authenticate with vendor-issued tokens that are not visible in the enterprise IAM stack.
- For broader NHI context, the Ultimate Guide to NHIs shows why hidden credentials and weak offboarding are recurring control failures, especially when app-level access paths are not centrally governed.
These patterns are common when an application was adopted before federation standards were required, or when business teams enabled direct grants to avoid integrating with the identity provider.
Why It Matters in NHI Security
Unfederated applications create blind spots that are especially dangerous for NHI governance because they often hide service credentials behind user-facing workflows. Once access is split across local accounts, token grants, and vendor-managed sessions, security teams lose reliable evidence for who or what accessed a system, when it was revoked, and whether rotation actually occurred. That weakens Zero Trust Architecture outcomes and undermines the controls described in Ultimate Guide to NHIs, where NHI lifecycle discipline depends on visibility, offboarding, and secret hygiene.
This matters because the risk is not abstract. NHI Mgmt Group reports that 96% of organisations store secrets outside of secrets managers, 79% have experienced secrets leaks, and 97% of NHIs carry excessive privileges. An unfederated app can turn those conditions into an incident that is hard to contain, because the identity owner may not control the session or even know the credential exists. Organisations typically encounter the consequences only after an offboarding failure, a token leak, or an incident review, at which point unfederated access 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 address the attack and risk surface, while 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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Unfederated apps weaken identity proofing and access enforcement across systems. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust requires continuous, centrally enforced access decisions, which unfederated apps undermine. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Unfederated apps often hide service credentials and break NHI visibility and revocation controls. |
Map every unfederated login path to its owner, secret, and revocation process before granting production access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
