SaaS security gaps are really identity governance gaps

At a glance

What this is: This is a practitioner guide to securing SaaS apps, with the central finding that SaaS risk is driven by weak visibility, poor access distribution, and fragmented management.

Why it matters: It matters because SaaS controls sit across human identities, service connections, and delegated app access, so IAM, IGA, and NHI teams need a single governance view.

By the numbers:

• 99% of cloud security breaches will be the user's fault.

👉 Read Zluri’s analysis of how to secure SaaS apps in the modern workplace

Context

SaaS app security is really an identity governance problem when access paths, app sprawl, and delegated permissions are not centrally controlled. The article argues that weak visibility, poor access distribution, and unmanaged SaaS usage leave sensitive data exposed across the modern workplace.

That framing matters for IAM teams because SaaS environments now mix human users, OAuth-connected services, and non-human access paths. The governance question is no longer only whether an app is secure, but whether the organisation can see, review, and constrain every identity touching it.

Key questions

Q: How should security teams govern access across SaaS apps and connected integrations?

A: Start with complete discovery, then map every app to an owner, an access model, and a data sensitivity level. Governance fails when sanctioned apps, shadow apps, and delegated integrations are reviewed separately. Teams need one system of record for entitlement, usage, and revocation decisions across the SaaS estate.

Q: Why do SaaS environments create persistent IAM and IGA blind spots?

A: Because app usage, user access, and third-party connections are often discovered through different tools with different coverage. That fragmentation leaves gaps in recertification, offboarding, and risk scoring. IAM teams should assume that anything not centrally discovered is already outside effective governance.

Q: What do security teams get wrong about CASB and SSPM in SaaS governance?

A: They often treat either control as a complete solution. CASB does not fully answer app ownership and lifecycle questions, while SSPM does not fully answer who should have access. Effective governance requires both posture visibility and entitlement accountability across the same SaaS estate.

Q: Who should be accountable when a SaaS app exposes sensitive data?

A: Accountability should sit with the business owner of the app, the IAM or IGA team that governs access, and the security team that monitors posture. If third-party access is involved, ownership must also extend to the connected integration or OAuth grant. Shared accountability is the only workable model.

Technical breakdown

Why SaaS visibility breaks down in distributed workplaces

SaaS visibility breaks down when discovery is split across separate tools, business units, and shadow app usage. The article points to manual audits, CASB coverage limits, and unsanctioned SaaS as recurring blind spots. In practice, incomplete discovery means access reviews and policy enforcement are working from an incomplete asset inventory, which makes risk scoring and compliance reporting unreliable.

Practical implication: establish a complete SaaS inventory before trusting any access or compliance control.

CASB and SSPM: overlapping controls with different blind spots

CASB focuses on cloud traffic, access enforcement, and some policy controls, while SSPM focuses on SaaS configuration and posture drift. The article shows why neither alone gives full operational control over who uses an app, how it is configured, and what data it can reach. That gap is especially visible when apps are accessed through SSO but still retain their own privileges and integrations.

Practical implication: use CASB and SSPM together, and validate where each product stops seeing delegated access.

Why centralised SaaS management becomes an identity control plane

A SaaS management platform becomes an identity control plane when it links discovery, usage, security status, and compliance evidence in one place. The article describes integrated discovery methods, usage tracking, encrypted storage, and auditable logs as the operational foundation for that model. This is less about convenience and more about creating a system of record for access, exposure, and governance actions.

Practical implication: treat SaaS management as governance infrastructure, not just application administration.

Threat narrative

Attacker objective: The attacker’s objective is to reach sensitive SaaS data or use delegated access paths to alter, exfiltrate, or persist inside business workflows.

1. Entry occurs through sprawling SaaS adoption, unsanctioned apps, or third-party integrations that are not fully visible to the organisation.
2. Escalation follows when over-distributed access, weak audit coverage, or excessive app permissions allow sensitive data to be reached or modified.
3. Impact is data exposure, compliance failure, and loss of control over who can access or alter SaaS-held information.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 security is an identity governance problem before it is a tooling problem. The article is right to focus on discovery, access levels, and shared data because those are the control points that decide whether SaaS is governable at all. When an organisation cannot see which users, apps, and integrations touch the data, every later control becomes partial. The practitioner conclusion is that SaaS security starts with governance completeness, not isolated hardening.

