SaaS governance is now an identity governance problem for CISOs

At a glance

What this is: This is a SaaS governance guide whose central finding is that SaaS control fails when identity, lifecycle, and vendor oversight are treated as separate problems.

Why it matters: It matters to IAM practitioners because SaaS sprawl is really an identity surface problem, with direct implications for NHI, human access governance, and delegated vendor risk.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Zluri's guide to SaaS governance and identity control

Context

SaaS governance is the discipline of deciding who and what can use SaaS applications, under which policies, and with what visibility. In practice, that means the control plane sits across human access, service accounts, API tokens, vendor integrations, and the data moving through each application.

Zluri’s guide frames SaaS governance as a way to manage risk, compliance, performance, and cost across the SaaS lifecycle. The deeper identity issue is that every new app adds another set of entitlements, renewal decisions, and offboarding obligations, which is why SaaS governance now intersects with NHI governance and access lifecycle control.

The article’s starting point is typical of the market: most organisations have accepted SaaS as operationally unavoidable, but have not built the governance discipline needed to keep access, data, and vendor connections inside policy boundaries.

Key questions

Q: How should security teams govern SaaS access across users, integrations, and vendors?

A: Treat SaaS access as an identity governance problem, not an application checklist. Build one inventory that includes human users, service accounts, OAuth grants, API tokens, and vendor support paths. Then apply lifecycle reviews, ownership assignment, and offboarding controls to each path so access does not survive beyond its business purpose.

Q: Why do SaaS environments create hidden identity risk for IAM teams?

A: SaaS platforms create risk because access is distributed across many small decisions. A user can have direct access, an app can have delegated authority, and a vendor can retain support credentials, all at the same time. Without unified governance, those permissions accumulate faster than teams can review them.

Q: What breaks when SaaS offboarding is handled only by IT?

A: Access often remains active after the business need ends. IT may disable an app account, but it can miss API keys, OAuth grants, vendor links, and shadow integrations that continue to operate. That leaves authority in place even when the application or contract should have been closed.

Q: Who should own SaaS governance decisions when multiple teams are involved?

A: Ownership should sit with the business and identity governance teams together. IT can enforce controls, but it should not decide whether an app, integration, or access path still has a valid business purpose. Clear ownership is what makes recertification, renewal, and offboarding enforceable.

Technical breakdown

SaaS governance as an identity control plane

SaaS governance is not just application oversight. It is the set of policy, access, and lifecycle controls that decide who can connect, what data can be touched, and when access should end. In a SaaS-heavy environment, that control plane includes SSO, MFA, role assignment, delegated access, token issuance, and app-level auditability. Where this breaks down is not usually at the point of login, but in the accumulation of permissions across disconnected tools. The more SaaS platforms an organisation uses, the more its governance model depends on consistent identity inventory and entitlement visibility.

Practical implication: map SaaS governance to identity inventory and entitlement review, not just app cataloguing.

Lifecycle management for SaaS entitlements and offboarding

SaaS lifecycle management covers acquisition, use, renewal, suspension, and retirement. In identity terms, that means deciding when an application’s access should be provisioned, re-certified, or revoked, and who owns that decision. The failure mode is persistent access after the business need has changed, especially where integrations, support accounts, or vendor-created access remain active. SaaS governance becomes materially weaker when offboarding is treated as an IT task rather than an access-control control. This is where lifecycle discipline and SaaS oversight converge.

Practical implication: tie SaaS renewals to entitlement recertification and formal offboarding checkpoints.

Vendor connections, OAuth risk, and hidden delegated access

Modern SaaS governance extends beyond first-party users because many apps connect through OAuth grants, API tokens, and third-party integrations. These delegated paths can persist even when the original business owner has moved on or the integration is no longer needed. That creates a visibility gap that traditional reviews often miss, especially in environments with dozens or hundreds of connected apps. The technical problem is not only authentication, but delegated authority that outlives its original purpose. That is why SaaS governance increasingly overlaps with third-party access governance.

Practical implication: review connected apps and delegated OAuth grants as part of every access and vendor assessment cycle.

Threat narrative

Attacker objective: The attacker or careless insider seeks persistent delegated access to SaaS data and workflows that was never fully governed or retired.

1. Entry occurs when a SaaS app, integration, or delegated OAuth grant is approved without clear ownership or expiry controls.
2. Credential access or abuse follows when API keys, tokens, or support accounts remain active after the original use case changes.
3. Impact emerges through unauthorized access, data exposure, or silent expansion of the organisation’s attack surface across multiple SaaS tenants.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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 governance problem, not an application administration problem. The article correctly treats access, compliance, and vendor management as core governance elements, but the real binding constraint is identity control across the SaaS estate. Every connected app introduces humans, service accounts, tokens, and third-party grants that must be governed as one system. Practitioners should stop treating SaaS sprawl as a software inventory issue and start treating it as an entitlement and lifecycle problem.

