What breaks when organisations try to rely on IGA alone for SaaS governance?

Why This Matters for Security Teams

IGA is designed to govern identities that sit inside a defined process, with clear ownership, provisioning, and review cycles. SaaS estates rarely stay that tidy. Shadow IT, business-led app adoption, OAuth-connected tools, and externally hosted collaboration services often sit outside the reach of traditional joiner, mover, leaver workflows. That is why the failure mode is not just missed recertification, but entire application classes that never enter the governance program.

The practical risk is amplified when app access is granted through shared admin roles, delegated OAuth consent, or one-off integrations that were never mapped to a policy owner. NHI Management Group has documented how these gaps show up in real incidents, including the Salesloft OAuth token breach and the BeyondTrust API key breach, where token-based access created reach well beyond the original system of record. The control problem is broader than identity lifecycle alone and aligns with the governance gaps highlighted in the Top 10 NHI Issues. In practice, many security teams discover the exposure only after a SaaS app is already being used in production without ever entering IGA.

How It Works in Practice

IGA works best when it can anchor a clean inventory, ownership model, and entitlement review process. For SaaS governance, that means it should be the control plane for governed applications, not the only control. Security teams need a broader discovery layer to find every app in use, then classify which services are authoritative, which are tolerated, and which should be removed or isolated. The NIST Cybersecurity Framework 2.0 supports this kind of asset and access discipline, but it does not replace the need for SaaS-specific discovery and enforcement.

Operationally, strong programs combine IGA with:

• Continuous SaaS discovery from SSO logs, CASB telemetry, finance records, browser extensions, and OAuth consent records.
• Ownership mapping so every application has a business owner and a security owner.
• Policy-based classification for sensitive, regulated, and high-risk apps.
• Automated lifecycle actions for offboarding, dormant accounts, and orphaned integrations.
• Review workflows that include app entitlements, not only human user accounts.

That broader view matches NHIMG guidance in the Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs - Regulatory and Audit Perspectives, because the same governance gap appears when machine access, service accounts, and SaaS integrations fall outside the review boundary. Where teams get value fastest is in connecting discovery to remediation, then feeding only verified app records into IGA for periodic review. These controls tend to break down when SaaS usage is decentralised across business units because app ownership is unclear and consented access proliferates faster than review cycles can keep up.

Common Variations and Edge Cases

Tighter SaaS control often increases operational overhead, requiring organisations to balance governance coverage against business speed. That tradeoff matters most in environments where departments can self-procure software, especially when procurement, IAM, and security each have partial visibility but no single control point. Current guidance suggests there is no universal standard for how much of the SaaS estate must be directly managed through IGA versus monitored through adjacent controls; the right answer depends on data sensitivity, regulatory exposure, and the maturity of the discovery stack.

One common edge case is federated SaaS access through SSO. Teams assume SSO means the app is governed, but SSO only proves authentication path, not entitlement hygiene, consent scope, or service-to-service exposure. Another is OAuth-based tooling, where a user revokes their account but leaves behind token grants or integration permissions. The 2024 ESG Report: Managing Non-Human Identities from Oasis Security & ESG shows how often identity gaps turn into incidents, which is why the same rigor used for human access must extend to app-to-app access. The safest pattern is to treat IGA as one layer in a broader SaaS governance model, not the governance model itself.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on visibility alone for Microsoft 365 sharing risk?
• What breaks when organisations rely on Group Policy alone to block NTLMv1?
• What breaks when organisations try to secure SaaS access with MFA after the app inventory is already fragmented?
• What breaks when organisations rely on SaaS inventories that only cover approved applications