Apps outside SSO

what it is

Single Sign-On (SSO) is the mechanism that routes authentication for all applications through one central identity provider, such as Microsoft Entra ID, Google Workspace, or Okta. When a user logs into an SSO-connected application, their credentials are verified against the identity provider. The application trusts the provider's confirmation.

This centralization means that access management actions taken in the identity provider, including closing an account, enforcing MFA, or changing permissions, propagate to all SSO-connected applications immediately.

Applications outside SSO authenticate independently. They maintain their own user databases. Login is handled with the application's own credentials, not through the identity provider. Changes in the identity provider do not reach these applications. A closed directory account does not close the application account.

"Apps outside SSO" describes the portion of a SaaS environment that operates outside this central control point and that therefore requires separate, manual access management.

why it accumulates

Several forces keep a significant share of most SaaS environments outside SSO.

SSO support is not universal. Many tools, particularly those at lower price tiers, either do not support SSO at all or include it only in enterprise or premium plans. Organizations on cost-conscious licenses frequently have tools where SSO is a paid upgrade they have not purchased.

Departmental adoption bypasses IT. When a team adopts a tool without going through IT, the tool is almost never integrated into SSO. The team creates accounts using email and password. The tool is never registered with the identity provider.

Legacy and long-standing tools drift. Applications that were added to the environment years ago, before SSO was enforced as a standard, often stay on independent credentials indefinitely. Migrating them requires time and effort that gets deprioritized against current priorities.

what it costs you

Offboarding blindspot. Closing a user's directory account closes access to SSO-connected applications. Applications outside SSO remain untouched. Without a separate, manual step to close the account in each one, former employees retain access. The manual step depends on IT knowing the application exists.

MFA enforcement gap. MFA enforced at the identity provider level applies to SSO-connected applications. Applications outside SSO have their own MFA settings, which may not be configured or may not be enforced consistently. A user account in a tool outside SSO may be protected only by a password, even if the organization has MFA enforced everywhere else.

No visibility in access reviews. Access reviews check who has access to what. For applications outside SSO, the review requires logging into each application's admin console separately. In practice, applications outside SSO are frequently missed in review cycles, which means their permissions are never formally validated.

Incident response delay. If a security event occurs and you need to cut off an account's access across all tools, SSO-connected applications can be handled in one action. Applications outside SSO require a separate action in each one. In a time-sensitive incident, this delay matters.

what works

The identity provider's admin console shows which applications are registered for SSO, and that list defines the governed perimeter. Comparing it against the broader application registry surfaces the tools that sit outside the central control point. The comparison has a known blind spot worth understanding: a directory can only reveal what touches it, so an application that authenticates entirely on its own credentials and holds no OAuth grant leaves no trace in the IdP at all. Expense records and direct questions to department leads are what surface that remainder.

For each application outside SSO, the deciding questions are whether the vendor supports SSO and whether it is available on the current plan. Tools that support it and process sensitive data are the natural first candidates for integration, since they offer the largest governance gain for a configuration task. Making SSO support a standard requirement in tool evaluation, with plan-level availability documented before purchase, keeps the gap from widening with each new adoption.

Some applications will never come inside: the vendor does not offer SSO, or offers it only at a licensing tier that cannot be justified. What works for those is explicit tracking plus compensating controls. Admin credentials held by more than one person, MFA enforced inside the application itself, and a fixed place on every offboarding checklist together approximate the protections the IdP would otherwise provide. The control that fails silently is the undocumented exception: an application everyone assumes the directory governs when it never did.