SaaS management is now an identity governance problem

At a glance

What this is: This is Efecte's view that SaaS management has become an identity governance issue because organisations need visibility into users, accounts, spend, and offboarding across an expanding app estate.

Why it matters: It matters because IAM, IGA, and SaaS governance teams now have to control who uses each app, why they use it, and what happens when users or vendors leave.

Context

SaaS management is no longer just a procurement or spend topic. As organisations move more of their operations into SaaS, the governance question shifts to identity, entitlement, and accountability across a fast-growing application estate.

The central failure mode is visibility. If teams cannot reliably identify who is using which application, who owns renewals and budgets, and whether accounts are still active after offboarding, the SaaS estate becomes a governance gap rather than a simple software portfolio problem.

That makes the article relevant to both human IAM and non-human governance where SaaS access is shared, delegated, or unmanaged. The article's starting point is typical: SaaS growth outpaces the controls that were designed for smaller, more static application landscapes.

Key questions

Q: What breaks when SaaS licenses are managed only as a cost-control exercise?

A: Access ownership becomes opaque, dormant accounts remain assigned, and service accounts can keep consuming entitlements without a clear business need. That creates a governance gap because the organisation may reduce spend without proving that access was removed, reviewed, or reassigned correctly.

Q: Why does shared SaaS access create both billing and security risk?

A: A shared login breaks the link between the user, the entitlement, and the paid seat, so usage data no longer supports accurate billing or accountable access. The same gap also weakens auditability because logs can show activity, but not reliably show who the real operator was. That is why the issue sits across IAM and revenue governance.

Q: Who should own unmanaged SaaS applications?

A: Unmanaged SaaS applications should be brought under explicit business and technical ownership as soon as they are discovered. Without ownership, there is no reliable way to review access, manage spend, or decide whether the app should stay in use. Accountability is the control that turns discovery into governance.

Q: When should teams prioritise SaaS access review over app rationalisation?

A: Teams should prioritise access review when they cannot answer who uses each app, when shared accounts exist, or when offboarding is inconsistent. Rationalisation still matters, but access review is the first control that restores accountability and shows where the real governance gaps sit.

Technical breakdown

Why SaaS governance becomes an identity problem

SaaS governance becomes an identity problem when application usage, access, and accountability are spread across departments without a stable ownership model. The operational data you need is not just spend or app inventory, but who can access what, under which business purpose, and whether that access still matches the user's role. In practice, SaaS sprawl turns access governance into the only reliable way to understand the application estate.

Practical implication: Treat SaaS management as an identity and entitlement inventory problem, not only a financial one.

Why shared accounts and offboarding gaps matter

Shared accounts and weak offboarding are risky because they break the link between an identity and its actions. When users share passwords or retain access after leaving, auditability collapses and the organisation loses the ability to prove who used a SaaS service at a given point in time. That is an IAM failure, but it also becomes a SaaS governance failure because consumption, ownership, and liability can no longer be reconciled cleanly.

Practical implication: Eliminate shared SaaS accounts where possible and tie offboarding to access revocation, not just HR exit workflows.

How unmanaged applications complicate control

Managed versus unmanaged SaaS usage creates two different control planes. Managed apps can be governed through procurement, SSO, lifecycle, and recertification processes. Unmanaged apps sit outside those controls, so security teams lose visibility into authentication methods, data handling, and vendor exposure. The result is a shadow access layer that often persists because the business adopted the tool faster than governance adapted.

Practical implication: Build a control path for unmanaged SaaS discovery, owner assignment, and access review before the shadow estate grows further.

NHI Mgmt Group analysis

SaaS management is now an identity governance discipline: once software use becomes distributed across the business, the governance problem is no longer just license optimisation. It becomes a question of identity accountability, entitlement ownership, and lifecycle control across every application the enterprise depends on. Practitioners should treat SaaS management as part of IAM and IGA, not as a separate admin function.

Visibility without identity context is insufficient: counting applications or subscriptions does not answer who can use them, who approved them, or whether access still matches business need. That gap matters because unmanaged access is where governance breaks first, especially when users self-provision tools outside formal approval paths. The practical conclusion is that SaaS estates need identity-linked ownership, not just inventory data.

