SaaS governance is now an identity and control problem

At a glance

What this is: This is a SaaS management overview arguing that effective control requires visibility into ownership, usage, cost, security, and compliance across the application estate.

Why it matters: It matters because SaaS sprawl affects human access, third-party risk, lifecycle offboarding, and control of non-human identities that often sit behind modern business applications.

By the numbers:

• 38% of companies operate almost entirely on SaaS.
• 51% use SaaS applications in most of their business.

👉 Read Efecte's article on six steps for successful SaaS management

Context

SaaS management is the discipline of finding, governing, and reducing risk across the application stack that now carries day-to-day business work. The identity issue is not just whether people can log in, but who owns each app, which accounts persist after employees leave, and where access and data handling sit outside normal governance.

The article’s core message is that SaaS programmes fail when teams treat apps as isolated subscriptions instead of an identity surface with security, lifecycle, and compliance consequences. That is a familiar problem in NHI-heavy environments as well, where shadow access, offboarding gaps, and fragmented ownership create control debt across the enterprise.

Key questions

Q: How should organisations govern SaaS applications as part of identity management?

A: They should treat SaaS as an identity-governed application layer, not just a spend category. That means naming owners, tracking active users, reviewing access regularly, and tying offboarding to actual application usage. The goal is to stop unmanaged access from surviving beyond the business need and to make every SaaS app answerable to a clear control owner.

Q: Why do SaaS sprawl and duplicate tools increase security risk?

A: Because every additional app creates another place where access, data handling, and offboarding can fail. Duplicate tools also fragment ownership, which makes it harder to know which accounts are still active and which integrations should be removed. The result is more shadow access, more review burden, and a higher chance of persistent entitlements.

Q: What breaks when SaaS offboarding is not tied to lifecycle controls?

A: Former employees, contractors, and project users can retain access long after they should have been removed. In practice, that means shared logins, dormant accounts, and connected services keep working outside policy. Offboarding only works when the business can identify every application, every account, and every linked integration that needs to be closed down.

Q: Who should be accountable for SaaS governance decisions?

A: Accountability should sit with both the business owner and the technical control owner. The business owns the need for the app, while identity, security, and compliance teams own the rules for access, data handling, and review. Without that split, SaaS becomes a shared-risk blind spot that no one is able to remediate end to end.

Technical breakdown

Why SaaS visibility is an identity control problem

SaaS visibility is not just inventory work. It is the process of linking applications to accountable owners, active users, spending, data location, and access scope so that governance can be applied consistently. Without that mapping, the organisation cannot tell whether an app is business-critical, duplicated, unmanaged, or still carrying access for former staff. That is why visibility sits upstream of both IAM and lifecycle control. Practical implication: establish a live application register that ties each SaaS app to owner, purpose, data class, and access model.

Practical implication: establish a live application register that ties each SaaS app to owner, purpose, data class, and access model.

How SaaS sprawl creates access and offboarding drift

SaaS sprawl appears when teams adopt tools faster than governance can track them. The result is duplicate functionality, unmanaged trial accounts, shared logins, and users who retain access after they no longer need it. In identity terms, the problem is lifecycle drift: joiner, mover, and leaver processes stop matching the actual application estate. That produces persistent entitlements and weak accountability, especially when apps are bought outside central procurement. Practical implication: integrate SaaS discovery into access review and offboarding workflows so dormant and orphaned access can be removed.

Practical implication: integrate SaaS discovery into access review and offboarding workflows so dormant and orphaned access can be removed.

What SaaS governance means for data, compliance, and shadow apps

Every SaaS app creates a data-handling decision, even when the business treats it as a simple productivity tool. Teams need to know where data is stored, which jurisdictions apply, whether the vendor meets policy requirements, and whether unmanaged apps are processing regulated information. Shadow apps are especially risky because they often bypass standard review, logging, and retention controls. Compliance issues then emerge after deployment rather than before it. Practical implication: require security and privacy review before adoption, and block unapproved SaaS paths from handling regulated data.

Practical implication: require security and privacy review before adoption, and block unapproved SaaS paths from handling regulated data.

NHI Mgmt Group analysis

SaaS governance is an identity lifecycle problem before it is a cost problem. The article focuses on spend, duplication, and ownership, but the deeper failure mode is that SaaS tools outgrow the joiner-mover-leaver process that is supposed to keep access bounded. Once app adoption outruns offboarding and recertification, access persists because no one owns the lifecycle. Practitioners should treat SaaS as part of identity governance, not as a separate procurement list.

