Apps outside SSO are applications that users can access without passing through the organisation’s identity provider. They are difficult to govern because standard access policies, session controls, and revocation workflows no longer apply consistently, which leaves entitlement decisions fragmented across local app admins.
What Apps Outside SSO Are
Apps outside SSO are applications that sit outside the central sign-in path, so access is granted and maintained in the app itself rather than through the organisation’s identity layer. That makes them easy to overlook, but hard to govern at scale.
Why They Create Governance Blind Spots
The core issue is fragmentation. When an app is not tied into SSO, the organisation loses a common control point for access policy, session enforcement, and revocation, which means entitlement decisions often drift into local admin hands. Over time, that produces inconsistent access standards and weaker visibility into who can get in, how they got there, and whether access still matches need.
Apps outside SSO also break the normal operating assumption that one identity event can govern many downstream apps. In an integrated environment, joiner, mover, and leaver actions can propagate through the identity platform; outside SSO, those changes may have to be repeated manually in each application, increasing delay and error risk. Workforce Identity Security Guide and IAM and Identity Provider Buyer’s Guide both reinforce why centralised lifecycle control matters.
How They Interact With Sessions, Tokens, and Federation
Outside-SSO apps often rely on local passwords, ad hoc tokens, or separate API credentials, which creates a parallel trust model. That raises the chance of shadow authentication paths, duplicated accounts, and stale access that outlives the central identity record. When the app does support federation but only partially, the boundary between central login and local fallback becomes the place where assurance is weakest.
These apps are also where token theft, stale OAuth grants, and third-party access chains become especially dangerous. A compromised integration can bypass user-facing SSO entirely and still expose business data, as shown in Salesloft OAuth token breach, Klue OAuth Supply Chain Breach, and OpenID Connect Core 1.0, which defines the authentication layer that SSO integrations are meant to standardise.
What Good Control Looks Like
Managing apps outside SSO starts with inventory, because you cannot govern what you cannot see. The practical task is to distinguish genuinely non-integratable applications from ones that simply have not yet been onboarded, then reduce the latter wherever possible. For the remainder, organisations need compensating controls around ownership, offboarding, authentication, and periodic access review.
That work is usually less about a single control and more about closing the gap between identity governance and application administration. If a business must keep an app outside SSO, then the access model should still be explicit, documented, and reviewable, with a clear owner for revocation and exceptions. Identity Provider and SSO Security Guide is useful here because it shows the broader hardening and monitoring assumptions that outside-SSO apps fail to inherit by default.
Risk and Threat Considerations
Apps outside SSO create an attractive gap for attackers because they often preserve access even after the central identity layer has been locked down, reset, or monitored. They also increase the chance that old accounts, shared credentials, or orphaned integrations remain active long after they should have been removed.
Failure mechanism: Local authentication, disconnected revocation, and weak ownership let access survive outside the organisation’s normal identity and session controls, so compromise or leakage in one app does not get caught by the central control plane.
Impact: The result can be persistent unauthorised access, delayed offboarding, broader token or password exposure, and a larger attack surface for lateral movement through business systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Apps outside SSO weaken central user authentication and session governance. |
| IA-5 — Authenticator Management | Outside-SSO apps often rely on local passwords, tokens, or app credentials. | |
| AC-2 — Account Management | Apps outside SSO fragment provisioning and deprovisioning workflows. | |
| Recommendation — Require centralized user authentication wherever the app can support it. Track, rotate, and revoke app-specific authenticators on a defined schedule. Centralize account lifecycle ownership and remove stale local accounts promptly. | ||
Practitioner Guidance
Why practitioners should care: Treat apps outside SSO as an exception to standard identity governance, not as a neutral implementation detail. Every exception should have a named business owner, a documented reason for being outside SSO, and a review path for eventual migration or compensating control.
What to watch for: The biggest warning signs are duplicated accounts, manual deprovisioning, shared logins, and integrations that can continue to operate after a user leaves or a session should have ended. Those are the places where governance breaks down first.