How should security teams handle applications that cannot be integrated into SSO?

Why This Matters for Security Teams

Applications that cannot join SSO are not a niche inconvenience. They create a parallel access path where identity, entitlement, and session controls are often weaker, less visible, and harder to audit. That matters because unmanaged apps usually hold real business data, connect to other systems, or expose credentials that can be reused elsewhere. NHI Management Group notes that only 5.7% of organisations have full visibility into service accounts in its Ultimate Guide to NHIs, which is a reminder that access gaps rarely stay isolated. The same problem shows up in third-party and OAuth-connected services, where the State of Non-Human Identity Security found 85% of organisations lack full visibility into connected vendors.

The real mistake is treating “not SSO-capable” as “not governable.” Security teams still need to know who uses the app, what data it can reach, what credentials it stores, and how access is revoked. Without that, password sharing, orphaned accounts, and stale service credentials become the default control plane. In practice, many security teams discover the blast radius of these apps only after an audit finding, a vendor incident, or a credential leak has already exposed them.

How It Works in Practice

The practical response is to manage these applications as exceptions with compensating controls, not as unmanaged exceptions to policy. Start by inventorying every app that cannot integrate with SSO, then classify it by business criticality, data sensitivity, and whether it supports user, administrator, or system access. From there, choose the least disruptive control combination that reduces risk without blocking operations. NIST guidance is useful here because the NIST Cybersecurity Framework 2.0 emphasizes identification, protection, and continuous oversight rather than relying on a single access mechanism.

• Require named owner accountability for every non-SSO app.
• Use MFA where the application supports it, even if federation does not.
• Prefer dedicated accounts over shared logins, and monitor them closely.
• Move privileged access into PAM when admin functions exist.
• Rotate any stored secrets, API keys, or integration tokens on a defined schedule.
• Set a retirement path for apps that cannot meet minimum governance requirements.

For service-to-service access, the focus should shift from user SSO to workload identity, short-lived secrets, and strong logging. If an app cannot support federation, teams should compensate with tighter access reviews, explicit approval workflows, and evidence of actual usage. NHI Management Group’s Schneider Electric credentials breach is a useful reminder that exposed credentials can become a breach path even when the application itself is not “high profile.” These controls tend to break down when the application is deeply embedded in legacy operations because shared credentials, brittle integrations, and weak audit trails make replacement slow and risky.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so teams need to balance risk reduction against business continuity. That tradeoff is especially visible with legacy platforms, vendor-hosted portals, and departmental tools that have no federation roadmap. Current guidance suggests two patterns: either wrap the app in stronger external controls, or retire it if the risk cannot be reduced enough.

There is no universal standard for this yet, but a few edge cases recur. Some apps support only local passwords, which means password vaulting and forced rotation become the main compensating control. Others allow partial federation for some roles but not privileged users, so admin paths need separate treatment. A third category is machine-facing applications that never had SSO in the first place; those should be reviewed as identity-bearing workloads, not as ordinary user apps. In all three cases, the question is not “can SSO be enabled?” but “what is the minimum control set that makes the access defensible?”

Teams should also be careful not to overcompensate with bureaucracy. If a low-risk tool is used occasionally and stores no sensitive data, a lightweight review cadence may be enough. If the tool handles regulated data or privileged actions, it needs stronger monitoring, tighter secret handling, and a clear offboarding process. In practice, the hardest failures show up when an application sits between “too important to remove” and “too weak to trust,” leaving security teams to govern it manually for years.

Related resources from NHI Mgmt Group

• How should teams implement RBAC in React applications without letting frontend checks become the security boundary?
• How should security teams implement Postgres RLS in multi-tenant applications without relying on it as the only control?
• How should security teams prioritize hidden identity risks in applications that bypass central identity controls?
• How should security teams handle password entropy disclosures in demos or recorded walkthroughs?