By NHI Mgmt Group Editorial TeamPublished 2026-03-20Domain: Governance & RiskSource: Zluri

TL;DR: SaaS management centralises discovery, cost control, renewals, compliance, and security across expanding app portfolios, with Zluri arguing that unmanaged SaaS creates visibility gaps, shadow IT, sensitive-data exposure, and regulatory risk. The real governance issue is not app count alone, but ownership, lifecycle, and access sprawl across identities.


At a glance

What this is: This is a SaaS management guide that argues uncontrolled SaaS growth creates visibility, security, and compliance gaps for IT teams.

Why it matters: It matters because SaaS sprawl is really an identity governance problem, affecting human access, delegated app ownership, and the offboarding of non-human entitlements.

By the numbers:

👉 Read Zluri's guide to SaaS management, sprawl, and security risk


Context

SaaS management is the discipline of inventorying, governing, and continuously monitoring cloud applications so ownership, renewals, access, and risk do not drift out of control. In practice, the problem is identity sprawl: business teams create app and data access faster than IT can classify, review, or retire it.

Zluri frames the issue as operational scale, but the deeper identity question is who is accountable for access when applications, vendors, and users multiply faster than governance processes. That matters across human IAM, delegated SaaS ownership, and the non-human credentials that often sit behind integrations and automations.


Key questions

Q: How should security teams govern shadow SaaS apps that bypass IT approval?

A: Security teams should treat shadow SaaS as an identity and access exception, not just an inventory problem. The first step is to identify who owns the app, what data it reaches, and whether it connects through SSO, API keys, or delegated admin. If those answers are unclear, the app should not be allowed to persist in production.

Q: Why do unmanaged SaaS apps create IAM and compliance risk?

A: Unmanaged SaaS apps create risk because they sit outside the normal lifecycle controls that govern access, offboarding, and review. That means users can keep permissions, integrations can keep working, and data can keep flowing after the original business need has changed. Compliance suffers because accountability and evidence are fragmented across departments.

Q: What breaks when SaaS ownership is unclear?

A: When ownership is unclear, nobody can reliably answer who can approve access changes, who can retire the app, or who is responsible for its data. That leads to duplicate tools, missed renewals, stale access, and weaker incident response because the organisation cannot quickly identify the control owner.

Q: How do organisations reduce SaaS sprawl without slowing the business?

A: Organisations reduce SaaS sprawl by combining discovery, ownership assignment, and review cadence instead of using one-time clean-up projects. The goal is to make every app visible, every owner accountable, and every renewal decision evidence-based. That preserves agility while preventing hidden access paths from accumulating over time.


Technical breakdown

SaaS discovery is really identity discovery

SaaS discovery is not just an inventory exercise. It is the process of finding which applications exist, who owns them, which users and integrations can reach them, and what data they touch. The article describes discovery through ERP, SSO, HR, finance, contract, and direct app integrations because no single control plane sees the whole stack. The technical problem is that entitlement data is scattered across systems that update at different speeds, so ownership and usage become inconsistent very quickly.

Practical implication: build a unified discovery layer that reconciles app, user, and integration records before you attempt governance.

Why shadow IT creates access and data control failures

Shadow IT emerges when teams adopt software outside IT approval paths. That creates a second governance plane where security settings, data flows, and renewal decisions are made without standard review. In SaaS environments, this is dangerous because each application has its own configuration surface and permission model, and those models are often weaker than the enterprise IAM baseline. Once data enters an unmanaged app, downstream visibility and revocation become much harder.

Practical implication: treat unsanctioned SaaS as an access control exception, not only as a procurement or cost issue.

Why SaaS renewals and offboarding are lifecycle controls

The guide links SaaS risk to ownership, renewals, and revocation, which are lifecycle problems rather than one-time deployment issues. When renewals happen automatically or ownership is unclear, unused accounts and redundant subscriptions persist. That persistence extends the attack surface and wastes budget. For identity teams, this is the same governance pattern seen in non-human identity management: access that is not time-bound, owned, and actively retired becomes an enduring security liability.

Practical implication: connect SaaS renewal review, ownership validation, and account retirement into the same lifecycle workflow.


Threat narrative

Attacker objective: The attacker objective is to exploit unmanaged SaaS access paths and hidden data flows to reach sensitive information or maintain durable access outside enterprise control.

  1. entry: A business user or department acquires an unsanctioned SaaS application through a self-service or shadow IT path, bypassing central review.
  2. escalation: The application receives data access, integrations, or shared ownership without a standard entitlement review, which expands what the app and its users can reach.
  3. impact: Sensitive data, compliance obligations, and renewal exposure accumulate in a system that IT cannot fully see or retire on schedule.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