Centralised discovery is the named concept that separates control from guesswork. A SaaS estate cannot be secured from a fragmented register, especially when apps are added outside IT and integrations evolve faster than reviews. This is a classic lifecycle and access-visibility failure, not a configuration-only issue. The practitioner conclusion is to treat discovery quality as a security metric, not an inventory exercise.

CASB-only thinking creates a coverage illusion. The article shows that CASB can see some cloud activity while still missing the operational detail needed to govern SaaS users, channels, and licensing relationships. That gap matters because access can be technically authenticated yet still poorly governed. The practitioner conclusion is to validate where the access control boundary actually sits before assuming policy coverage is complete.

SSPM improves posture monitoring, but posture is not governance. Continuous checks for misconfiguration are useful, yet they do not by themselves answer who should retain access, which integrations are still needed, or when delegated permissions should be removed. The deeper issue is that SaaS security depends on lifecycle control across identities, not just alerting. The practitioner conclusion is to align posture management with review, offboarding, and entitlement ownership.

SaaS management is becoming the operational layer where IAM, IGA, and NHI controls converge. The article’s strongest implication is that app governance now spans people, service connections, and data-sharing relationships in one environment. That makes the SaaS management layer strategically important for access accountability. The practitioner conclusion is to govern SaaS as a cross-domain identity surface rather than a collection of isolated apps.

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.
• A separate finding from the same research shows that 1 in 4 organisations are already investing in dedicated NHI security capabilities.
• For a broader lifecycle view, read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the governance steps that keep access reviews and offboarding aligned.

What this signals

Centralised discovery is fast becoming the dividing line between SaaS governance and SaaS sprawl. If the organisation cannot assemble a single source of truth for apps, identities, and integrations, access reviews will continue to certify an incomplete environment. That is why the discovery layer now matters as much as the enforcement layer, especially for teams aligning their programme to the NIST Cybersecurity Framework 2.0.

The practical signal for IAM leaders is that SaaS controls must now be measured against ownership, usage, and delegated access together. The article’s strongest lesson is not that another tool is needed, but that app governance collapses when lifecycle processes are split across security, IT, and procurement.

When SaaS is treated as part of the identity surface, the next maturity step is not more alerts but better entitlement hygiene. That means connecting application discovery to access reviews, offboarding, and evidence retention so the governance model matches how modern workplaces actually consume software.

For practitioners

• Build a complete SaaS inventory Combine identity provider data, expense records, directory sources, and direct app integrations so unsanctioned tools do not stay invisible to governance teams.
• Separate visibility from enforcement decisions Use CASB for traffic and access policy where it fits, but rely on a SaaS management layer for ownership, licensing, and app-level governance evidence.
• Review third-party integrations as privileged access paths Treat connected apps, OAuth grants, and shared datasets as governed access relationships that need ownership, review, and revocation criteria.
• Tie compliance evidence to app-level activity Retain auditable logs, risk scores, and app usage records so security and audit teams can prove which identities accessed which SaaS resources.
• Reconcile unsanctioned SaaS with access reviews Fold shadow apps into joiner-mover-leaver and recertification processes so access decisions reflect the real application estate, not only approved systems.

Key takeaways

• SaaS risk is largely an identity governance problem because access, integrations, and app sprawl are difficult to control without central discovery.
• The article’s key evidence is that visibility gaps, poor access distribution, and shadow SaaS undermine both security and compliance outcomes.
• Practitioners should treat SaaS management as governance infrastructure, linking discovery, entitlement review, and audit evidence in one operating model.

Key terms

• SaaS Security Posture Management: SaaS Security Posture Management is the discipline of continuously checking SaaS configurations, permissions, and exposure for risk. It focuses on misconfiguration, risky sharing, and compliance drift across applications that are already in use, rather than only on perimeter defence or network traffic.
• Cloud Access Security Broker: A Cloud Access Security Broker is a control layer that sits between users and cloud services to apply policy, visibility, and some enforcement. In practice, it is strongest for access control and monitoring, but it may not fully capture app-level ownership, lifecycle, or delegated permissions.
• Shadow SaaS: Shadow SaaS is software used inside an organisation without full visibility or approval from central IT or security teams. These applications often bypass standard onboarding, review, and offboarding processes, which creates gaps in access governance, data handling oversight, and compliance evidence.
• Delegated Access: Delegated access is permission granted through one identity or application to act on behalf of another system or user. In SaaS environments, it often appears through OAuth grants, connected apps, and service integrations, and it needs lifecycle governance just like direct user access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme maturity, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance How to Secure SaaS Apps in the Modern Workplace. Read the original.