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.
At a glance
What this is: A SaaS stack roundup that shows how tool sprawl expands the identity surface across collaboration, CRM, automation, finance, design, and HR systems.
Why it matters: It matters because every new SaaS app adds users, integrations, and lifecycle obligations that IAM, IGA, and PAM teams must account for across human and non-human access.
By the numbers:
- Loom is used by over 100000 companies for communication via video or screen sharing.
- Pipedrive is used by over 95000 companies.
- DocuSign is used by over 250000 companies in 150+ countries.
👉 Read Zluri's guide to SaaS tools for SMBs and enterprises
Context
SaaS sprawl is an identity governance problem, not just a procurement problem. The article describes how collaboration, CRM, automation, accounting, design, and HR tools accumulate across the business, which means every application also becomes a source of user access, integration access, and lifecycle work.
For IAM teams, the issue is the widening gap between adoption and control. The more business units buy and connect SaaS applications, the more difficult it becomes to maintain visibility, enforce least privilege, and keep access reviews aligned to what is actually in use.
Key questions
Q: How should security teams govern SaaS sprawl without slowing the business down?
A: Start by treating SaaS adoption as an identity governance problem. Build a live inventory of applications, owners, users, and integrations, then assign review cadences based on business criticality. The goal is not to block buying decisions. It is to make access, offboarding, and entitlement review visible enough that the business can keep moving without accumulating unmanaged privilege.
Q: Why do SaaS integrations increase identity risk even when users are well managed?
A: Because integrations often use service accounts, API keys, and delegated tokens that sit outside normal human access workflows. Those credentials can keep working long after the original use case changes. If security teams do not govern them as identities, they create a hidden access layer that bypasses the controls used for employees.
Q: What do teams get wrong about managing SaaS access at scale?
A: They often focus on the visible login experience and overlook the entitlement, integration, and lifecycle layers behind it. The result is good authentication but weak governance. Real control depends on knowing who can access each app, what they can do there, and whether that access is still justified after the business changes.
Q: How do IAM and IGA teams keep offboarding effective across a large SaaS stack?
A: Link offboarding to a full application inventory and require revocation evidence for every high-risk app, not just the directory. The hardest failures happen when access lingers in niche business tools or automation paths. Offboarding is complete only when the entire SaaS footprint has been checked and deprovisioned where needed.
Technical breakdown
Why SaaS sprawl becomes an access-governance problem
SaaS sprawl creates a control problem because each application introduces its own identity layer, permissions model, and audit trail. In practice, that means access is no longer governed in one place. Users, admins, API keys, and app-to-app connections all need different lifecycle handling. When organizations add tools for collaboration, CRM, marketing, accounting, and HR without a central entitlement model, the result is fragmented governance and duplicated privilege. The main failure mode is not the app category itself but the inability to see and certify who or what still has access after business needs change.
Practical implication: map every SaaS app to an owner, an access model, and a review cadence before the stack grows further.
How integrations and automation expand the non-human identity surface
Automation tools and SaaS integrations often rely on service accounts, API keys, and delegated tokens. These are non-human identities, and they outlive their original business context unless someone manages rotation, revocation, and scope reduction. When a tool like Zapier connects multiple apps, it can create hidden access paths that are easy to forget because they do not look like traditional user accounts. That makes integration governance part of identity governance. The operational issue is not just whether the workflow works, but whether the credentials behind it remain appropriate over time.
Practical implication: inventory every integration credential and treat it as an identity with an owner, purpose, and expiry review.
What SaaS adoption means for human IAM and lifecycle controls
The article shows that SaaS adoption now spans core business processes, from HR and finance to collaboration and sales. That makes joiner-mover-leaver processes more important, because access changes follow role changes across many systems at once. If lifecycle events are not synchronized, dormant access lingers in old tools and over-privileged accounts remain active. Human IAM fails when onboarding and offboarding are treated as single-system tasks rather than cross-platform governance events. The practical challenge is to keep provisioning, deprovisioning, and recertification aligned to the actual SaaS footprint.
Practical implication: tie offboarding and recertification to the full SaaS inventory, not just the directory or core productivity suite.
NHI Mgmt Group analysis
SaaS sprawl is an identity surface issue, not a software catalogue issue. The article frames a broad business tooling landscape, but the deeper governance problem is that every new SaaS subscription adds another access domain with its own lifecycle burden. Once collaboration, CRM, automation, accounting, and HR tools are all in play, the identity perimeter expands faster than most programmes can track. The implication is that SaaS inventory now belongs in identity governance, not just IT procurement.
Integration credentials are the hidden non-human identity layer in SaaS estates. Automation platforms and connected apps rely on API keys, delegated tokens, and service accounts that rarely get the same governance attention as employees. That creates a recurring control blind spot: the business sees workflows, while security inherits standing machine access. The relevant frame here is OWASP-NHI and NIST Cybersecurity Framework 2.0. Practitioners should treat every integration as a governed identity, not a convenience connection.
Lifecycle failure is the real risk multiplier in SMB and enterprise SaaS alike. The article’s broad tool list reflects how quickly business teams accumulate platforms outside central identity planning. Access review, offboarding, and privilege reduction then become cross-system problems instead of routine administrative tasks. This is where the Ultimate Guide to NHIs and NIST CSF align most closely: visibility and lifecycle discipline are what keep SaaS adoption from turning into unmanaged access debt. Practitioners should anchor governance to the full application estate, not the core directory.
Unified identity governance is becoming the only durable response to SaaS expansion. The article shows that modern work now depends on dozens of app-specific identities, each with different controls and owners. That means IAM, IGA, and PAM can no longer operate as separate conversations when the same users, integrations, and privileges move across all three. The field-level shift is toward one governance model that covers human access, machine access, and delegated access together. Practitioners should design around the whole identity surface, not individual tool categories.
From our research:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- For a deeper lifecycle view, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding discipline.
What this signals
SaaS sprawl is converging with NHI governance whether teams name it that way or not. Every automation link and app integration adds machine identity to the estate, which means access reviews that only cover users will miss a growing share of effective privilege. The practical shift is toward governance models that can track human accounts, delegated app access, and workload credentials together.
Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. That figure from Ultimate Guide to NHIs is a warning sign for any organisation letting SaaS stacks grow without identity ownership. If the business cannot revoke access cleanly, every new tool compounds residual risk.
Identity teams should expect SaaS rationalisation and identity rationalisation to become the same project. The more applications are added through department-led buying, the more access pathways are created outside central design. Practitioners who align procurement, lifecycle, and entitlement review will have a much clearer path to control than teams trying to retrofit governance after the fact.
For practitioners
- Build a complete SaaS identity inventory List every business application, its owner, authentication model, integration dependencies, and review cadence. Include shadow SaaS and department-owned tools so access decisions reflect the real estate, not just the approved stack.
- Classify every integration as a governed identity Tag API keys, delegated tokens, and service accounts with business purpose, system owner, and renewal date. Revoke or rotate credentials when the workflow changes, the vendor relationship changes, or the app is retired.
- Tie offboarding to cross-app revocation When an employee changes role or leaves, remove access across the full SaaS footprint, not only the directory and primary collaboration tools. Require evidence that linked apps and automation credentials were also reviewed.
- Run quarterly recertification on high-risk SaaS apps Prioritise finance, HR, CRM, and automation platforms where access drift has direct business impact. Review privileged users, external collaborators, and machine accounts together so hidden dependencies are not missed.
Key takeaways
- SaaS expansion is really an expansion of the identity surface, with governance consequences across users, integrations, and lifecycle controls.
- Automation and app-to-app connections create non-human identities that need ownership, rotation, and revocation just as much as employee accounts do.
- The practical response is unified lifecycle governance across the full SaaS footprint, not isolated access checks for a few core applications.
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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers rotation and lifecycle for integration credentials used across SaaS tools. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must stay aligned across many apps and integrations. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification across distributed SaaS access paths. |
Apply zero-trust principles to SaaS integrations and revalidate app access continuously.
Key terms
- SaaS sprawl: SaaS sprawl is the uncontrolled growth of software-as-a-service applications across the organisation. It becomes an identity issue when each application introduces its own users, admins, integrations, and offboarding tasks, creating more places where access can drift or persist after it should have been removed.
- Non-Human Identity: A non-human identity is any machine or software identity that authenticates and gets access on behalf of a process, application, or workflow. Examples include service accounts, API keys, tokens, and certificates, all of which need ownership, scope control, and lifecycle management.
- Lifecycle governance: Lifecycle governance is the set of processes used to provision, review, modify, and remove access as business roles and systems change. In SaaS estates, it must cover people and machine credentials together, or access will remain active in forgotten applications and automation paths.
- Delegated access: Delegated access is permission granted to one application or service to act in another system on behalf of a user or workflow. It is convenient for integration, but it also creates a separate governance obligation because the delegated permission can outlive the original business need.
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 Zluri: IT Teams SaaS Stack for SMBs and Enterprises. Read the original.
Published by the NHIMG editorial team on 2025-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org