SaaS access governance is failing beyond SSO coverage

At a glance

What this is: This analysis shows how SaaS usage is outpacing IT visibility, leaving shadow IT, poor offboarding, and weak app control outside traditional SSO governance.

Why it matters: It matters because IAM teams must govern app access, lifecycle, and OAuth exposure across SaaS, NHI, and human identity programmes, not only within federated apps.

By the numbers:

• 52% of employees have downloaded applications without IT’s approval.
• On average, 34% of a company’s apps are not protected by SSO.

👉 Read 1Password’s analysis of the Access-Trust Gap in SaaS governance

Context

SaaS governance is the discipline of discovering, approving, and removing access across cloud applications. The problem is that many enterprises still treat SSO as if it were complete coverage, even though large parts of the application estate sit outside federation and therefore outside routine control. This makes the primary keyword here, SaaS access governance, a lifecycle problem as much as an authentication one.

When apps are created faster than they are inventoried, access reviews become partial and offboarding becomes inconsistent. That creates a structural gap between what security teams think is managed and what employees actually use, which is why shadow IT has become a governance issue rather than just an IT hygiene issue.

Key questions

Q: How should security teams govern SaaS apps that sit outside SSO?

A: Security teams should treat non-SSO apps as governed assets, not exceptions. That means discovering them continuously, assigning ownership, reviewing their access paths, and defining revocation steps for both human accounts and delegated tokens. If a SaaS app cannot be federated, it still needs lifecycle controls that are as explicit as any core enterprise application.

Q: Why do unmanaged SaaS apps create access risk even when SSO is in place?

A: Because SSO only governs the apps it covers. Employees can still use browser tools, local accounts, and OAuth-linked services outside federation, which leaves access invisible to standard identity reporting. The risk is not the absence of authentication, but the absence of complete lifecycle control over what users can actually reach.

Q: What should teams get wrong about offboarding in SaaS environments?

A: They often assume disabling the primary account is enough. In reality, offboarding must also remove app-specific accounts, revoke OAuth tokens, and confirm that shadow IT services do not retain access. If the app estate is only partially known, offboarding is partial by definition and leaves residual access behind.

Q: How do organisations know if SaaS governance is actually working?

A: They should look for high discovery coverage, low numbers of unmanaged apps, and complete revocation during offboarding. A working programme can show which apps are federated, which are not, and which third-party grants were removed. If those facts are unclear, governance exists on paper but not in practice.

Technical breakdown

Why SSO coverage does not equal SaaS governance

SSO centralises authentication, but it does not discover every app, enforce lifecycle control in every integration, or fix what happens outside federation. If a SaaS app is not routed through SSO, it can still be used, shared, and linked to company data through OAuth grants, local accounts, or vendor-specific access paths. The control failure is not SSO itself, but the assumption that SSO visibility equals full governance. In practice, that assumption breaks as soon as employees adopt apps faster than IT can classify them.

Practical implication: teams need continuous discovery and app classification, not only SSO enforcement.

How shadow IT creates lifecycle and offboarding gaps

Shadow IT expands the identity surface because access exists before governance does. An employee can onboard a new app through a browser or external workflow, create credentials, and accumulate business data access long before IT sees the service. Offboarding then becomes incomplete because revocation depends on knowing which apps exist, which identities were created, and which grants must be removed. This is a lifecycle failure across human access, SaaS permissions, and third-party app entitlements, not just a procurement problem.

Practical implication: offboarding processes must search for unmanaged app grants and non-federated accounts, not only disable directory access.

Why OAuth tokens and non-SSO apps widen the trust gap

OAuth can make SaaS adoption easier, but delegated access also creates persistence if tokens are not reviewed or revoked. Non-SSO apps often rely on local credentials, vendor-specific permissions, or third-party app connections that sit outside standard IAM reporting. That means the true trust boundary is broader than the identity provider. Governance needs to account for where access is exercised, not only where it is authenticated, because token-based access can survive directory cleanup and continue to expose company resources.

Practical implication: add token review and third-party app revocation into routine access governance.

NHI Mgmt Group analysis

SaaS access governance fails when discovery is treated as optional. The article shows that employees can add applications faster than IT can inventory them, which means governance starts after exposure has already occurred. That is not a visibility nuisance, it is a control boundary failure. Practitioners should treat unmanaged app discovery as the prerequisite for every downstream access decision.

