SaaS governance is becoming an identity attack-surface problem

At a glance

What this is: This is Zluri’s report on SaaS governance, with the core finding that the security problem starts after procurement and extends across access, data handling, and termination.

Why it matters: It matters because IAM teams must govern SaaS access, connected identities, and lifecycle offboarding together, or risk leaving unmanaged access paths outside formal identity controls.

By the numbers:

• We surveyed 100 IT leaders to know their perspective on SaaS Governance.
• Zluri | Identity Governance & Administration Reviews Rated by Gartner Peer Insights 4.7 Based on 10 reviews as of 19th Nov 2025

👉 Read Zluri's report on SaaS governance and IAM attack surface reduction

Context

SaaS governance is the discipline of controlling application access, use, and termination after an app has been procured. In practice, the risk appears when employees keep using applications outside central oversight, store sensitive data on personal devices, or retain access after leaving the organisation.

For IAM and governance teams, the issue is not only SaaS sprawl but identity sprawl across connected apps, personal accounts, and lifecycle gaps. That makes SaaS governance part of broader identity attack-surface management, not a separate procurement exercise.

Key questions

Q: What breaks when SaaS access is not tied to lifecycle controls?

A: Access persists after the business need has ended, which means former employees, stale integrations, and unused permissions can still reach data. That breaks offboarding, weakens auditability, and leaves organisations unable to prove that access was removed when the relationship changed. SaaS governance only works when termination closes the identity path, not just the HR record.

Q: Why do SaaS apps increase identity governance risk?

A: SaaS apps multiply the number of identities, delegated connections, and data paths that IAM teams must track. Risk rises when visibility stops at the app catalogue and does not extend into permissions, shared access, and residual data on personal devices or accounts. The result is a wider attack surface with weaker accountability.

Q: How can security teams know whether SaaS governance is actually working?

A: They should look for closed-loop evidence: every discovered risky app or access path has an owner, a remediation action, and a completion timestamp. If teams can only report inventory but not reduction in unmanaged access, the control is informational rather than protective. Effective governance changes the state of access, not just the quality of the spreadsheet.

Q: Who is accountable when SaaS access remains after offboarding?

A: Accountability should sit with the identity governance owner, the application owner, and the business approver who accepted the access. If any one of those roles is missing, the offboarding process can fail silently. Frameworks such as NIST Cybersecurity Framework 2.0 reinforce that identity governance must be measurable and owned, not implied.

Technical breakdown

IAM attack surface in SaaS environments

The IAM attack surface in SaaS environments is the set of identities, tokens, app connections, and admin paths that can be used to reach business data and controls. When employees connect multiple apps, reuse credentials, or authorise integrations without central visibility, the attack surface expands beyond the primary login. This is why visibility must cover both connected and disconnected systems, not just the apps already in the catalogue. The governance challenge is that many risks sit in the seams between identity, application, and data control planes.

Practical implication: map every SaaS app, integration, and privileged path to the identity owner before you can govern it.

Visibility, observability, and remediation as one control loop

Visibility tells you what exists, observability tells you what is happening, and remediation closes the loop when access or data use is out of policy. In SaaS governance, these are not separate maturity stages but linked controls. If you can see an app but not the permissions inside it, or detect misuse but cannot revoke access quickly, the control fails operationally. The report’s framing aligns with a zero-trust view of identity governance: continuous verification matters only if it is paired with action.

Practical implication: treat detection and revocation as one workflow, not separate teams or tickets.

Identity lifecycle management for SaaS users and apps

Identity lifecycle management in SaaS extends from request and approval through onboarding, access reviews, and termination. The key failure is not simply missing a review; it is allowing access to persist after the business need has ended. In SaaS settings, that persistence often includes stale user entitlements, shared app access, and residual data on personal devices or accounts. Lifecycle controls therefore need to cover both human identities and the application relationships those users create.

Practical implication: tie SaaS offboarding to access removal, data return, and app relationship cleanup in the same process.

Threat narrative

Attacker objective: The objective is to exploit unmanaged SaaS access and stale identities to reach data, extend access beyond the approved lifecycle, and increase exposure without immediate detection.

1. Entry occurs when employees gain legitimate access to SaaS applications and connected identities without full governance over their downstream use of the apps and data.
2. Escalation occurs when sensitive data is stored on personal devices or accounts, or when access persists after a leaver event and remains usable outside the organisation's intent.
3. Impact is realised when unmanaged access and weak lifecycle controls expose financial, security, and compliance risk across the SaaS estate.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SaaS governance is now an identity attack-surface discipline, not a procurement discipline. The article correctly points to the gap between buying software and governing how access behaves after deployment. Once employees can continue using apps, move data to personal devices, or keep access after departure, SaaS becomes an identity control problem. The practitioner conclusion is that SaaS governance belongs inside IAM and IGA operating models, not beside them.

