SaaS sprawl is widening the identity and compliance gap

At a glance

What this is: This interview argues that SaaS sprawl has turned identity and compliance into a visibility problem, with app integrations, APIs, and shadow IT obscuring where data and elevated access go.

Why it matters: It matters because IAM, IGA, and security teams now have to govern application access and data pathways as part of identity control, not just user logins and credentials.

👉 Read Zluri's interview on SaaS visibility, compliance, and shadow IT

Context

SaaS sprawl is the expansion of software usage beyond centrally managed procurement and IT oversight. In this interview, Zluri frames the problem as one of identity and compliance visibility: once employees can sign up for apps directly, security teams lose sight of what is in use, who can access it, and where data is flowing.

That shift matters for IAM and governance programmes because control is no longer limited to the directory or SSO layer. The real challenge becomes inventorying SaaS applications, understanding elevated access, and monitoring app-to-app connections closely enough to prove compliance and reduce exposure.

Key questions

Q: How should security teams govern SaaS sprawl in enterprise environments?

A: Start with discovery, then connect every known application to an owner, an access model, and a data flow record. Governance fails when teams only review approved apps, because shadow IT and unsanctioned integrations still create real identity and compliance exposure. Continuous inventory is the baseline control, not an optional enhancement.

Q: Why do SaaS integrations make compliance harder to prove?

A: Because the compliance question is no longer just who logged in, but where data went after the application connected to other services. APIs and delegated permissions can move information outside the original boundary, so auditors need evidence for both access and onward data transfer. Without that visibility, controls may exist on paper but not in practice.

Q: What breaks when shadow IT is not tracked in SaaS environments?

A: Untracked SaaS usage breaks entitlement review, offboarding, and privileged access control at the same time. If the organisation does not know an app exists, it cannot revoke access, validate integrations, or retire duplicated tools cleanly. The result is hidden exposure that persists even after the original business need has disappeared.

Q: How do teams decide which SaaS accounts need the tightest review?

A: Prioritise administrative roles, tenant owners, integration managers, and any account that can alter security settings or data routing. Those identities have the highest blast radius because they can change the posture of the platform itself. Standard user access matters, but privileged SaaS access is where governance failure becomes operationally expensive.

Technical breakdown

Why SaaS integrations create identity blind spots

SaaS applications often connect through APIs, delegated permissions, and third-party integrations that move data outside the original application boundary. Once those connections exist, a company may have valid user access but still lack control over how the application exchanges information with other services. That breaks the old assumption that securing the login also secures the environment. The problem is less about one risky app and more about the identity surface expanding into the connections between apps, data, and privileged accounts.

Practical implication: map SaaS-to-SaaS and SaaS-to-API connections as part of access governance, not as an afterthought.

Shadow IT as an identity inventory failure

Shadow IT appears when employees adopt applications outside approved procurement and onboarding channels. The operational issue is not only unsupported software, but also unmanaged identities attached to those services, including admin accounts, tokens, and delegated access. If teams do not know an application exists, they cannot review its permissions, monitor its data pathways, or decommission it cleanly. That makes inventory accuracy a prerequisite for both security control and compliance evidence.

Practical implication: tie SaaS discovery to entitlement review so unknown applications are brought into governance quickly.

Elevated access in SaaS environments

Elevated access in SaaS means administrative or high-impact permissions that let a user change settings, expose data, or alter integrations across the environment. In distributed SaaS estates, elevated access is often granted informally and then forgotten because the application sits outside traditional infrastructure control. The result is a governance gap between who can use an app and who can change its security posture. That gap becomes especially risky when access is spread across many departments and freemium tools.

Practical implication: classify and review privileged SaaS roles separately from standard user access.

NHI Mgmt Group analysis

SaaS sprawl is now an identity governance problem, not just an application-management problem. Once employees can create services without procurement, the control boundary moves outside the traditional IT intake process. That means identity teams are no longer only governing users and groups, but also the SaaS estates those users create and the permissions those services accumulate. The implication is that discovery, entitlement review, and lifecycle control must extend to application identities as well as human accounts.

