TL;DR: SaaS security failures often start with fragmented visibility, inconsistent access distribution, and unmanaged third-party integrations, according to Zluri’s article and Gartner’s finding that 99% of cloud security breaches will be the user’s fault. The practical issue is not just app hardening, but governing who and what can reach sensitive data across SaaS, SSO, and connected services.
At a glance
What this is: This is a SaaS security guidance piece arguing that the main failure mode is not app hardening alone but identity governance across users, access paths, and integrations.
Why it matters: It matters because IAM, IGA, and SaaS security teams need a shared control model for users, app entitlements, and third-party access rather than treating SaaS risk as a standalone configuration problem.
By the numbers:
- 99% of cloud security breaches will be the user's fault, according to Gartner's report cited by Zluri.
- Zluri says its platform uses nine advanced discovery methods to ensure 100% of SaaS apps used in an organization are discovered.
- Zluri says backed up data is stored for a period of 60 days.
Context
SaaS security in this article is really an identity and access problem. The main issue is not just whether a SaaS application is configured securely, but whether the organisation can see who is using it, what they can access, and which integrations extend that access beyond the core application.
That matters because SaaS environments usually grow through fragmented onboarding, shadow app use, and third-party connections that outpace central governance. Once access is distributed inconsistently, risk starts to look like a governance failure rather than a single product or settings failure.
The article's core claim is typical of modern workplace SaaS estates. The same visibility and entitlement gaps show up in most organisations that rely on SSO, CASB, SSPM, and unmanaged app sprawl.
Key questions
Q: How should security teams govern access across SaaS sprawl?
A: Security teams should govern SaaS sprawl with one inventory, one policy model, and one review process that covers both human and non-human access. The practical goal is to connect application approval, entitlement review, and revocation to business ownership. Without that linkage, access governance becomes a manual cleanup exercise instead of a control system.
Q: Why do SaaS security controls fail when access distribution is inconsistent?
A: Because inconsistent access distribution breaks the link between ownership, entitlement, and accountability. When users, connectors, or shared permissions are granted too broadly, teams lose the ability to prove who can act on sensitive data and why. That weakens both security response and auditability across the SaaS estate.
Q: What are the signs that SaaS access governance is failing in a distributed tooling environment?
A: Common warning signs include manual onboarding and offboarding steps, access requests that do not reconcile with ITSM records, unknown OAuth logins, and licenses that remain active after an employee changes role or leaves. If teams cannot trace who approved what and when, the governance model is already too fragmented to support reliable oversight.
Q: Should organisations prioritise CASB, SSPM, or SaaS management for access control?
A: They should use them as complementary layers, not substitutes. CASB improves cloud visibility, SSPM spots SaaS misconfigurations, and SaaS management gives the inventory and ownership context needed for governance. The right sequence is to connect tool findings to identity and entitlement processes so access decisions are actually enforceable.
Technical breakdown
Why SaaS visibility fails without identity governance
SaaS visibility is not just inventory. It means knowing which applications exist, which identities can reach them, what data those identities can touch, and whether access is sanctioned or inherited through federation and connected services. A CASB may reveal some usage patterns, but it often does not expose the full governance context around app ownership, channel-level activity, or third-party integrations. That leaves teams seeing surface activity without understanding entitlement risk. In practice, identity governance is the control plane that turns app discovery into access accountability.
Practical implication: tie SaaS discovery to entitlement review so every app is mapped to an owner, user set, and access scope.
How improper access distribution becomes a SaaS control gap
Improper access distribution occurs when users, service connections, and shared app permissions are granted more broadly than their actual work requires. In SaaS, that can mean over-broad SSO access, poorly scoped sharing, or integrations that can read and modify data across multiple systems. The article's example of an app with access to Google Drive and the ability to modify or delete files shows the governance issue clearly: the risk is not just presence in the environment, but excess authority inside connected data paths. That is an IAM and IGA problem, not only a SaaS settings problem.
Practical implication: review high-impact SaaS permissions by connected data source, not only by application name.
Why unmanaged third-party integrations raise the blast radius
Third-party integrations extend trust outside the core SaaS application. Once an app, connector, or workflow tool is allowed to act on behalf of a user or tenant, the security boundary shifts from login controls to delegated access governance. If those integrations are not inventoried, scoped, and periodically revalidated, they become hidden pathways for data exposure and persistence. This is where SaaS security and identity governance converge most sharply: the app may be legitimate, but the delegated access may be broader than the business intended. That is the practical meaning of SaaS governance sprawl.
Practical implication: inventory every third-party integration and recertify delegated permissions as part of identity governance.
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.
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 security gaps are identity governance gaps, not just application misconfigurations. The article is right to connect cloud failures with centralised management, visibility, and access distribution. When the same identity can reach multiple SaaS apps through SSO and connected integrations, the real control boundary is governance of entitlements and delegation. Practitioners should treat SaaS risk as an access lifecycle issue, not a dashboard issue.
Unified discovery becomes a governance requirement once app sprawl outpaces central IT. Manual audits and isolated security tools cannot reliably track sanctioned and unsanctioned SaaS usage at modern workplace scale. That creates a blind spot between what the organisation believes it owns and what employees actually use. The practical conclusion is that inventory quality is now an access-control prerequisite, not a reporting nicety.
Delegated access is the named concept that should anchor SaaS governance programmes. The article shows how integrations, shared data paths, and app-level permissions extend trust beyond the primary login event. Once delegated access exists, the question is no longer only who signed in, but what that signed-in identity can do across connected services. Security teams need to govern delegation as a first-class identity surface.
CASB and SSPM solve different pieces of the problem, but neither replaces identity governance. CASB improves cloud usage visibility and SSPM helps identify SaaS misconfigurations, yet both can still miss ownership, entitlement, and offboarding issues when app use is fragmented. That means the programme gap sits above the tool layer. IAM and IGA teams should align SaaS controls to identity lifecycle governance rather than tool-specific coverage.
Compliance language in SaaS security only holds up when access is auditable end to end. The article references ISO 27001, SOC 2, and GDPR, which are only meaningful here if the organisation can show who accessed what, through which identity, and under what delegated permissions. Compliance is therefore a byproduct of governance quality, not a substitute for it. Practitioners should use regulatory obligations to sharpen entitlement discipline across SaaS estates.
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
Delegated access is becoming the hidden SaaS risk boundary. Once integrations and connected services can act on behalf of users, the governance question shifts from app security to delegation control. IAM teams should assume that every SaaS connector expands the identity surface unless it is explicitly inventoried and recertified.
The practical programme response is to join SaaS discovery, access reviews, and offboarding into one governance workflow. If the organisation can see apps but cannot prove who approved access or when a connector should be removed, then the control gap is operational, not theoretical.
For practitioners
- Map SaaS applications to identity owners Build an authoritative inventory that links each SaaS app to a business owner, technical owner, and the identities that can access it, including federated and third-party pathways.
- Review access distribution across high-risk apps Prioritise SaaS apps that can touch sensitive data or modify shared content, then validate whether current entitlements match actual job roles and business need.
- Recertify third-party integrations and connectors Treat every connector, automation, and delegated app permission as a governed identity relationship and reapprove it on a fixed cadence.
- Correlate SSPM findings with IAM data Use SSPM to surface misconfigurations, then validate them against SSO, directory, and access review records so ownership and access scope are visible together.
- Separate discovery from governance decisions Do not stop at app discovery or risk scoring; route findings into entitlement review, access removal, and application offboarding workflows.
Key takeaways
- SaaS security problems often begin when identity governance, not application settings, is the weakest layer in the control stack.
- Visibility, access distribution, and third-party integrations are the recurring fault lines that turn SaaS sprawl into exposure.
- The most useful response is to connect discovery, entitlement review, and delegated access governance into one programme.
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 addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and SOC 2 (AICPA) defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party SaaS integrations extend delegated identity risk across connected services. |
| NHI-05 — Overprivileged NHI | The article's access distribution problem is a classic over-privilege issue in SaaS-linked identities. | |
| NHI-10 — Human Use of NHI | Users and admins often rely on shared SaaS permissions and delegated access that blur accountability. | |
| Recommendation — Inventory and recertify third-party SaaS connectors before they become unmanaged identity pathways. Trim SaaS entitlements to the minimum access needed for each app, connector, and service account. Separate human access from delegated app access and document who approves each trust relationship. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing access scope across SaaS identities and integrations. |
| GV.OC-03 — Roles, responsibilities, and authority are established and communicated | SaaS risk in the article increases when app ownership and accountability are unclear. | |
| Recommendation — Review and enforce SaaS entitlements through a governed access-approval and recertification process. Assign clear app ownership and authority for every SaaS service and connected integration. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Improper access distribution in SaaS is a direct least-privilege failure. |
| Recommendation — Apply least-privilege review to SaaS users, connectors, and shared data permissions. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article emphasises managing who can access SaaS apps and when that access should be removed. |
| Recommendation — Centralise account governance for SaaS users, shared accounts, and delegated access paths. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | The article explicitly references SOC 2 and the need to control access to SaaS data and systems. |
| Recommendation — Document and enforce logical access controls over SaaS applications, integrations, and sensitive data. | ||
Key terms
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
- 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.
- Software As A Service Security Posture Management: Software as a Service Security Posture Management is the continuous assessment and control of security settings, access, and data exposure across SaaS applications. It focuses on misconfigurations, excessive permissions, risky integrations, and weak governance. The discipline maps SaaS controls to policy, detects drift, and supports remediation before exposure becomes an incident.
- Cloud Access Security Broker: A CASB is a control layer that monitors and governs how users and services access cloud applications and data. It is strongest when used to enforce policy, detect shadow IT, and apply cloud app controls, but it still depends on accurate identity and entitlement data upstream.
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 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