Security teams should treat SSO as one control layer, not the full access strategy. The practical move is to inventory unmanaged SaaS, assess which apps carry real business value, and then bring high-risk or high-value apps under governance through complementary controls. That usually means application discovery, usage review, and risk-based management rather than trying to force every app behind SSO.
When SSO Is Not an Option, What Should Own the Access Decision?
SSO is a strong control, but it is not a universal prerequisite for managing access. When an application cannot be integrated, the security team should decide whether the app is still worth supporting, what data it touches, and whether the business can accept the extra control burden. The answer should drive governance, not the other way around.
That is why an app that sits outside SSO needs a named owner, an explicit access method, and a periodic review path. If the application is low value and high friction, retirement is often the right outcome. If it is business-critical, the team should treat the exception as a governance problem, not a technical quirk.
For apps that still need to exist, security teams should document the access model in the same way they would document any other identity control boundary. That means defining who approves access, how accounts are created and removed, what logs exist, and how the team will detect abandoned accounts or shared credentials. The IAM and Identity Provider Buyer's Guide is useful here because the control decision is often about choosing the right identity architecture, not simply adding another login method.
Which Compensating Controls Matter Most for Unmanaged SaaS?
The right compensating controls depend on the app's risk profile, but the usual priorities are clear: inventory, governance, access review, and credential discipline. If the app cannot join SSO, teams should still centralise visibility over who uses it, whether it holds sensitive information, and whether there are service or delegated accounts that can outlive their business purpose. That is especially important where tokens or API-based access can bypass the normal employee login path.
Discovery matters because unmanaged SaaS tends to spread quietly through self-service procurement and team-level buying. Where the app is truly important, map it into the identity lifecycle you already operate for other systems, even if the login path stays separate. The Workforce Identity Security Guide helps frame the lifecycle and recovery issues that still exist when SSO is absent.
Security teams should also look at whether the application exposes reusable secrets, external integrations, or broad API access. In many real cases the immediate risk is not the interactive login itself, but the extra tokens, connector accounts, or recovery paths created to make the app usable. The Salesloft OAuth token breach is a reminder that non-SSO access paths can become the real trust boundary.
How Do You Decide Whether to Keep, Replace, or Retire the App?
The decision should be risk based, not convenience based. If the app is low value, duplicates another service, or cannot meet basic governance requirements, the cleanest answer is usually replacement or retirement. If it is strategically important, the team should decide whether a different product, a federation-capable upgrade, or a managed wrapper can reduce the exception burden without forcing a brittle integration.
That decision is easier when security, procurement, and the business owner compare the app's value against the operational cost of keeping it off the standard access plane. If the app handles regulated data, supports privileged workflows, or has meaningful downstream integrations, a non-SSO exception should be treated as a high-friction exception with a sunset plan. The Identity Provider and SSO Security Guide is the right reference point for the control baseline you are trying to preserve.
When replacement is not practical, the fallback should still be intentional: limit access, review it often, and make offboarding reliable. Avoid the common mistake of letting a legacy login method become permanent simply because it was once tolerated. A temporary exception without a review date usually turns into an unmanaged entitlement.
Risk and Threat Considerations
Applications outside SSO usually create weaker visibility and more inconsistent lifecycle control. The main risk is not just convenience drift, but shadow access that survives staff changes, contractor departures, or team restructuring. If the app also uses separate credentials, recovery emails, or third-party tokens, the attack surface becomes broader than the login page suggests.
Failure mechanism: Accounts and secrets drift outside central governance, then remain active after ownership changes, incomplete offboarding, or unsupervised integration setup.
Impact: Unauthorized access can persist longer, access reviews become incomplete, and a compromise can be harder to detect or contain because the app is not covered by the normal SSO control plane.
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, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Non-SSO apps still need controlled account creation, review, and removal. |
| IA-5 — Authenticator Management | Separate apps often rely on passwords, tokens, or shared secrets that need lifecycle control. | |
| AU-2 — Event Logging | Unmanaged applications need logging so access and abuse can still be detected. | |
| Recommendation — Define owners, review cycles, and removal triggers for every exception account. Track, rotate, and revoke any secrets used outside the SSO path. Require usable audit logs before accepting a non-SSO access exception. | ||
| CIS Controls v8 | CIS-5 — Account Management | CIS emphasizes managing accounts and exceptions where central SSO is absent. |
| Recommendation — Inventory and review accounts for every application that bypasses SSO. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | App discovery and inventory are central to finding SaaS that bypasses SSO. |
| Recommendation — Maintain a complete inventory of apps that sit outside SSO. | ||
Practitioner Guidance
What to prioritise: Start with the applications that combine business importance, sensitive data, and non-SSO access. Those are the ones that justify compensating controls and a formal exception process.
What to verify: Confirm that every non-SSO app has an owner, an access review cadence, an offboarding process, and a record of any tokens, shared accounts, or external connectors that can reach it.
Decision rule: If the app cannot meet basic governance requirements and does not have clear business criticality, retire or replace it rather than building a permanent exception path.
Practitioner takeaway: The goal is not to force every application into SSO, it is to make sure every exception is visible, owned, reviewed, and proportionate to the business value it protects.
Related resources from NHI Mgmt Group
- How should security teams handle SaaS applications that gate SSO behind premium tiers?
- How should security teams handle legacy header-based applications that do not support modern SSO protocols?
- How should security teams handle OAuth tokens in multi-API applications?
- How should security teams handle secrets in frontend applications?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org