Visibility without remediation leaves the governance model incomplete. Seeing SaaS apps and integrations is useful, but the real failure is when teams cannot act on what they see. Visibility, observability, and remediation have to operate as a single loop across connected and disconnected systems, or the attack surface remains intact. The practitioner conclusion is to measure closure speed, not just inventory coverage.

Identity lifecycle controls are the missing boundary in most SaaS programmes. Access reviews and offboarding are often designed around human employment events, but SaaS introduces persistent app relationships and residual data outside the core identity system. That means the lifecycle boundary must include app termination, entitlement removal, and user data recovery. The practitioner conclusion is to govern SaaS exit with the same rigour as joiner and mover processes.

Persistent SaaS access creates privilege creep in a form many teams undercount. The article’s risk framing reflects a familiar failure mode: access outlives its business purpose. In NIST CSF terms, this is an access governance weakness that affects protect and recover outcomes as much as identify and detect. The practitioner conclusion is to treat stale SaaS permissions as a measurable control defect, not administrative residue.

Identity visibility and SaaS governance are converging into one operating model. The named concept here is identity attack surface in SaaS: the combination of accounts, integrations, and residual access paths that can reach business data. That concept matters because the boundary is no longer the app login screen, it is the full path from request to offboarding. The practitioner conclusion is to model SaaS as part of identity security architecture, not only application management.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 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.
• The visibility gap is why practitioners should review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs alongside SaaS offboarding and access review design.

What this signals

SaaS governance is converging with identity governance, which means programme owners should expect more pressure to prove control closure rather than simple application inventory. The practical test is whether a discovered access path can be removed, reviewed, and evidenced before it becomes an audit exception.

Identity attack surface in SaaS: the useful mental model is no longer which applications exist, but which identities, delegated tokens, and residual relationships can still reach data. That shift aligns naturally with NIST Cybersecurity Framework 2.0, because the issue spans identify, protect, detect, and recover outcomes.

For practitioners, the next step is to connect SaaS governance to lifecycle discipline. If termination, access review, and delegated access cleanup are managed separately, the operating model will keep recreating the same exposure in a different application.

For practitioners

• Map SaaS identities beyond the login layer Inventory connected applications, delegated access, admin accounts, and any identity paths that can reach sensitive data. Include disconnected systems and personal-device usage where business access persists outside central control.
• Bind SaaS offboarding to entitlement removal Make termination workflows remove app access, revoke delegated tokens, and confirm data return or deletion where required. Do not treat employee exit as complete until SaaS access paths are closed.
• Measure remediation, not just discovery Track how long it takes to revoke risky SaaS access after it is identified, and report on exceptions where the issue is known but not closed. Use that metric to drive ownership across IAM, security, and application teams.
• Tie access reviews to application relationships Review which users, groups, and integrations are still necessary for each SaaS app, then eliminate orphaned access and unused connections. Recertification should cover the business relationship, not only the named user.

Key takeaways

• SaaS governance fails when it stops at procurement and does not control how access, data, and termination behave afterwards.
• The main evidence gap is visibility into connected apps and downstream access paths, which leaves remediation too slow to reduce exposure.
• Teams need to treat SaaS offboarding, access review, and delegated access cleanup as one lifecycle control, not separate administrative tasks.

Key terms

• SaaS Governance: SaaS governance is the set of controls that manage how software-as-a-service applications are approved, accessed, monitored, and retired. It extends beyond procurement into identity lifecycle, data handling, and offboarding so that access does not outlive the business need.
• Identity Attack Surface: Identity attack surface is the total set of accounts, tokens, delegated permissions, and access paths that can be used to reach systems or data. In SaaS environments, it includes connected apps, shared access, and residual permissions that remain after users change role or leave.
• Identity Lifecycle Management: Identity lifecycle management is the process of creating, adjusting, reviewing, and removing access as roles and business relationships change. For SaaS, it must cover users, delegated integrations, and app relationships so that termination actually closes the access path.
• Observability: Observability is the ability to understand what is happening in an environment from the signals it produces, not just to know that the environment exists. In identity governance, observability means you can trace access, detect anomalies, and confirm whether remediation actually occurred.

What's in the full report

Zluri's full report covers the operational detail this post intentionally leaves for the source:

• Survey findings from 100 IT leaders on where SaaS governance breaks down in practice.
• The report's end-to-end governance strategies from procurement through termination.
• How the vendor frames identity visibility, observability, and remediation across SaaS estates.
• Additional product and platform context around Zluri's identity governance and access management approach.

👉 The full Zluri report covers the governance strategies, visibility gaps, and remediation themes in more detail.

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.