SaaS management is identity governance by another name. The article describes discovery, ownership, renewals, and compliance, but those are the same governance primitives identity teams already manage for accounts and entitlements. The difference is that SaaS multiplies the number of systems and the number of decision points, which makes fragmented ownership the real failure mode. Practitioners should treat SaaS management as part of the identity programme, not as an adjacent procurement exercise.

Shadow IT is a control-plane split, not just a policy problem. Once departments procure and operate their own SaaS, the enterprise loses a shared source of truth for access, configuration, and offboarding. That split creates a second governance reality where security settings can diverge from the corporate standard. The implication is that governance must follow the system of record for access, not only the approved software list.

Lifecycle drift is the named risk hiding inside SaaS sprawl. The recurring issue is not simply too many apps, but access and ownership that outlive the business need that created them. In NHI terms, this looks like unmanaged persistence: permissions, renewals, and integrations remain valid after the original purpose has faded. Practitioners should recognise lifecycle drift as the operational pattern that turns SaaS convenience into long-tail exposure.

Visibility without accountability does not reduce risk. The guide emphasises discovery and diagnostics, yet discovery only matters if each application has a clear owner, a revocation path, and a review cadence. Otherwise visibility becomes inventory theatre. The stronger governance model is to attach every SaaS relationship to a lifecycle owner who can answer who can access it, why it exists, and when it should be retired.

Identity teams need a broader control model than SSO alone. SSO improves sign-in consistency, but the article’s own risk examples show that renewals, data exposure, duplicate applications, and shadow ownership sit outside login controls. That is why SaaS governance has to connect IAM, IGA, procurement, and security operations. The practitioner conclusion is simple: if the only control you govern is authentication, the rest of the SaaS lifecycle remains exposed.

From our research:

  • 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
  • Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
  • Read NHI Lifecycle Management Guide for the lifecycle controls that stop SaaS and machine access from outliving business need.

What this signals

Lifecycle drift is the signal practitioners should watch first. If SaaS ownership, renewals, and access reviews live in different systems, the programme will drift toward hidden persistence even when discovery tooling is in place. Teams that already struggle with secret revocation and account retirement should assume the same pattern will appear in SaaS governance unless lifecycle ownership is made explicit.

The practical next step is to connect SaaS governance to identity lifecycle controls, not to keep it isolated in procurement or finance. When discovery surfaces an app, the response should include access review, renewal review, and offboarding criteria in the same workflow. That is the only way to turn visibility into durable control.


For practitioners

  • Create a single SaaS ownership registry Map each application to a business owner, technical owner, data owner, and renewal approver so no app exists without an accountable lifecycle path.
  • Tie SaaS reviews to access and renewal cycles Use recurring reviews to validate active users, dormant licenses, and auto-renewing contracts at the same time, so access and spend drift are remediated together.
  • Classify shadow SaaS as an access exception When an app appears outside the approved stack, route it into identity and security review before it is allowed to connect to data, integrations, or SSO.
  • Retire abandoned integrations on a fixed schedule Identify API connections, delegated admin paths, and dormant app accounts, then remove them through a scheduled offboarding process rather than leaving them in place.

Key takeaways

  • SaaS management is an identity governance problem as much as an application management problem, because ownership and access drift create the real risk.
  • The article’s evidence points to shadow IT, duplicate apps, and unclear accountability as the main sources of cost, exposure, and compliance failure.
  • Practitioners should unify discovery, ownership, review, and offboarding so SaaS controls operate as one lifecycle rather than separate hygiene tasks.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-1SaaS discovery and account ownership map to identity and access management.
OWASP Non-Human Identity Top 10NHI-01Unmanaged SaaS often hides service accounts, API keys, and delegated access.
NIST Zero Trust (SP 800-207)PR.AC-4SaaS governance depends on continuous validation of user and app access.

Inventory SaaS access paths and assign accountable owners for each application.


Key terms

  • SaaS sprawl: SaaS sprawl is the uncontrolled growth of cloud applications across teams, departments, and business units. It becomes a governance problem when ownership, access, and data handling are split across too many systems for the identity programme to track consistently.
  • Shadow IT: Shadow IT is software or services adopted without central approval or visibility. In SaaS environments, it matters because unmanaged apps can carry real data, integrations, and access paths that bypass normal review and offboarding controls.
  • Lifecycle governance: Lifecycle governance is the set of processes that control how access is granted, reviewed, renewed, and removed. For SaaS, it means treating app ownership, user access, integrations, and retirement as one continuous control loop rather than separate tasks.
  • Delegated SaaS access: Delegated SaaS access is the permission granted to teams, admins, or third parties to configure or manage an application on behalf of the organisation. It needs explicit ownership and review because delegated authority can outlive the business purpose it was meant to serve.

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.

This post draws on content published by Zluri: SaaS Management What Is SaaS Management: A Comprehensive Guide 2026. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-03-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org