TL;DR: Enterprise SaaS is expanding toward 85% of software spend, while shadow IT already accounts for 29% of IT security concerns, according to JumpCloud. The practical shift is that SaaS management now functions as identity governance for apps, accounts, and access, not just license cleanup.
At a glance
What this is: This is a SaaS management guide that argues discovery, access control, and lifecycle handling now sit inside identity governance.
Why it matters: It matters because IAM, NHI, and human identity teams increasingly manage the same sprawl problem through different control planes, and weak SaaS visibility quickly becomes an access and compliance issue.
By the numbers:
- SaaS adoption is at an all-time high, with almost 85% of all enterprise software expected to be SaaS applications.
- Shadow IT accounts for 29% of IT security concerns.
👉 Read JumpCloud's guide to the best SaaS management platforms for IT teams
Context
SaaS management is the practice of discovering which applications are actually in use, matching them to the right users, and controlling access and spend. As enterprises move toward SaaS-first operating models, the governance gap is no longer about whether apps exist, but whether IT can see them, control them, and retire them cleanly.
For identity teams, the issue is broader than software inventory. SaaS sprawl creates overlapping problems in human access, third-party OAuth connections, and service-like accounts tied to business workflows. JumpCloud's guide frames the category as a control layer for discovery, access enforcement, and lifecycle management, which is why it belongs in IAM conversations rather than being treated as a procurement-only tool choice.
Key questions
Q: How should security teams govern SaaS apps that employees adopt outside IT approval?
A: Start by treating SaaS adoption as an identity event, not just an application event. Discover the app, identify the owning account, decide whether it should remain approved, and then enforce the decision with policy. If IT can only see the app after procurement or audit, the governance model is already too late.
Q: Why do SaaS sprawl and shadow IT create identity risk?
A: Because every unsanctioned app can introduce an unsanctioned account, OAuth grant, or personal login path. Those access paths often sit outside normal review cycles, which means credentials and delegated permissions can persist long after the original business need has disappeared.
Q: How can teams tell whether SaaS access control is actually working?
A: Look for evidence that unapproved apps are being detected, personal accounts are being flagged, and former-employee access is being removed during offboarding. If the platform only reports usage and never changes access state, it is informing governance rather than enforcing it.
Q: What is the difference between SaaS management and IAM?
A: IAM governs identities and access decisions across systems, while SaaS management focuses on discovering, governing, and optimising cloud applications in use. In practice, the two overlap when SaaS platforms enforce app access, tie accounts to identities, and support lifecycle controls.
Technical breakdown
How SaaS discovery methods expose hidden access paths
SaaS discovery is only useful when it reaches beyond manual inventories. Browser extensions, desktop agents, native connectors, SSO telemetry, and OAuth monitoring each surface a different slice of usage. That matters because many apps are adopted outside formal procurement channels, while others are created through identity-provider integrations that never appear in finance records. A strong discovery layer turns app sprawl into an identity problem: who created access, which account owns it, and whether the app is still authorised. Practical implication: map every discovery source to a control owner so unidentified apps do not fall between IT, IAM, and security workflows.
Practical implication: map every discovery source to a control owner so unidentified apps do not fall between IT, IAM, and security workflows.
Why SaaS access control is an identity governance problem
Once a SaaS app is visible, the next question is whether access should exist at all. The guide emphasises warnings and blocking for risky or unapproved apps, which makes SaaS management more than passive reporting. Access control here depends on identity context, including whether the user is an employee, whether the account is corporate or personal, and whether the application is tied to a sanctioned workflow. This is the same governance logic used in IAM and PAM, but applied to cloud apps rather than infrastructure or administrator sessions. Practical implication: align SaaS approval states with identity policy so access decisions can be enforced, not just reported.
Practical implication: align SaaS approval states with identity policy so access decisions can be enforced, not just reported.
What lifecycle management means for SaaS accounts and licences
SaaS lifecycle management covers provisioning, deprovisioning, licence reconciliation, and access revocation as users join, move, or leave. In practice, this is where SaaS management connects directly to identity governance because stale accounts and unused licences often persist after role changes or offboarding. The operational problem is not only cost waste, but retained access that no one actively owns. Platforms that match users to accounts and surface shadow, shared, or former-employee accounts reduce that gap by linking app administration to identity records. Practical implication: treat SaaS offboarding as part of the identity lifecycle, not as a separate application admin task.
Practical implication: treat SaaS offboarding as part of the identity lifecycle, not as a separate application admin task.
NHI Mgmt Group analysis
SaaS management is now a control plane problem, not a tooling niche. Once enterprises run most software through SaaS, discovery and access enforcement become core identity functions rather than optional optimisation layers. The guide shows that app visibility, user-account matching, and blocking logic sit on the same governance path as IAM. Practitioners should therefore treat SaaS management as part of the identity operating model, not a separate software category.
Shadow IT becomes an access governance failure before it becomes a spend issue. The article correctly places shadow app usage alongside security risk, because unmanaged apps often arrive with unmanaged identities attached. That means the real failure is not app adoption itself, but the absence of policy enforcement at the point of login or provisioning. The practical conclusion is that SaaS sprawl must be governed through identity context, not discovered only after audit.
Personal accounts and OAuth connections are the hidden edge of SaaS risk. The guide's emphasis on personal-account detection and OAuth visibility reflects where SaaS programmes often lose control of authentication and delegation. Those flows can bypass formal onboarding and create durable access paths that are hard to see in traditional inventory. Practitioners should read this as a signal that app governance now depends on identity telemetry, not just contract management.
Unified identity and SaaS management lowers friction, but only if governance remains explicit. A platform that connects devices, directories, and apps can improve visibility, yet that integration only helps when teams keep ownership clear across IT, IAM, and security. Otherwise, integrated tooling can hide accountability gaps behind convenience. The lesson for practitioners is to unify control planes without blending control responsibilities.
From our research:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- When SaaS management exposes personal accounts and OAuth grants, practitioners should extend the same lifecycle discipline described in NHI Lifecycle Management Guide to every delegated access path.
What this signals
Shadow access will keep outrunning inventory unless SaaS governance is tied to identity lifecycle controls. The practical signal is that discovery alone is insufficient when personal accounts, delegated app access, and former-employee identities can survive in the same estate. Teams should expect more pressure to connect SaaS administration to joiner-mover-leaver processes and to treat app approval as an access decision, not a procurement checkbox.
Identity teams should expect SaaS management to merge further with directory, device, and policy enforcement workflows. That convergence is already visible in products that combine app discovery with user-account matching and blocking. The risk is role confusion, so practitioners need clear ownership boundaries even when tooling is unified.
With only 1.5 out of 10 organisations highly confident in securing NHIs, the governance gap is larger than many SaaS programmes assume, and OAuth-connected apps are part of that same visibility problem. In practice, teams should use the discovery layer to prioritise which access paths deserve immediate review, not just which apps are cheapest to renew.
For practitioners
- Map discovery sources to one identity control owner Assign browser, connector, SSO, and OAuth discovery outputs to a named control owner so unidentified applications do not drift between IT, IAM, and security teams.
- Block personal-account access for sanctioned SaaS Detect non-corporate login patterns and force reauthentication or denial when users attempt to access approved applications with personal email addresses.
- Tie offboarding to SaaS account revocation Make deprovisioning a required step in joiner-mover-leaver workflows so former employees, shared accounts, and unused licences are removed together.
- Review OAuth grants as delegated access paths Inventory third-party app connections to identity providers and revoke grants that no longer support an approved business process.
Key takeaways
- SaaS management is becoming an identity governance function because app discovery, access control, and offboarding now affect the same risk surface.
- Shadow IT is an access problem first and a cost problem second, especially when personal accounts and OAuth grants bypass formal controls.
- Practitioners should connect SaaS discovery to lifecycle enforcement so visibility leads to revoked access, not just better reporting.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SaaS access enforcement maps directly to managed authorisation decisions. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | SaaS discovery and blocking support continuous verification of app access. |
| NIST SP 800-63 | Personal-account detection and federation depend on trustworthy identity signals. |
Use strong identity proofing and federation signals before granting SaaS access.
Key terms
- SaaS management: SaaS management is the practice of discovering, governing, and optimising cloud applications used across an organisation. It combines inventory, access oversight, licence control, and workflow enforcement so application adoption does not outrun identity governance.
- Shadow IT: Shadow IT is technology adopted without formal approval or visibility from central IT or security teams. In SaaS environments, it often appears as unauthorised applications, personal logins, or unsanctioned integrations that create hidden access and compliance risk.
- OAuth grant: An OAuth grant is a delegated authorisation that allows one application to act on behalf of a user or another system. In SaaS governance, grants can become persistent access paths that survive beyond the original business need unless they are reviewed and revoked.
- Joiner-mover-leaver process: A joiner-mover-leaver process manages identity changes when people enter, change roles, or leave an organisation. For SaaS environments, it should connect app provisioning and deprovisioning to account ownership so access is removed as part of lifecycle governance, not as an afterthought.
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 JumpCloud: best SaaS management platforms for IT teams. Read the original.
Published by the NHIMG editorial team on 2025-07-23.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org