An application that cannot be governed through standard single sign-on or automated provisioning protocols such as SAML or SCIM. These tools often require alternative control paths, which makes lifecycle management, auditability, and access review more difficult for identity teams.
Expanded Definition
A Non-SSO Application is any application that cannot be governed through standard single sign-on flows or automated provisioning interfaces such as SAML or SCIM. In practice, that usually means identity teams must manage access through local accounts, custom connectors, API-based controls, or manual workflows. For NHI operations, the issue is not only user authentication but also how machine identities, service accounts, and secrets are created, updated, and removed when the application sits outside the normal identity plane.
Definitions vary across vendors, because some teams call an app “non-SSO” when it lacks federation entirely, while others use the term for systems that support login federation but not lifecycle automation. The operational distinction is whether access can be centrally attested and revoked without touching the application directly. That makes governance harder, especially where privileged service access is embedded in the application itself. The NIST Cybersecurity Framework 2.0 remains the closest broad reference for control ownership, but it does not solve the application integration gap by itself. The most common misapplication is treating a non-SSO application as if it were covered by normal joiner-mover-leaver controls, which occurs when identity teams assume federation exists just because the app has a login screen.
Examples and Use Cases
Implementing governance for non-SSO applications rigorously often introduces process overhead, requiring organisations to weigh stronger access control and auditability against slower onboarding and more manual exception handling.
- Legacy admin consoles that accept only local usernames and passwords, forcing the use of vaulting and periodic credential rotation rather than SCIM-driven deprovisioning.
- Internal tools that support SAML for interactive users but expose no lifecycle API, so service accounts and API keys must be tracked separately from human access.
- On-premises platforms with embedded authentication stores, where access reviews depend on exportable reports and compensating controls instead of central identity orchestration.
- Third-party business apps that cannot integrate with enterprise SSO, requiring tightly scoped local accounts and documented offboarding steps tied to Ultimate Guide to NHIs lifecycle guidance.
- Systems that support partial federation, such as login via SSO but manual provisioning, where teams must separately manage secrets, entitlements, and revocation timing in line with NIST Cybersecurity Framework 2.0.
These cases are common in environments where business continuity depends on software that predates modern identity standards, or where vendor limitations prevent full integration into the enterprise IAM stack.
Why It Matters in NHI Security
Non-SSO applications are a governance blind spot because they often become the exception path where secrets, service accounts, and emergency access accumulate outside normal policy. That increases the chance that a credential outlives its business need, a deprovisioning event is missed, or a privileged account is never reviewed. In NHI programs, these gaps are especially dangerous because machine access is frequently broader than human access and much harder to observe. NHI Mgmt Group reports that Ultimate Guide to NHIs shows only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of visibility problem non-SSO systems tend to amplify.
Practitioners should treat these applications as compensating-control candidates, not as an acceptable permanent exception without review. That means documenting ownership, mapping every local credential to a business purpose, and ensuring rotation, logging, and offboarding occur on a fixed cadence. Where possible, teams should align these controls with enterprise guidance from the NIST Cybersecurity Framework 2.0 while using NHI-specific research from Ultimate Guide to NHIs to prioritise the highest-risk applications first. Organisations typically encounter the true cost of a non-SSO application only after an access review, incident, or failed offboarding reveals that no reliable revocation path exists, at which point the term 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Non-SSO apps often drive secret sprawl and weak lifecycle controls. |
| NIST CSF 2.0 | PR.AC-4 | Access provisioning and revocation must still enforce least privilege. |
| NIST Zero Trust (SP 800-207) | Non-SSO apps weaken central policy enforcement in Zero Trust environments. |
Wrap non-SSO systems with compensating controls, strong segmentation, and continuous verification.