Shadow SaaS behaves like shadow identity infrastructure. Unmanaged SaaS apps create accounts, tokens, and delegated access paths outside central visibility, which means the organisation loses control over who can act, where data goes, and when access should end. That is the same governance pattern seen in unmanaged machine access, just with a human-facing front end. The implication is that discovery and owner assignment must be mandatory, not optional.

Vendor consolidation and feature sprawl increase control debt. The article rightly notes that changes in vendors, features, and user counts affect cost, but the security consequence is that teams inherit more access paths than they can accurately review. Each extra app or overlapping feature set adds another place where entitlement, data residency, and offboarding can fail. Practitioners should expect governance overhead to rise faster than app count unless standards are imposed.

Zero Trust only works when the SaaS layer is governed as an enforceable boundary. SaaS is often treated as a trusted business layer, yet the article shows it contains unmanaged users, third-party services, and compliance exposure. That breaks the assumption that application access can be left to local convenience. The implication is that SaaS must be brought into the same access, review, and policy framework as the rest of the identity estate.

Application sprawl creates NHI exposure by proxy. Even when the article is written in SaaS terms, many of the hidden risks are non-human identities behind the scenes, including service integrations, API tokens, and connected accounts. Once those identities are not tracked alongside the app they support, revocation becomes unreliable and persistence becomes normal. Practitioners should govern the app and its machine identities as one control surface.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows that policy confidence and operational behaviour often diverge.
• For a broader lifecycle view, see Salesloft OAuth token breach for how delegated access can persist beyond the intended control boundary.

What this signals

Application sprawl will keep turning into identity sprawl. As SaaS estates expand, teams will need to manage the app, the user, and the connected account as one control surface rather than three separate problems. That is especially true where local app ownership hides machine credentials, tokens, or delegated access paths that no one reviews until after a failure.

The governance signal is clear: discovery without lifecycle enforcement only creates a better inventory of unmanaged risk. If your programme cannot connect SaaS adoption to access review, offboarding, and policy enforcement, it will not materially reduce exposure even when the dashboard looks complete.

With 32.4% of security budgets dedicated to secrets management and code security in our research, the underlying message is that control depth matters more than tool count. The same logic applies to SaaS governance: the organisations that win are the ones that can connect visibility to enforcement, not the ones with the longest software list.

For practitioners

• Build a live SaaS application register Track every approved app with business owner, technical owner, user population, data class, and review date so governance does not depend on informal knowledge.
• Fold SaaS discovery into offboarding Use access reviews and leaver processes to find accounts, tokens, and linked services that survive after employees move roles or leave the organisation.
• Set review gates before new app adoption Require security, privacy, and compliance review before any SaaS app handles business data, especially where regulated information or external sharing is involved.
• Rationalise duplicate applications Compare overlapping tools by actual usage, business criticality, and access scope, then retire redundant apps that create extra entitlement and data risk.

Key takeaways

• SaaS management fails when ownership, access, and offboarding are treated as separate disciplines rather than one identity governance process.
• The biggest risk is not only overspend, but persistent access, unmanaged integrations, and shadow applications that outlive business need.
• Teams should respond by building an authoritative SaaS register, tying reviews to lifecycle events, and blocking unapproved apps from handling regulated data.

Key terms

• SaaS governance: SaaS governance is the set of controls used to approve, track, review, and retire software as a service applications. It brings together ownership, access management, data handling, compliance, and lifecycle oversight so that app sprawl does not become unmanaged identity and security risk.
• Shadow SaaS: Shadow SaaS is SaaS software used outside approved processes or without central visibility. It often appears through departmental purchasing or trial adoption, then creates hidden access paths, data exposure, and offboarding gaps because security, privacy, and identity teams never had the chance to govern it.
• Application lifecycle control: Application lifecycle control is the practice of managing an application from adoption through review and retirement. In SaaS environments, it ensures ownership, user access, data handling, and decommissioning stay aligned with business need rather than lingering as informal or forgotten entitlements.
• Delegated access: Delegated access is permission granted to an application, integration, or account to act on behalf of a user or service. In SaaS, it becomes risky when the delegation is not tracked, reviewed, or revoked, because the access path can continue even after the original business purpose has ended.

What's in the full article

Efecte's full article covers the operational detail this post intentionally leaves for the source:

• Practical guidance on how to assign ownership for SaaS renewals, licenses, and budgets across teams
• A step-by-step view of how to build user-level application portfolios and collect usage feedback
• Detailed checks for SaaS security, including data storage, password practices, account sharing, and offboarding
• Compliance considerations for GDPR, vendor approval, and the handling of managed versus unmanaged applications

👉 The full Efecte article covers ownership, cost visibility, security checks, and compliance controls for SaaS environments.

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.