Delegated access is the governance blind spot that keeps growing with SaaS adoption. OAuth grants, API tokens, and support access create authority that can persist independently of the person who approved it. That is a structural NHI issue because the access path survives changes in ownership, job role, or vendor relationship. Delegated access without lifecycle offboarding: this is the failure mode SaaS governance exposes most clearly, and it is the one practitioners need to name before they can manage it.

Cost optimisation and security control are the same conversation in SaaS environments. Unused subscriptions are not just wasted spend, they often signal dormant entitlements, stale integrations, and abandoned access paths. The article’s cost-control section therefore has identity implications: reducing app sprawl also reduces unreviewed access surface. Practitioners should read SaaS rationalisation as a governance control, not a procurement clean-up exercise.

Zero Trust only works in SaaS when identity state is continuously maintained. The vendor’s discussion of least privilege and dynamic governance aligns with the broader shift away from static trust in users or applications. In practice, that means access decisions must be tied to current business need, current device or session context, and current vendor relationship. IAM teams should treat SaaS governance as a continuous verification problem, not a one-time policy rollout.

SaaS lifecycle discipline is the missing bridge between human IAM and NHI governance. The same recertification, offboarding, and privilege-reduction logic applies whether the subject is a user, an integration, or a service account. The difference is that SaaS environments often blur those categories inside the same tool. Practitioners should build one governance model that can handle all three, rather than maintaining separate controls that drift apart.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That is why the NHI Lifecycle Management Guide is the right next step for teams trying to close the offboarding gap.

What this signals

Delegated access without lifecycle offboarding: SaaS programmes will keep failing at the same point until owners can prove that every OAuth grant, API token, and vendor support path has an expiry condition. The control question is no longer whether the app is approved, but whether its authority still matches the business relationship.

As SaaS estates expand, the governance challenge shifts from app approval to continuous entitlement reduction. Teams that can reconcile subscription sprawl, delegated access, and recertification in one workflow will reduce both exposure and waste.

For practitioners aligning SaaS governance with broader identity programmes, the priority is to make lifecycle review operational, not annual. That means the same control logic should apply across human access, NHI credentials, and third-party integrations, with evidence retained for audit and renewal decisions.

For practitioners

• Build a single SaaS entitlement inventory Track users, integrations, support accounts, API keys, and OAuth grants in one register so reviewers can see who or what actually has access across the SaaS estate.
• Tie renewal review to access recertification Require each renewal decision to confirm current business owner, data sensitivity, and whether any delegated access or dormant account should be removed before the contract extends.
• Review delegated access on a fixed cadence Inspect OAuth connections, API tokens, and vendor-managed support paths during access reviews so dormant authority does not persist after ownership or use case changes.
• Rationalise SaaS to reduce hidden identity surface Retire duplicate applications, unused integrations, and shadow SaaS tools because each one adds a separate access and audit burden that governance teams must continuously defend.

Key takeaways

• SaaS governance fails when identity, lifecycle, and delegated access are managed separately from application oversight.
• The most important evidence in the article is the hidden authority carried by users, integrations, tokens, and vendor connections across the SaaS estate.
• Practitioners should unify entitlement inventory, renewal review, and offboarding so SaaS governance becomes a continuous identity control process.

Key terms

• SaaS Governance: SaaS governance is the set of policies and controls used to manage how software-as-a-service applications are approved, accessed, monitored, and retired. It extends beyond procurement into identity, compliance, data protection, and vendor oversight, because each app creates its own access paths and lifecycle obligations.
• Delegated Access: Delegated access is authority granted to one identity or system to act through another, often via OAuth, API tokens, or support credentials. In SaaS environments, it can outlive the original business need if teams do not track ownership, expiry, and revocation as part of lifecycle governance.
• SaaS Entitlement: A SaaS entitlement is any permission that allows a user, integration, or vendor path to perform actions inside a software-as-a-service application. Entitlements can be direct or delegated, and they become a governance risk when they are not inventoried, reviewed, or removed after the need has changed.
• Lifecycle Offboarding: Lifecycle offboarding is the process of removing access, integrations, credentials, and approvals when an identity or service no longer needs them. For SaaS, it must include app accounts, vendor links, API keys, and OAuth grants, otherwise dormant authority remains active after the business purpose ends.

Deepen your knowledge

SaaS governance, entitlement inventory, and lifecycle offboarding are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance model that has to cover users, integrations, and vendor access together, it is worth exploring.

This post draws on content published by Zluri: SaaS Management SaaS Governance, the guide to SaaS excellence. Read the original.