TL;DR: As remote work expands tool adoption, SaaS stacks are becoming broader and harder to govern, with apps spanning collaboration, CRM, automation, accounting, design, and HR according to Zluri. The identity risk is not the apps themselves, but the uncontrolled access surface they create across users, integrations, and shadow pathways.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “SaaS Stack for SMBs and Enterprises”.
Key questions
Q: How should security teams govern access across SaaS sprawl?
A: Security teams should govern SaaS sprawl with one inventory, one policy model, and one review process that covers both human and non-human access.
Q: Why do SaaS sprawl and shadow IT create IAM risk?
A: They create IAM risk because each unmanaged application introduces another identity system, another set of privileges, and another place where access can persist after need changes.
Q: What breaks when SaaS subscriptions are not tied to access reviews?
A: Orphaned subscriptions and stale entitlements start to accumulate because no one revalidates whether the access still matches the job.
Practitioner guidance
- Inventory the full SaaS identity graph Document each application, its owning team, the human users attached to it and every integration token or API key that extends access beyond the app itself.
- Classify integrations as governed access paths Treat automation connectors, webhooks and sync tools as part of the access estate so they are included in approval, review and revocation workflows.
- Assign explicit ownership for departmental apps Require each SaaS service to have a business owner and an identity owner so entitlement drift does not become nobody's responsibility.
Bottom line: SaaS sprawl creates an identity governance problem because the access graph expands faster than most SMBs can track it.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
SaaS sprawl is an identity governance problem before it is a software inventory problem: The real issue is not how many tools a company buys, but how many identities, permissions and delegated access paths those tools create. Once every department can add apps independently, the access model becomes fragmented and lifecycle control weakens. Practitioners should treat SaaS expansion as an IAM design issue, not an application catalogue exercise.
A few things that frame the scale:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
A question worth separating out:
Q: How do organisations reduce SaaS access drift without slowing teams down?
A: Organisations reduce access drift by combining ownership, periodic review and clean offboarding for both users and connected apps. The objective is not to stop SaaS adoption, but to make every new app enter a known governance path. That keeps productivity gains while preventing permissions from accumulating beyond business need.
👉 Read our full editorial: SaaS sprawl is the identity surface problem SMBs keep underestimating