CASB software for SaaS security is really an identity problem

At a glance

What this is: This is a comparative guide to CASB software that argues cloud visibility, DLP, and compliance controls are central to reducing SaaS risk.

Why it matters: It matters because IAM teams need to understand where CASB overlaps with application discovery, access governance, and identity-driven cloud control across human and non-human programmes.

By the numbers:

• Zluri has deep integrations with 300+ applications, including SSO.

👉 Read Zluri's CASB software comparison for SaaS security teams

Context

CASB software is meant to sit between users and cloud services so organisations can see activity, enforce policy, and reduce data exposure. In practice, the control problem is not just cloud traffic inspection, but identity visibility across sanctioned apps, unsanctioned apps, and the accounts that connect them.

For IAM teams, that makes CASB adjacent to NHI governance and access governance rather than a standalone cloud add-on. The article’s core message is that cloud control fails when the organisation cannot reliably see who or what is using the SaaS stack, what permissions those identities hold, and where policy enforcement should attach.

The SaaS governance question is broader than network inspection. It includes app discovery, data loss prevention, compliance mapping, and integration with identity sources that can tell you which accounts are active, privileged, or unmanaged.

Key questions

Q: What breaks when CASB tools cannot see all SaaS applications?

A: When CASB tools cannot see all SaaS applications, shadow IT, unmanaged sharing, and unknown privileges remain outside policy control. That creates a false sense of coverage because the organisation may be protecting the apps it knows while missing the ones that actually hold sensitive data or create new access paths.

Q: Why do CASB controls matter for non-human identities in SaaS?

A: CASB controls matter for non-human identities because service accounts, API tokens, and delegated app connections can move data without a human session. If those identities are not identified separately, access reviews, DLP policy, and offboarding will treat machine activity like normal user behaviour and miss the real risk.

Q: How do teams know whether CASB visibility is actually complete?

A: Teams know visibility is incomplete when discovery results differ across API, SSO, browser, and endpoint sources, or when unsanctioned apps appear only after an audit or incident. Complete visibility means the same active apps and key identities can be reconciled across the major data sources.

Q: How should organisations decide where CASB fits in the security stack?

A: Organisations should place CASB between identity governance, SaaS access control, and data protection rather than treating it as a standalone cloud tool. The right decision is based on whether the organisation needs app discovery, DLP enforcement, or policy visibility for both human and non-human access paths.

Technical breakdown

CASB visibility and cloud app discovery

A CASB works by observing cloud activity and correlating it with policy, identity, and usage signals. In a SaaS-heavy environment, that usually means discovering sanctioned and unsanctioned applications, then mapping which users or accounts are interacting with them. The technical challenge is that visibility can come from logs, APIs, browser agents, or connected identity systems, and each source has different coverage and latency. If the organisation treats one source as complete when it is not, shadow IT and shadow access remain hidden. The article’s emphasis on real-time visibility reflects this gap in source-of-truth design.

Practical implication: validate which telemetry source actually covers SaaS usage before you rely on CASB output for access decisions.

Data loss prevention and policy enforcement in SaaS

CASB DLP is designed to inspect files and actions for policy violations, often using fingerprinting, context signals, and activity patterns. In SaaS environments, this matters because the sensitive event is often not perimeter-based exfiltration but sharing, uploading, syncing, or downloading inside approved applications. The control only works when policies are aligned to actual data handling paths and when the CASB can see the relevant activity. If those conditions are missing, the tool may detect generic risk while missing the specific data movement that matters to the business.

Practical implication: tie DLP rules to the SaaS sharing and file-handling paths most likely to expose regulated or sensitive data.

Zero trust, SSO, and SaaS access control

The article links CASB to zero trust and identity controls because cloud access is increasingly shaped by user identity, device posture, location, and application state. That is a sign that CASB is no longer just a network control. It becomes part of an access decision stack where SSO, federation, and conditional policy inform whether a session should proceed. This is also where NHI governance enters the picture, because service accounts, API tokens, and integrations often sit outside the user-centric access model even though they create equivalent risk.

Practical implication: review whether your SaaS controls can distinguish between human sessions and non-human credentials before you assume zero trust coverage is complete.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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

NHI Mgmt Group analysis

