The problem: data leaves IT's field of view
When corporate applications ran in a company's own data center, IT had direct control over them — it owned the servers, the network, and the firewall around them. The moment most work moves into third-party SaaS applications (Microsoft 365, Salesforce, Google Workspace, Slack, Dropbox, and dozens of others), that direct control disappears. Data now lives in someone else's infrastructure, accessible from anywhere, often even from employees' personal devices.
On top of that comes the phenomenon of shadow IT — employees signing up for cloud tools on their own, without IT's knowledge, simply because it makes their work easier. As a result, a company can genuinely be using several times more cloud services than its security team is even aware of.
What a CASB does
A CASB (Cloud Access Security Broker) is a security policy enforcement point inserted between users (and their devices) and cloud service providers. Gartner defines its function around four pillars:
| Pillar | What it provides |
|---|---|
| Visibility | Reveals which cloud applications are actually being used across the company — including unapproved shadow IT |
| Compliance | Checks whether cloud service usage meets regulatory requirements (e.g. GDPR) and internal policies |
| Data Security | Enforces encryption, controls sharing, and often integrates with DLP to protect sensitive content |
| Threat Protection | Detects malicious behavior — e.g. unusual logins, mass file downloads, malware uploaded to cloud storage |
Two deployment approaches
A CASB gets "in between" the user and the cloud service in one of two fundamentally different ways:
- API-based CASB — connects directly to the cloud application's API and analyzes data stored "at rest," without sitting in the traffic path. It works retroactively — able to flag a problem even in files that already exist, but with a slight delay compared to real time.
- Proxy-based CASB — acts as a forward or reverse proxy that traffic passes through in real time. This lets it block a risky action (e.g. uploading a sensitive file) before it even completes, but requires routing traffic through the proxy, which can be harder to deploy and only covers services that can be routed that way.
Most modern CASB solutions combine both approaches — proxy-based for real-time control over the main, sanctioned applications, and API-based for retroactive checks and detecting shadow IT across a wider range of services.
Typical use cases
- Shadow IT discovery — by analyzing network logs, a CASB finds out which cloud services employees are actually using, even ones IT never knew about.
- File-sharing control — preventing a corporate document from being shared publicly or with an unapproved personal account.
- Login anomaly detection — for example, a login to a corporate Microsoft 365 account from two geographically distant locations within a short time window.
- Non-compliant device control — restricting access to sensitive data from personal or unsecured devices.
CASB as part of SASE
Like ZTNA, a CASB today is most commonly deployed as an integrated part of a broader SASE architecture, sharing infrastructure and policy with the other security components rather than operating as a standalone, separately managed solution.
CASB frequently overlaps with DLP (Data Loss Prevention) functionality — while DLP generally focuses on the content of data regardless of channel, the DLP capability inside a CASB is specifically focused on what's happening to data within cloud and SaaS applications themselves.
Summary
CASB emerged as a response to the loss of direct control over data that came with moving corporate applications into third-party clouds. By positioning itself as a visible or invisible control point between users and SaaS services, it hands security teams back what they lost in that move to the cloud — an overview of which cloud services are even in use, control over how sensitive data is handled within them, and the ability to catch suspicious behavior before it causes harm.