What is a CASB?

A Cloud Access Security Broker (CASB) is a security control point – deployed inline through a gateway or via direct API integration with SaaS providers – that sits between users and cloud applications to give organizations visibility into cloud usage, discover shadow IT, and enforce risk-based access and data-loss-prevention policies on the data moving to, from, and within cloud services.

Key takeaways

• CASB gives visibility into and control over sanctioned and unsanctioned SaaS use.
• Inline CASB inspects traffic in real time; API CASB scans data already at rest.
• Shadow IT discovery classifies each application as Sanctioned or Unsanctioned.
• CASB pairs with DLP and ATP to inspect uploads, downloads, shares, and posts.
• CASB is the SaaS-control component of Security Service Edge (SSE) within SASE.

On this page: Why it matters · How it works · Types · CASB & Versa · FAQ

Why is CASB important?

Once applications moved to SaaS, most of an organization’s data stopped passing through any perimeter the security team controls. Employees adopt cloud tools faster than IT can approve them, and the same corporate domain often serves both the sanctioned business tenant and a user’s personal account, so a login screen alone can’t tell them apart.

CASB closes that gap. It discovers shadow IT – the SaaS applications employees use without IT’s knowledge – and turns each application’s risk profile into an enforceable rule: allow, block, or allow-with-inspection. It then extends enforcement to the data itself, controlling logins, uploads, downloads, and sharing activity so a “sanctioned” application doesn’t become an ungoverned exfiltration path the moment a sensitive file is shared externally.

What is CASB?

A CASB enforces policy using two complementary deployment models. Inline CASB sits in the traffic path – typically as a reverse proxy behind a secure web gateway – inspecting sessions in real time as users log in, upload, download, or share content, and applying an allow, block, or reject action per activity. API CASB instead connects directly to a SaaS tenant’s management API, seeing what inline inspection cannot: data already stored in the tenant and sharing events such as a file made public.

Neither mode alone is complete. Inline CASB can’t see certificate-pinned native apps or browser-cache activity; API CASB can’t intervene on a session in progress. Together they cover real-time access control and at-rest data governance across the same SaaS and IaaS tenants.

Types of CASB

CASB deployments are generally described by where enforcement happens. Forward-proxy CASB routes outbound traffic through an agent or explicit proxy configuration, most common for managed endpoints. Reverse-proxy (inline) CASB intercepts traffic at the gateway without endpoint configuration, inspecting sessions as they pass through – the model behind most agentless, any-device coverage. API-based (out-of-band) CASB connects directly to the SaaS provider’s management API rather than sitting in the traffic path, the only way to inspect data already at rest or sharing changes that never generate live traffic. Mature deployments combine an inline mode with an API-based mode rather than relying on one alone, since each covers scenarios the other structurally cannot.

CASB & Versa

Versa’s CASB is built into the VOS™ data path and delivered as part of the SASE fabric, with both inline and API deployment models. Inline CASB runs as software using VOS deep packet inspection through the Versa Cloud Gateway or a VOS appliance, supporting roughly 80 SaaS applications with a five-band risk classification, configured as CASB profiles attached to an internet protection rule in Director or Concerto.

The API model, configured as API-DP connectors in Concerto, inspects data already stored in a tenant and reacts to sharing events, pairing with DLP and Advanced Threat Protection profiles for remediation. Best practices for CASB security recommends deploying both modes for every in-scope tenant, layering in shadow IT classification and tenant-restriction headers that stop exfiltration to personal cloud accounts. Administrators track activity through the CASB tabs in Concerto’s security dashboards.

Frequently asked questions

What is the difference between inline CASB and API CASB?

Inline CASB sits in the traffic path and inspects sessions in real time as users log in, upload, or share content. API CASB connects directly to a SaaS tenant’s management API to inspect data already at rest, which inline inspection never sees.

Does CASB replace a firewall or secure web gateway?

No. CASB is a complementary control focused specifically on SaaS and cloud-application activity, not general network traffic. It’s typically deployed alongside a secure web gateway and next-generation firewall, often as part of a converged SSE or SASE platform rather than as a standalone appliance.

What is shadow IT, and how does CASB address it?

Shadow IT is cloud application use that happens without IT’s knowledge or approval. CASB discovers which applications are in use, scores their risk, and lets administrators classify each one as Sanctioned or Unsanctioned so that classification can be enforced as an allow or deny rule.

Can CASB protect data already stored in a SaaS application, not just data in transit?

Yes – that’s the role of API CASB. By connecting directly to the SaaS provider’s management API, it scans content already at rest, monitors sharing changes, and can quarantine or remediate violations without needing the traffic to pass through a gateway at all.

How does CASB relate to SASE and SSE?

CASB is one of the core services inside Security Service Edge (SSE), alongside secure web gateway, ZTNA, and DLP. SSE is the security half of SASE, so CASB reaches users as part of the broader SASE fabric rather than as a separate product.

More on CASB

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about CASB, these are worth looking at next.