Why do shadow SaaS applications create risk even when an organisation has an IGA programme in place?

Why This Matters for Security Teams

shadow saas creates a governance gap that IGA was never designed to close. IGA assumes the organisation knows the application, the owner, the access model, and the lifecycle hooks needed for joiner-mover-leaver workflows. Shadow tools bypass those assumptions, so access certification, entitlement review, and revocation can all look “green” while real business data is flowing through unmanaged services.

The risk is not only missed revocation. Shadow SaaS often enters through personal accounts, browser-based sharing, or ad hoc integrations that never pass through procurement, so the identity team cannot enforce policy at the point of use. That leaves compliance, data loss prevention, and third-party oversight exposed even when the IGA programme is mature. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which illustrates how easily unmanaged identities and tools escape routine governance. See the Ultimate Guide to NHIs — Key Challenges and Risks and the NIST Cybersecurity Framework 2.0 for the broader visibility and governance context.

In practice, many security teams discover shadow SaaS only after data has already been shared, not through intentional discovery or access review.

How It Works in Practice

IGA remains valuable for governed applications, but shadow SaaS changes the problem from “who has access?” to “what is happening outside the control plane?” Employees may create accounts with work email addresses, connect unsanctioned apps to sanctioned data sources, or sync files into services that have no inventory record. IGA cannot certify or revoke access to systems it does not know exist, and it cannot validate policy on connections that bypass SSO, SCIM, or approved lifecycle workflows.

That is why security teams need discovery plus enforcement, not IGA alone. A practical control stack usually includes:

• Cloud access security broker, SaaS discovery, and DNS or proxy telemetry to reveal unsanctioned usage.
• Conditional access and tenant restrictions to reduce sign-up paths for unmanaged apps.
• Policy-based approval for high-risk integrations, especially those involving file storage, email, and CRM data.
• Continuous review of OAuth grants, browser extensions, API tokens, and service accounts tied to shadow tools.
• Offboarding processes that remove access to both sanctioned and discovered unsanctioned services.

This is where NHI governance becomes especially relevant. Shadow SaaS often depends on secrets, tokens, and service accounts that sit outside IGA workflows, so the organisation needs controls aligned to lifecycle, rotation, and revocation. NHIMG’s Top 10 NHI Issues and the Salesloft OAuth token breach show how unmanaged credentials can turn a convenience tool into a persistent access path. For control mapping, the NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for anchoring access, audit, and configuration requirements.

These controls tend to break down when users can self-provision SaaS with corporate email and independently authorize third-party integrations, because the app lifecycle never enters the IGA workflow.

Common Variations and Edge Cases

Tighter discovery and control often increases friction for employees, so organisations must balance usability against governance coverage. That tradeoff becomes more visible in high-collaboration environments, where teams adopt niche tools quickly and expect immediate sharing with external partners.

There is no universal standard for shadow SaaS governance yet. Current guidance suggests treating sanctioned, tolerated, and prohibited applications differently: not every unmanaged tool requires the same response, but every tool that handles corporate data needs some level of visibility and risk decision. Some organisations will choose to bring a shadow app into the approved estate; others will block it, isolate it, or restrict it to non-sensitive data only.

Edge cases matter. Business units may use one-off AI or file-sharing apps for a short project, contractors may bring external tooling into a temporary workflow, and administrators may create service connections that outlive the original need. These are exactly the places where IGA reports can look clean while actual exposure grows. Mature programmes pair inventory, data classification, and entitlement review with explicit discovery of SaaS-to-SaaS links and non-human credentials. The Ultimate Guide to NHIs — Why NHI Security Matters Now is useful here, because the same unmanaged patterns that drive shadow SaaS risk also drive hidden identity risk across the enterprise.

Related resources from NHI Mgmt Group

• Why do SaaS environments still create identity risk even after SSO is in place?
• Why do cloud ERP environments still create identity and access risk even when workflow automation is in place?
• Why do SSO groups create access risk even when application-level reviews are already in place?
• Why do non-human identities create compliance risk even when policies exist?