CASB is now an identity visibility problem, not just a cloud filtering problem. The article repeatedly returns to discovery, sanctioned versus unsanctioned apps, and policy enforcement. That is the real signal for practitioners: the control value of CASB rises or falls with identity context, not with inspection depth alone. Organisations that cannot connect cloud activity back to users, accounts, and privileges will keep missing the access path that matters. The practitioner conclusion is that CASB must be assessed as part of identity governance, not as a separate security box.

Shadow SaaS and unmanaged connections create the same governance risk as shadow NHIs. The article’s focus on visibility gaps, unsanctioned apps, and connected services shows that unmanaged cloud use is an identity issue before it is a data issue. A user session, a third-party app, and a tokenised integration all become part of the same trust chain once policy is enforced through CASB. The practitioner conclusion is that app inventory and identity inventory need to be reconciled continuously.

Policy enforcement breaks when the organisation cannot see the account type behind the action. Human users, service accounts, and delegated integrations all move data in SaaS, but CASB content often collapses them into one activity stream. That hides over-privileged non-human access and makes recertification and offboarding harder to prove. The practitioner conclusion is that access review processes must separate human and non-human SaaS activity before governance can be trusted.

Identity blast radius is the right concept for CASB-led governance. The article’s emphasis on visibility, policy, and integrations points to a broader problem: one weakly governed identity can touch many SaaS tools, data stores, and downstream workflows. That makes blast radius, not just app count, the useful unit of risk. The practitioner conclusion is that CASB programmes should be evaluated on how quickly they reduce the spread of privileged access across the SaaS estate.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• That is why practitioners should pair visibility work with Ultimate Guide to NHIs , Key Challenges and Risks and OWASP Non-Human Identity Top 10 when building control coverage.

What this signals

Identity coverage will become the deciding factor in CASB value. As SaaS estates sprawl, the teams that win are the ones that can reconcile app discovery with identity source-of-truth data and keep it current. The practical next step is to treat CASB outputs as inputs to governance, not as a finished control view.

The next governance gap is cross-domain, not tool-specific. A CASB may flag risky activity, but without parallel controls for NHI lifecycle, offboarding, and access review, the same account can keep reappearing across apps and workflows. That is why programmes need to link SaaS discovery to the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs rather than handle cloud access as an isolated problem.

For practitioners

• Map SaaS discovery to identity sources Confirm which applications, sessions, and accounts your CASB can actually see through API, SSO, browser, and agent-based sources. Use the resulting coverage map to identify blind spots in shadow IT and unmanaged access.
• Separate human and non-human SaaS activity Tag service accounts, API-driven sessions, and delegated app connections differently from end-user sessions so policy, review, and incident response can follow the correct identity type.
• Tie DLP policies to real SaaS data paths Anchor sensitive-data controls to upload, share, sync, export, and cross-app handoff events rather than generic traffic patterns, especially where sanctioned SaaS collaboration is the main exposure point.
• Review zero-trust controls for SaaS integrations Check whether SSO, device posture, and location signals are being applied consistently to third-party app connections and API-linked workflows, not only to interactive user logins.

Key takeaways

• CASB software is most useful when it improves identity visibility across SaaS apps, not when it is treated as a generic cloud filter.
• The article’s core risk signal is unmanaged SaaS usage, because unknown apps and untagged accounts weaken policy enforcement and auditability.
• IAM and NHI teams should evaluate CASB as part of access governance, DLP, and offboarding, especially where integrations and delegated access drive cloud activity.

Key terms

• Cloud access security broker: A cloud access security broker is a control layer that monitors and governs use of cloud applications. In practice, it combines visibility, policy enforcement, and data protection so organisations can manage risky cloud activity without relying only on perimeter security.
• Shadow IT: Shadow IT is the use of software, services, or integrations outside approved governance. In SaaS environments, it usually appears when users connect apps directly, bypassing central inventory, which makes access review, DLP, and offboarding harder to trust.
• Non-human identity: A non-human identity is any machine or software credential used to access systems, including service accounts, API keys, tokens, certificates, bots, and AI agents. Governance depends on inventory, lifecycle control, and privilege boundaries because these identities can operate at scale without direct human supervision.
• Identity blast radius: Identity blast radius is the amount of systems, data, and workflows that can be affected when one identity is compromised or over-privileged. It is a practical risk measure for understanding how far access can travel across SaaS, integrations, and downstream controls.

Deepen your knowledge

CASB visibility, SaaS governance, and identity-driven policy enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is trying to connect cloud app discovery with account governance, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Top 15 CASB Software in 2026. Read the original.