Zluri’s $10m funding spotlights SaaS governance pressure

At a glance

What this is: Zluri's funding update frames SaaS sprawl as an identity and governance problem, with discovery, integration depth, and automation positioned as the core control points.

Why it matters: For IAM, IGA, and PAM teams, SaaS sprawl changes who has access to what, how quickly it changes, and how hard it is to prove control across human and non-human identities.

By the numbers:

• Zluri said it had added over 100 new customers from North American and Asian markets in the past year.
• Zluri reported a library of 300+ in-depth direct integrations.

👉 Read Zluri's Series A funding update and SaaS management expansion plans

Context

SaaS management is really about governing access across a fast-changing application estate, not just tracking software spend. As organisations adopt more cloud apps, the identity challenge shifts from one-time provisioning to ongoing discovery, entitlement visibility, and control over who or what can connect to those services.

This funding update matters because SaaS management now sits close to the boundary between IT operations and identity governance. When application sprawl expands, the practical questions become whether teams can see the full estate, understand the access paths behind each app, and keep offboarding, review, and automation aligned with real usage.

Key questions

Q: How should teams govern SaaS sprawl without losing access visibility?

A: Start with discovery, then tie every application to an owner, an identity source, and a review cadence. Visibility only becomes governance when you can tell who has access, how that access was granted, and how it is removed. Without that linkage, SaaS sprawl turns into unmanaged entitlement growth rather than controlled adoption.

Q: Why does SaaS growth create identity risk for IAM and IGA teams?

A: Because each new application introduces another place where identities, roles, and delegated access can drift out of sync with policy. The risk is not just more software. It is more access surfaces, more offboarding paths, and more chances for dormant or over-privileged accounts to persist unnoticed.

Q: How do organisations know whether SaaS automation is actually reducing risk?

A: Measure whether automated workflows are removing stale access faster than it is created, whether exceptions are tracked, and whether review outcomes are reconciled back into the source systems. If automation speeds up tasks but leaves ownership and evidence unclear, it has improved efficiency more than control.

Q: What is the difference between SaaS management and SaaS governance?

A: SaaS management focuses on inventory, spend, and operational coordination. SaaS governance focuses on who can access each application, how that access is reviewed, and whether lifecycle events remove it on time. Organisations need both, but governance is the layer that determines whether access remains under control.

Technical breakdown

SaaS discovery as the control plane for access governance

SaaS discovery is the process of identifying which applications exist, which teams use them, and how they connect to identity systems and data. In practice, discovery becomes the control plane for governance because teams cannot review, secure, or retire what they cannot see. Deep integration coverage matters when access is distributed across SSO, local accounts, API connections, and embedded admin roles. The challenge is not simply inventory. It is correlating application presence with identity exposure, business ownership, and control responsibility across the stack.

Practical implication: build discovery coverage first, then map each app to an owner, access path, and review cadence.

Automation for SaaS access does not replace governance

Workflow automation can reduce manual effort in provisioning, deprovisioning, and repetitive SaaS tasks, but automation only helps if the underlying policy is sound. Automation without ownership, approval logic, and lifecycle triggers can simply make bad access patterns faster. For identity teams, the technical issue is orchestration across multiple systems, not just button-click efficiency. Automated actions must still reflect joiner-mover-leaver events, application-specific entitlement models, and exceptions that need human review.

Practical implication: pair automation with explicit ownership and lifecycle triggers before expanding it across the SaaS estate.

SaaS integration depth determines visibility into the identity surface

A broad application library is useful only when integrations expose the operational details that matter, such as users, admins, roles, and connection types. Without that detail, teams may know an app exists but still miss who can administer it, which accounts are dormant, or where shadow access persists after offboarding. The identity surface in SaaS is often fragmented across vendor consoles and federated directories, so integration depth is what turns inventory into actionable governance data.

Practical implication: test whether integrations expose users, roles, and admin paths before treating coverage as complete.

NHI Mgmt Group analysis

