CASB software for SaaS security is really an identity problem

At a glance

What this is: This is a CASB software roundup that argues SaaS security starts with identity and app visibility, not only traffic inspection or policy enforcement.

Why it matters: It matters because IAM, IGA, and SaaS governance teams cannot control access, data exposure, or shadow IT if they do not first know which users, accounts, and app connections are active.

Context

A Cloud Access Security Broker is usually described as a control point between users and cloud services, but the practical governance problem is broader: most SaaS risk sits in discovering what is in use, who is using it, and which connections are already active. In that sense, the article is really about identity visibility across sanctioned and unsanctioned SaaS, not just cloud filtering.

Zluri frames this as a selection problem for CASB software, but the deeper implication is that SaaS security programmes need source-of-truth data before policy enforcement can be trusted. When app usage, access scopes, and third-party connections are opaque, data loss prevention and compliance controls operate with incomplete context.

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 does shadow SaaS create governance risk even when CASB is deployed?

A: Shadow SaaS creates risk because a CASB can only enforce policy on services it can see and classify. Unapproved apps, browser-based access, and direct connections can escape network-centric inspection, which leaves access scope and data movement outside the governance model. Visibility gaps become control gaps.

Q: What signs show that CASB coverage is incomplete in a remote-first environment?

A: Look for app usage that appears in one data source but not another, such as SaaS activity seen in a provider log but missing from gateway monitoring. Missing browser sessions, inconsistent app counts, and unmanaged third-party connections are also strong indicators that your control view is fragmented.

Q: How do compliance teams prove SaaS controls are actually working?

A: They need evidence that combines who accessed what, which apps were in use, and which policy checks were enforced at the time. A policy document alone is not proof. Effective evidence shows the identities, the applications, and the resulting control outcomes together.

Technical breakdown

Why SaaS visibility is the real control surface

CASB is often positioned as a network enforcement layer, but SaaS environments break that assumption because users connect directly to applications from distributed devices and networks. That makes packet inspection and gateway-only monitoring incomplete. Effective SaaS governance depends on application-level telemetry, access data, and usage context so teams can distinguish approved services from shadow IT and see which identities are actually active. Once you lose that inventory, every downstream control, from DLP to compliance policy, is operating blind to part of the estate.

Practical implication: Treat SaaS discovery and identity inventory as prerequisites for CASB policy design, not as reporting after the fact.

Why sanctioned and unsanctioned apps need the same governance view

The article repeatedly contrasts sanctioned and unsanctioned applications because the security problem is not only whether an app is allowed, but whether its identity relationships are understood. A user with a legitimate account can still create risk through unmanaged file sharing, unauthorised app connections, or data movement into an unapproved service. That means SaaS governance has to follow the account, the connection, and the permission scope across the application layer rather than stopping at the perimeter.

Practical implication: Map app usage, access scope, and sharing paths together so governance can see risk in both approved and shadow SaaS.

Why compliance controls depend on identity context

The article ties CASB selection to GDPR, HIPAA, PCI DSS, and ISO 27001 because compliance in SaaS is not only about storage locations or encryption settings. It is also about whether access, activity, and policy enforcement can be demonstrated across the real set of users and applications. Without identity context, audit evidence becomes partial: you may know what a policy says, but not which identities or connections were actually governed by it.

Practical implication: Use identity and application evidence together when assessing whether SaaS compliance controls are truly enforceable.

NHI Mgmt Group analysis

SaaS security is an identity visibility problem before it is a CASB problem: The article’s central point is that policy enforcement cannot outpace incomplete discovery. If teams cannot see which apps, accounts, and connections exist, they cannot govern access consistently. The practical conclusion is that SaaS inventory and identity context belong at the front of the control stack, not behind it.

Shadow SaaS turns CASB into a partial control, not a complete one: Approved applications are only one part of the operating picture. Unapproved services, browser-based access, and direct app integrations can all bypass assumptions built around network-bound inspection. Practitioners should treat unsanctioned SaaS as an identity governance issue because the risk is often unmanaged account creation and data sharing, not just forbidden software.

Visibility across users, apps, and connections is the decisive control variable: The article makes clear that different data sources matter because no single view captures the full SaaS estate. That points to a named concept worth tracking: identity surface visibility. In SaaS governance, the question is not only what traffic passed, but which identities and app relationships were present when it did.

Compliance without identity telemetry is evidence-light governance: Controls such as DLP, access policy, and cloud compliance requirements are only as credible as the underlying usage and access data. If the source of truth is fragmented, teams will struggle to explain who had access, where data moved, and whether controls were applied consistently. The practitioner takeaway is to align governance evidence with identity activity, not just policy intent.

What this signals

Identity surface visibility: SaaS governance is shifting toward a broader inventory problem where access, app usage, and third-party connections must be seen together. Teams that still separate CASB monitoring from identity governance will continue to miss unmanaged app relationships and shadow usage patterns.

The practical test is whether your programme can explain not just which controls exist, but which identities and applications were actually covered when data moved. That requires joining SaaS discovery, access context, and policy evidence into one operating view.

For practitioners

• Inventory SaaS applications from identity and usage data Build a current list of sanctioned and unsanctioned SaaS applications using application telemetry, SSO, and other direct sources so policy starts from actual usage rather than assumptions.
• Correlate users, accounts, and app connections Tie each active SaaS application to the users, service accounts, and third-party connections that can move or expose data, then review that map for unmanaged scope.
• Validate CASB coverage against remote access patterns Test whether your control set still sees app usage when users bypass the corporate network and connect directly from home networks, mobile devices, or browser sessions.
• Align compliance evidence to actual SaaS activity Use access logs, app activity, and policy enforcement evidence together so audit teams can demonstrate which identities were governed, not just which controls were configured.
• Separate approved from shadow SaaS in governance reviews Make every review show whether a service is sanctioned, tolerated, or unapproved, because unmanaged app use often creates the conditions for policy drift and data leakage.

Key takeaways

• CASB is not just a traffic control story. In SaaS environments, the harder problem is knowing which identities, applications, and connections exist before policy can work.
• Shadow SaaS and direct cloud access weaken network-only inspection models because they create governance gaps that conventional perimeter controls cannot fully see.
• Practitioners should anchor CASB decisions in application inventory, identity context, and audit evidence so compliance and DLP operate on the real SaaS estate.

Key terms

• 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.
• Identity Surface: The identity surface is the full set of credentials, tokens, tool permissions, and delegated identities an AI agent can use during execution. It matters because agents often do not operate through a single account, and partial visibility into that surface creates false confidence about control coverage.
• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• SaaS Lifecycle Governance: SaaS lifecycle governance is the set of controls that manage applications from onboarding through access assignment, renewal, and decommissioning. It matters because the security value of SaaS management depends on whether the organisation can prove ownership, revoke access, and retire unused tools on demand.

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.