How should teams handle SaaS apps that are not covered by SSO?

How to govern non-SSO SaaS without losing control

Non-SSO apps should be handled as a governed access population with explicit ownership, not as informal one-offs. The practical question is not whether they are “less secure” by definition, but whether the organisation can still prove who approved access, who receives it, and when it is removed. That is the control boundary you need to restore.

The first step is to define a separate intake and approval path for any app that cannot participate in federation. That path should include a named business owner, a technical owner, and a review cadence, because unmanaged SaaS often becomes invisible after initial purchase. Treating it this way keeps the app inside the access governance model even when SSO is unavailable.

For discovery and coverage, the important distinction is between federation coverage and application inventory. An app may sit outside SSO and still be acceptable if provisioning, review, and revocation are controlled. The risk begins when teams confuse “not federated” with “not important enough to govern.” In practice, a clean exception process is safer than a silent gap.

What changes when the app sits outside the federation layer?

Once an app is outside SSO, every lifecycle action becomes more fragmented. Joiner-mover-leaver handling, entitlement review, and removal of stale access must happen through the app or its surrounding admin process rather than through a central identity flow. That makes evidence quality more important, because the organisation has to reconstruct the access decision from local records.

This is also where hidden drift shows up. A non-SSO app can remain in production long after the original justification has expired, especially if it was adopted by one team and then spread laterally. If access is granted through local accounts, shared admin logins, or manual exports, the application can keep functioning while governance slowly disappears.

Where possible, teams should reduce the number of true exceptions by aligning the app to a compensating control set: strong provisioning controls, regular recertification, and documented offboarding. If an app cannot support those controls, it should be treated as a higher-risk service until a replacement or integration path is available. See the broader access governance patterns in Workforce Identity Security Guide and the platform selection trade-offs in IAM and Identity Provider Buyer's Guide.

How to keep the exception controlled in practice

The goal is not to force every SaaS app into SSO, but to make the exception operationally expensive enough that it stays visible. Use a documented exception register, require periodic owner attestation, and make removal part of the same process that approved the exception in the first place. If the app supports SCIM, API-based provisioning, or other lifecycle hooks, use them to narrow the gap even when login itself is not federated.

For technical teams, the best control pattern is usually to separate authentication from governance. If the app cannot accept SSO, you can still govern who is allowed to exist in the tenant, who can administer it, and how privileged functions are reviewed. That keeps the app from becoming a blind spot while you work toward retirement, migration, or eventual federation.

When teams want a concrete external reference for federation and token-based login boundaries, OpenID Connect Core 1.0 is the clearest baseline for what the SSO path does and does not cover. For organisations that need to justify the exception process inside a broader control catalogue, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the access-control and audit-control framing that makes non-SSO governance auditable.

Risk and Threat Considerations

Non-SSO SaaS becomes risky when the organisation loses lifecycle visibility rather than when it merely lacks federation. The real exposure is orphaned access, stale admin rights, and inconsistent offboarding, all of which can persist because the app sits outside the normal identity monitoring path. Over time, that creates a second access estate that security teams see only partially.

Failure mechanism: Access is granted and removed through local or manual processes, so revocation is delayed, forgotten, or impossible to prove. Shared accounts, local admins, and exported user lists make it easier for attackers or former users to retain access after the business believes it has been removed.

Impact: The organisation gets incomplete onboarding coverage, incomplete deprovisioning, and weaker accountability for privileged actions. That increases the chance of unauthorised access, audit gaps, and unresolved exposure when a SaaS tenant is misused or compromised.

Practitioner Guidance

What to prioritise: Classify every non-SSO SaaS app by business criticality and access sensitivity before trying to remediate the tooling gap. A low-value tool can sit in a lighter process, but anything that stores customer data, administrative content, or privileged workflow access needs named ownership and a reviewable lifecycle.

What to verify: Confirm that each exception has a documented owner, a provisioning method, a deprovisioning method, and a review date. If you cannot produce evidence of those four items, the app is effectively unmanaged even if it is known to the IT team.

Practitioner takeaway: The key decision is whether the app can be governed as part of the identity lifecycle, not whether it supports SSO on day one. If it cannot, treat it as a controlled exception with explicit expiry and evidence, not as an unowned convenience app.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should teams handle secrets that have no obvious owner?
• How should security teams handle local accounts in cloud and SaaS apps?
• How should IAM teams govern provisioning across HR, SSO, and SaaS apps?