Shared access is a governance debt, not a convenience: when employees share accounts, the organisation loses non-repudiation, lifecycle precision, and reliable offboarding. That pattern is especially damaging in SaaS because browser-based access and federated login can make informal sharing look operationally harmless until an incident or audit exposes it. Teams should treat shared SaaS credentials as a control failure, not a user preference.

Compatibility and admission processes define the boundary of control: as SaaS footprints expand across regions and regulations, the key question becomes which apps are admitted, by whom, and under what data and identity requirements. The strongest programmes connect SaaS admission to policy, ownership, and review cadence rather than letting usage grow first and governance catch up later. Practitioners should harden the intake boundary before unmanaged adoption becomes normal.

Ephemeral SaaS accountability must be designed deliberately: the article points to a broader trend where access, usage, and vendor dependencies change faster than traditional review cycles. That means governance programmes need a named owner for each application, a clear offboarding trigger, and a repeatable way to reconcile access with business purpose. The implication is straightforward: without identity-led SaaS governance, operational sprawl becomes structural risk.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

What this signals

Identity-led SaaS governance is becoming the default control model: the practical boundary is no longer the software catalogue alone but the relationship between each app, its owner, and the identities that use it. Only 5.7% of organisations have full visibility into their service accounts. That visibility gap is a warning sign for SaaS programmes that still separate application management from identity governance.

SaaS admission is the new control point: once employees can adopt tools faster than review cycles can track them, governance has to move upstream to intake, ownership, and entitlement assignment. The organisations that keep control will be the ones that make every new application pass through an identity and accountability checkpoint before it becomes normalised.

Offboarding now needs application context as well as user context: removing a user from one system does not solve the problem if shadow apps, shared credentials, or delegated vendor access remain outside the lifecycle process. Practitioners should expect SaaS governance to converge with access governance, because the boundary between them is already gone.

For practitioners

• Map SaaS ownership to named business and IT roles Assign clear responsibility for renewals, licenses, budgets, and access decisions so each application has an accountable owner.
• Inventory who uses each SaaS application Capture user-level access and business purpose for every major SaaS tool, then review whether each account still matches an active use case.
• Review shared accounts and offboarding paths Find applications where passwords are shared or access survives employee exit, then align revocation with offboarding so stale access is removed promptly.
• Track SaaS spend, duplication, and unused capability Compare subscription usage against business demand to identify overlap, under-used features, and services that can be removed or consolidated.
• Control unmanaged app admission Define a process for discovering, approving, and assigning owners to unmanaged SaaS tools before they spread across departments.

Key takeaways

• SaaS management now reaches beyond procurement because identity, access, and ownership determine whether the application estate is actually governable.
• The article's core warning is that visibility, shared accounts, and unmanaged adoption break accountability faster than traditional SaaS administration can correct it.
• Practitioners should anchor SaaS governance in named ownership, user-level access review, and offboarding-linked revocation before sprawl becomes structural risk.

Key terms

• SaaS Lifecycle Governance: SaaS lifecycle governance is the set of controls that manage applications from onboarding through access assignment, renewal, and decommissioning. It matters because the security value of SaaS management depends on whether the organisation can prove ownership, revoke access, and retire unused tools on demand.
• Managed versus unmanaged SaaS: Managed SaaS sits inside formal procurement, identity, and review processes, while unmanaged SaaS is adopted outside those controls. The distinction matters because unmanaged tools often lack clear ownership, consistent offboarding, and visibility into access or data handling.
• Shared Account Risk: The security and accountability problem created when multiple people use the same login or credential. Shared accounts weaken traceability, complicate offboarding, and make it difficult to prove who performed an action inside a SaaS application.
• Offboarding Revocation Window: The time between a user or workflow no longer needing access and that access being fully removed across relevant systems. Longer windows increase the chance that obsolete credentials, sessions, or delegated rights can be reused during or after departure.

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 building or maturing an IAM programme, it is worth exploring.