TL;DR: SaaS risk management is framed here as the discipline of finding, assessing, and reducing application, access, compliance, and third-party exposure across a growing SaaS estate, according to Zluri. The practical takeaway is that visibility, access control, auditability, and offboarding discipline matter more than adding another checklist.
At a glance
What this is: This guide frames SaaS risk management as a governance discipline that must cover discovery, access, auditing, compliance, and third-party exposure across the application estate.
Why it matters: It matters because IAM, IGA, and PAM teams have to control SaaS access paths and offboarding discipline before unmanaged apps, stale entitlements, and external integrations expand the blast radius.
Context
SaaS risk management is the discipline of identifying, evaluating, and reducing the security, compliance, and operational exposure created by an organisation’s software-as-a-service estate. In practice, that means knowing which apps exist, who can access them, which integrations touch sensitive data, and where ownership or offboarding breaks down.
Zluri’s article argues that the core problem is governance drift: SaaS estates expand faster than IT and security teams can inventory, review, and reconcile access. That creates a familiar identity control gap, where visibility, access discipline, and lifecycle management no longer move at the same pace as application adoption.
Key questions
Q: How should security teams inventory SaaS applications before setting CASB policy?
A: Start with application telemetry, SSO data, and direct integrations so the inventory reflects real usage, not only procurement records. Then reconcile sanctioned and unsanctioned apps, because CASB policy cannot govern what the team has not identified. The goal is a current identity surface for SaaS, not a one-time spreadsheet.
Q: Why do dormant SaaS integrations create so much identity risk?
A: Dormant integrations remain dangerous because they often keep valid secrets or delegated consent after the business process ends. If the permissions include read, write, or admin-like actions, a forgotten integration becomes a standing non-human identity that can be abused without alerting the original owner.
Q: What are the signs that SaaS and IaaS access controls are failing?
A: Common warning signs include overly permissive roles, unused accounts, stale shared links, weak authentication coverage, and third-party integrations that were never re-reviewed. In non-human identity estates, long-lived tokens and hidden service account permissions are especially concerning. If teams cannot quickly explain who owns access, what each identity can do, and when permissions were last validated, control is already eroding.
Q: How do organisations make SaaS offboarding actually work?
A: Organisations make SaaS offboarding work by combining account removal, session termination, and subscription closure into a single accountable workflow. If any one of those steps is missed, access can persist after the user or team no longer needs the application. The process should be owned jointly by IAM, IT, and procurement.
Technical breakdown
Why SaaS visibility breaks down in decentralised estates
SaaS estates fragment quickly because applications are adopted by teams, connected through APIs, and layered with integrations outside central control. Visibility fails when inventory is incomplete, ownership is unclear, and app usage changes faster than governance processes can track. In identity terms, the problem is not just missing software discovery. It is that access decisions, compliance checks, and termination workflows are operating on partial data, so the control plane never fully matches the live application surface.
Practical implication: build authoritative SaaS inventory and ownership mapping before trying to optimise review cadence or access policy.
How access control and MFA reduce SaaS risk
SaaS risk rises when broad user access, weak password practices, and unreviewed entitlements intersect with externally hosted applications. MFA reduces the chance that a stolen password becomes immediate access, while role-based access control narrows who can reach sensitive data or admin functions. But these controls only work when they are tied to real app ownership and entitlement review. Without that linkage, access control becomes a static policy instead of a live governance mechanism.
Practical implication: pair MFA and role-based access with app-level entitlement review, especially for CRM, finance, and file-sharing systems.
Why third-party integrations and shadow IT widen the identity attack surface
Third-party risk in SaaS is often really delegated identity risk. External APIs, connected apps, and unofficial tools create additional trust relationships that inherit access into core business systems. Shadow IT makes this worse because the security team cannot govern what it cannot see. The result is a broader identity surface with more credentials, more trust paths, and more offboarding points than the organisation thinks it has. That is why SaaS governance has to treat integrations as part of the identity estate, not as a side issue.
Practical implication: inventory connected apps and delegated access paths alongside primary SaaS applications, then remove any trust relationship that lacks an owner.
Threat narrative
Attacker objective: The objective is to reach sensitive SaaS data or business workflows through weakly governed access paths and then persist through poor oversight.
- Entry occurs when unmanaged SaaS adoption or third-party integrations create access paths outside central oversight.
- Credential or privilege exposure follows when permissions, tokens, or delegated access are broader than the business use requires.
- Escalation happens when stale entitlements, weak review cycles, or shadow IT keep those access paths active after business need changes.
- Impact is the loss of confidentiality, compliance assurance, or operational continuity across the SaaS estate.
Breaches seen in the wild
- SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
- New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SaaS risk management fails when access governance and application discovery are treated as separate problems. The article shows that visibility, auditing, and access control are all part of the same governance surface. When inventory is incomplete, entitlement review and offboarding cannot be trusted to reflect reality. The practitioner conclusion is simple: SaaS risk is an identity governance problem before it is a tooling problem.
Third-party integrations turn SaaS into delegated identity infrastructure. External services, APIs, and connected apps inherit trust into business systems and can outlive the original business justification. That is why the relevant question is not just which apps exist, but which trust relationships have been allowed to persist without an owner. Practitioners should treat integrations as governed access paths, not as passive connections.
Shadow IT is a control-plane failure, not merely an adoption issue. Once business teams adopt SaaS outside central oversight, the organisation loses the ability to enforce consistent security standards, compliance checks, and termination workflows. The named concept here is identity surface drift: the gap between the live SaaS and integration estate and the set of systems security teams believe they control. The practitioner conclusion is to measure governance against the real estate, not the approved list.
Access control in SaaS is only as strong as the lifecycle discipline behind it. The article repeatedly ties effective risk management to regular audits, role-based controls, and secure termination of services. That aligns with NIST CSF PR.AA-05 and CIS account management principles, but the deeper issue is that entitlement review without lifecycle enforcement leaves stale access in place. Practitioners should assume that unused access becomes active risk unless it is explicitly retired.
SaaS risk management is converging with broader identity security programme design. The same operational patterns appear across human IAM, NHI governance, and delegated SaaS access: inventory, ownership, authorisation, monitoring, and offboarding. The article signals that teams cannot keep these disciplines in separate silos if they want durable control. The practitioner conclusion is to govern SaaS through the same identity lifecycle model used for the rest of the enterprise.
From our research library:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
What this signals
Identity surface drift: SaaS environments change too quickly for periodic review alone to provide reliable governance. The practical answer is to connect discovery, entitlement review, and offboarding into one lifecycle model so the control plane follows the live application estate instead of a stale approval list.
Security teams should not treat SaaS governance as a software procurement issue. It is a cross-programme identity problem that touches IAM, IGA, PAM, and third-party access, because every unmanaged integration or shadow app creates another trust path that must be owned and retired.
The strongest programmes will measure SaaS risk by control completeness, not app count. That means knowing which apps have owners, which integrations inherit access, and which services can be terminated without leaving credentials or workflows behind.
For practitioners
- Build a complete SaaS application inventory Map all sanctioned and unsanctioned SaaS applications, then assign an owner to each one so security reviews and offboarding have a clear control point.
- Tie access reviews to real application usage Review roles, permissions, and admin access against actual usage data, not just directory membership, so dormant entitlement no longer looks acceptable.
- Treat integrations as governed trust relationships Catalogue third-party apps, APIs, and automation connections that can reach sensitive data, and revoke any delegated access path without a named business owner.
- Formalise SaaS termination and offboarding steps Require secure shutdown for shadow IT, unused subscriptions, and cancelled services so credentials, tokens, and connected workflows do not persist after business need ends.
Key takeaways
- SaaS risk is driven less by the number of applications than by the mismatch between the live estate and the governance records that are supposed to control it.
- The article’s core evidence is that visibility, access control, auditing, compliance, and third-party oversight all have to work together for SaaS governance to hold.
- Practitioners should treat SaaS inventory, entitlement review, and offboarding as one identity lifecycle rather than separate security tasks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | SaaS integrations and external services create delegated access paths that can outlive ownership. |
| NHI-01 — Improper Offboarding | The article stresses secure termination of SaaS services and removal of lingering access paths. | |
| Recommendation — Inventory third-party access paths and revoke any delegated SaaS trust that lacks an accountable owner. Tie SaaS offboarding to account removal, token revocation, and integration shutdown. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on access control, role-based permissions, and entitlement review in SaaS. |
| Recommendation — Review SaaS entitlements against actual business use and remove excess access promptly. | ||
| CIS Controls v8 | CIS-5 — Account Management | SaaS governance here depends on account ownership, review, and retirement discipline. |
| Recommendation — Establish account ownership, periodic review, and retirement workflows for every SaaS application. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Poorly governed SaaS trust paths can expose credentials and broaden access across connected services. |
| Recommendation — Map unmanaged SaaS trust paths to credential access and lateral movement risk in detection and review. | ||
Key terms
- SaaS Risk Management: SaaS Risk Management is the practice of identifying, assessing, and controlling security, privacy, compliance, and operational risks created by software delivered as a service. It covers how applications are configured, who can access them, what data they store, how identities are governed, and how third-party dependencies affect resilience and oversight.
- Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Identity Surface Drift: Identity surface drift is the gap between the access and trust relationships an organisation believes it controls and the ones that are actually active. In SaaS-heavy environments, apps, integrations, and shadow services expand faster than governance records, so the managed surface steadily falls behind reality.
Deepen your knowledge
Identity lifecycle management, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org