Zluri’s $10m funding spotlights SaaS governance pressure

At a glance

What this is: Zluri’s funding update is a signal that SaaS sprawl is turning access and governance into a scaling problem, not just a software buying problem.

Why it matters: It matters because IAM and IGA teams now need coverage for application discovery, integration oversight, and control automation across a fast-growing SaaS estate.

By the numbers:

• The company says it added over 100 new customers from North American and Asian markets in the past year.

Context

SaaS governance pressure emerges when organisations can buy applications quickly but cannot keep pace with their discovery, access oversight, and integration lifecycle. In practice, the control problem sits in the middle of IAM, IGA, and SaaS operations, where usage, entitlements, and integrations fragment faster than teams can review them.

This article is not really about funding alone. It shows that platform demand is being pulled by a structural governance gap: enterprises need a way to understand what SaaS exists, who can use it, which integrations are active, and where automation can reduce manual control overhead.

Key questions

Q: How can IT and IAM teams reduce SaaS sprawl without slowing the business?

A: They should standardise app ownership, review duplicate tools by function, and retire software that no longer has clear demand. The goal is not blanket reduction, but a controlled stack where every app has an owner, a usage signal, and a clear offboarding path.

Q: Why do delegated SaaS integrations complicate identity governance?

A: They complicate governance because the access is often granted by business users or vendor workflows, yet the blast radius reaches production data and privileged APIs. Teams must govern scopes, approval owners, and reauthorisation cycles with the same seriousness they apply to human access, because the risk lives in the delegation chain.

Q: What signals show that SaaS governance is not working?

A: Look for delayed offboarding, repeated manual exports, inconsistent access review responses, and inactive accounts that still carry paid licenses. Those signals indicate that entitlement ownership and usage data are not reconciled often enough to support reliable governance.

Q: Should organisations prioritise SaaS discovery or access review first?

A: Discovery should come first when the app estate is poorly understood, because you cannot govern what you cannot see. But access review must follow quickly, otherwise discovery becomes a static inventory exercise. The right sequence is discover, assign ownership, then recertify or remove access.

Technical breakdown

SaaS application discovery and shadow access

SaaS estates become hard to govern when discovery is incomplete. Shadow applications, unmanaged subscriptions, and fragmented admin consoles mean identity teams often do not know the full access surface before controls are applied. That weakens entitlement review, offboarding, and audit readiness because governance starts with an incomplete inventory. In SaaS environments, discovery is not a reporting function. It is the prerequisite for knowing where access exists, who owns it, and which applications carry business-critical data or delegated integrations.

Practical implication: establish continuous SaaS discovery before attempting recertification or access rationalisation.

Integration density and delegated access risk

A large SaaS estate is governed through tokens, connectors, and direct integrations as much as through human logins. Each integration expands the access graph and creates delegated authority that may outlive the original business need. That matters because integrations can bypass the normal human IAM control path, especially when they are created outside central review or left active after ownership changes. The real governance task is to treat integrations as first-class access relationships, not as background configuration.

Practical implication: inventory integrations as access paths and review them with the same discipline as privileged accounts.

One-click automation and control drift

Automation reduces manual work only when the underlying policy model is accurate. In SaaS governance, workflows for provisioning, deprovisioning, and optimisation can drift if they are built on stale ownership data, incomplete application coverage, or inconsistent role definitions. That creates a false sense of control because activity increases while governance quality stays flat. The technical challenge is not simply automating tasks, but binding automation to authoritative identity and application context so the workflow reflects reality.

Practical implication: tie automation to authoritative identity and app ownership records before scaling control workflows.

NHI Mgmt Group analysis

SaaS sprawl is now an identity governance problem, not a procurement by-product. The funding story only makes sense because enterprises have reached a point where application growth outpaces control visibility. Once SaaS acquisition becomes frictionless, governance shifts from license management to identity and access orchestration across hundreds of connected services. The practitioner conclusion is that SaaS oversight belongs inside IAM and IGA operating models, not as a side process.

Integration count is a governance signal, not a capability metric. When a SaaS platform reports a large integration library, the identity question is how many delegated trust relationships those integrations create and how quickly they can be revoked. That is the control boundary practitioners need to see, because each connector can carry access, data movement, or automation authority. The conclusion is to assess integrations as part of entitlement scope, not as passive infrastructure.

Automation only helps when the underlying identity data is trustworthy. The article’s emphasis on one-click workflows reflects a common industry pattern: teams automate around incomplete inventories and then assume the process is mature. In reality, automation amplifies whatever data quality and ownership model already exist. The conclusion for practitioners is to fix identity and application source data before scaling SaaS workflow automation.

SaaS governance pressure exposes the limits of manual review cycles. Monthly or quarterly access reviews do not scale cleanly when application ownership changes, integrations multiply, and usage patterns shift continuously. That is why the market is converging on discovery-plus-automation models. The practitioner conclusion is to design governance around continuous state, not periodic cleanup.

Identity lifecycle control is the missing lens in many SaaS programmes. The same joiner-mover-leaver discipline used for human accounts has to extend to applications, integrations, and delegated access. Without lifecycle ownership, SaaS estates accumulate access that no one can confidently retire. The conclusion is that access governance must include offboarding logic for applications and connectors, not just people.

From our research library:

• The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.

What this signals

SaaS governance now depends on identity scope, not just software inventory. As estates expand, the useful control question is whether teams can continuously map applications, owners, and delegated access. Once that mapping breaks, provisioning, review, and offboarding all start to degrade together.

Integration sprawl is the governance debt that hides inside modern SaaS productivity. Every connector adds an access relationship that can outlive the business reason for creating it. Practitioners should watch for connector ownership gaps as an early indicator that the SaaS programme is drifting out of control.

For practitioners

• Define a SaaS control inventory Build a single inventory of all sanctioned applications, admin owners, and delegated integrations so governance starts from a complete estate view.
• Treat integrations as access relationships Review OAuth connections, connectors, and automation links as privileged access paths that require ownership, purpose, and revocation criteria.
• Bind automation to authoritative identity data Use source-of-truth identity and application ownership records before automating provisioning, deprovisioning, or access optimisation workflows.
• Extend lifecycle governance to SaaS offboarding Require explicit offboarding for applications, integrations, and dormant accounts when business ownership changes or subscriptions are retired.

Key takeaways

• SaaS growth becomes a governance problem when discovery, ownership, and integration oversight cannot keep pace with adoption.
• The article points to a large and increasingly connected application estate, which makes delegated access and automation the real control boundary.
• Practitioners should manage SaaS as part of the identity lifecycle, with continuous discovery, integration review, and explicit offboarding.

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.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Application Discovery: Application discovery is the process of identifying which software and services are actually in use, including unsanctioned or shadow applications. In lifecycle governance, it helps teams align access decisions with the real application estate instead of relying only on a static catalogue.
• Lifecycle Offboarding: Lifecycle offboarding is the process of removing an identity when it is no longer needed or no longer under the original owner’s control. In NHI programmes, it applies to service accounts and integrations as well as people, and it is essential for preventing stale access from surviving ownership changes.

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.