SSO is a control plane, not a complete trust model. The report makes clear that many apps still sit outside federation, while others expose permissions through OAuth or vendor-specific account paths. Once access can exist outside the directory, the IAM programme no longer has a single source of truth. The practical conclusion is that federation coverage must be measured as a percentage of the app estate, not assumed from directory adoption.

Lifecycle failure is the real risk multiplier in SaaS environments. Offboarding, access reviews, and approvals all weaken when the app is unmanaged or the account lives outside SSO. This is the same governance problem that appears in NHI estates when secrets or tokens are never fully traced to their owning workflow. The implication for security teams is that lifecycle controls must extend to every app, not only the sanctioned core.

OAuth token revocation is becoming a first-class identity control. The article highlights a trust gap that lives in third-party app connections as much as in user sessions. Once tokens grant standing access, traditional directory cleanup may leave the effective path open. Practitioners should view token governance as part of access lifecycle, not as an edge-case cleanup task.

Shadow IT is now an IAM design input, not an exception case. If more than half of employees can adopt apps without approval, then the IAM programme must assume that unsanctioned services will exist at scale. That changes how recertification, offboarding, and privilege reporting are built. Security teams should design for unmanaged app sprawl as the default operating condition, not a rare deviation.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• That pattern reinforces why teams should pair SaaS discovery with the NHI Lifecycle Management Guide when access paths extend beyond SSO.

What this signals

Shadow app sprawl is now a governance baseline, not an edge case. If employees can approve their own tooling faster than central teams can inventory it, then IAM and SaaS management must operate as a discovery-led programme. The operational shift is to assume that some access will live outside the directory and to measure how quickly it is found, classified, and contained.

The strongest near-term control signal is not just whether SSO exists, but whether offboarding and revocation still work when a service is outside federation. Teams that cannot answer that question should expect residual access to survive employee exits, app changes, and vendor integrations.

For teams aligning identity work to framework language, this problem maps cleanly to NIST Cybersecurity Framework 2.0 governance and protect functions, because visibility without lifecycle enforcement leaves the identity programme structurally incomplete.

For practitioners

• Build continuous SaaS discovery into the access stack Continuously inventory browser-based and locally hosted apps, then classify which ones are federated, which ones use local credentials, and which ones are unmanaged. Use the inventory to drive remediation queues instead of relying on annual audits.
• Measure SSO coverage as a governance metric Track the percentage of apps protected by SSO, but also separate out non-federated apps that still hold business data or third-party integrations. Use the metric to prioritise high-risk app classes for migration or restriction.
• Extend offboarding beyond the directory When an employee leaves, revoke access in SaaS apps, remove OAuth grants, and validate that local app accounts no longer exist. Do not stop at disabling the primary identity provider account.
• Treat OAuth grants as revocable entitlements Review third-party app permissions on a recurring basis and remove tokens that no longer map to an approved business need. Keep the revocation path inside access governance rather than leaving it to application owners alone.
• Fold unmanaged apps into access reviews Include shadow IT and non-SSO apps in certification cycles so reviewers assess actual usage, not only directory records. Where ownership is unclear, mark the app for containment or retirement rather than deferring the decision.

Key takeaways

• SaaS governance breaks when discovery lags adoption, because access can exist before IT knows the app exists.
• SSO coverage is only part of the control picture, and non-SSO apps, OAuth tokens, and local accounts still need lifecycle management.
• Security teams should treat unmanaged apps as governed assets, then prove that offboarding, revocation, and access review work outside federation.

Key terms

• Shadow It: Software and services used inside an organisation without formal IT approval or visibility. In SaaS environments, shadow IT becomes an identity problem when users create accounts, share data, and grant access before governance teams know the app exists.
• Sso Coverage: The portion of an application estate that is protected by single sign-on. High SSO coverage helps centralise authentication, but it does not by itself prove that all apps, accounts, and delegated permissions are visible, owned, or revocable.
• OAuth Token: A delegated access credential that allows one application to act on behalf of a user or service within another system. In governance terms, it can preserve access even after the primary account is changed, making token review and revocation part of lifecycle control.
• SaaS Offboarding: The process of removing a user’s access from cloud applications when their role ends or changes. Effective offboarding goes beyond disabling the directory account and includes SaaS logins, local app accounts, linked integrations, and any third-party grants.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Password: Access-Trust Gap research on SaaS governance and lifecycle control. Read the original.