SaaS sprawl is now an identity governance problem, not a procurement problem. The article frames scale in terms of application growth, but the real operational burden lands on access control, ownership, and review. When every new app adds another identity boundary, the programme requirement shifts from buying software to governing a changing access graph. Practitioners should treat SaaS visibility as a governance dependency, not an inventory exercise.

Integration depth is the difference between knowing an app exists and knowing who can act in it. A catalogue of applications without entitlement detail does not support access certification, offboarding, or least privilege enforcement. The identity risk is not just blind spots, but false confidence created by partial telemetry. Practitioners should assume that shallow discovery leaves admin access, dormant accounts, and delegated connections outside control.

Workflow automation only reduces risk when lifecycle logic is already defined. The funding narrative centers on automation, but automation does not solve ambiguous ownership or inconsistent joiner-mover-leaver handling. If access events are not tied to lifecycle triggers, the organisation simply accelerates existing policy drift. Practitioners should treat automation as an execution layer, not a governance model.

SaaS governance and NHI governance are converging at the same control points. Every SaaS application introduces service accounts, API connections, and machine-to-machine access that sit beside human users. That means the same programme has to govern people, workloads, and delegated access paths in one place. Practitioners should design for mixed identity estates rather than keep SaaS, NHI, and IAM controls in separate silos.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity governance still starts from incomplete inventory.
• For lifecycle and offboarding depth, see NHI Lifecycle Management Guide, which covers the governance actions that inventory alone cannot deliver.

What this signals

Identity visibility has become the limiting factor in SaaS control. As application estates expand, teams should expect more of their risk to sit in undocumented access paths, unmanaged integrations, and unclear ownership. The governance test is no longer whether a platform exists, but whether the organisation can prove who can act inside it and remove that access when needed.

The stronger programmes will connect SaaS discovery to access review, offboarding, and exception handling rather than treat those as separate workflows. That shift matters because automation only creates control when policy, evidence, and lifecycle triggers are aligned.

Mixed identity estates are the new normal: SaaS environments now combine human users, service accounts, and API connections, so teams need one governance model that can see all three. The organisations that separate those controls will keep discovering gaps after the fact.

For practitioners

• Inventory the full SaaS estate before expanding automation Use discovery to identify every business app, then classify each one by owner, authentication path, and integration type so hidden access paths do not survive the onboarding process.
• Map every SaaS application to a lifecycle owner Assign responsibility for joiner-mover-leaver handling, access reviews, and offboarding at the application level so no service can remain outside governance because ownership is unclear.
• Validate integration depth before using a platform as a control source Check that each connector exposes users, admins, roles, and connection types, not just app presence, so review and remediation decisions are based on actionable identity data.
• Tie automation to explicit policy triggers Only automate provisioning or removal after you define the event that should trigger the action, the approval path for exceptions, and the evidence needed for audit.

Key takeaways

• SaaS growth creates identity sprawl when discovery, ownership, and access review do not move together.
• Integration depth matters because a platform that cannot expose users, roles, and admin paths cannot support real governance.
• Automation should follow policy and lifecycle design, not substitute for them.

Key terms

• SaaS sprawl: SaaS sprawl is the uncontrolled growth of cloud applications across an organisation. It becomes an identity problem when each new app adds users, roles, integrations, and offboarding paths that must be governed consistently. Without visibility and ownership, sprawl turns into access drift.
• Identity surface: The identity surface is the total set of accounts, credentials, roles, integrations, and control points through which access can be granted or abused. In SaaS environments, it includes human users, service accounts, API connections, and delegated application access, all of which need governance.
• Lifecycle trigger: A lifecycle trigger is the event that starts an access action, such as joiner, mover, leaver, contract change, or application decommissioning. When triggers are defined well, automation can remove or adjust access reliably. When they are missing, workflows execute without governance intent.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Miscellaneous SaaS Management Platform Zluri raises $10M led by MassMutual Ventures. Read the original.