Application inventory is the first missing control when SaaS usage outpaces governance. The interview describes a jump from a manually discovered 250 applications to more than 750 once a SaaS discovery tool was connected. That scale gap shows how unreliable manual spreadsheets are in modern estates. When inventory is incomplete, every downstream control, from access review to compliance reporting, becomes partially fictional. Practitioners should treat discovery quality as a governance control in its own right.

Data protection evidence depends on visibility into API-driven access paths. The article’s GDPR discussion is really about proving where data travels once applications and APIs are connected. If the organisation cannot trace those flows, it cannot reliably demonstrate control over regulated data movement. This is a classic governance failure mode in SaaS-heavy environments, where the application may be sanctioned but the data path is not fully understood. Practitioners need evidence that connects access, integration, and data flow.

Shadow IT creates a hidden privilege-creep problem across the SaaS layer. When multiple project management or collaboration tools coexist, elevated access tends to spread quietly across unused or redundant applications. Those accounts and integrations linger because no one owns the offboarding path. The result is not merely tool sprawl but privilege accumulation outside formal governance. Organisations should assume dormant SaaS access exists unless discovery and cleanup are continuous.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader governance lens, read the Ultimate Guide to NHIs for lifecycle, visibility, rotation, and offboarding patterns that map cleanly to SaaS governance.

What this signals

SaaS discovery is becoming a control-plane issue for identity programmes. The more app creation moves outside procurement and IT, the more identity teams need a governance layer that can find, classify, and retire services continuously. Manual review cycles are too slow for environments where users can introduce new SaaS tools in minutes.

Identity teams should treat delegated SaaS access as part of lifecycle management. Privileged roles, API connections, and redundant tools need the same owner-based offboarding discipline that human accounts receive. That is where the gap between access approval and access retirement usually opens.

The governance pattern here aligns closely with the Ultimate Guide to NHIs, especially where inventory, rotation, and access review intersect with cloud and SaaS operations.

For practitioners

• Build a live SaaS inventory Use discovery tooling and departmental validation together so the inventory captures sanctioned apps, shadow IT, and duplicated tools. Reconcile findings against procurement, SSO, and finance records to expose unmanaged services.
• Review API and integration permissions Inventory delegated access, service connections, and third-party app permissions for each major SaaS platform. Focus on whether each integration still has a business owner, a documented purpose, and a removal path when the relationship ends.
• Separate privileged SaaS roles from standard access Maintain a distinct review process for administrative users, tenant owners, and integration managers. Ensure those roles are recertified on a shorter cycle than ordinary users and tied to explicit business justification.
• Extend compliance checks to data flow evidence For regulated environments, record where SaaS data is stored, which apps receive it, and which APIs can forward it onward. Use that evidence during audits to show how data movement is controlled rather than assumed.

Key takeaways

• SaaS sprawl creates an identity blind spot because control now depends on seeing applications, integrations, and privileged access together.
• Manual inventories undercount real usage, which makes compliance evidence and access review unreliable in fast-moving SaaS estates.
• Security teams should extend governance to SaaS discovery, delegated permissions, and offboarding so hidden access does not outlive business need.

Key terms

• SaaS Sprawl: The uncontrolled growth of software-as-a-service applications across an organisation. It creates governance risk because apps are adopted faster than they can be inventoried, reviewed, and decommissioned, leaving security teams with incomplete visibility into access, integrations, and data movement.
• Shadow IT: Technology used without formal approval or oversight from central IT or security teams. In SaaS environments, it often includes free or freemium applications brought in by employees, along with the identities, permissions, and data flows that attach to them.
• Delegated Access: A permission model where one application or service is authorised to act on behalf of another user or system. In SaaS governance, delegated access can expand the attack surface because the original login is only part of the trust relationship.

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: Navigating cybersecurity in the age of SaaS, insights from Todd Dekkinga, CISO. Read the original.