What Is a CASB (Cloud Access Security Broker)?

A finance team starts paying for a file-sharing app on a corporate card. Nobody tells security. Six months later an analyst pulls the egress proxy logs during an incident and finds 40 distinct cloud services in use, half of which IT never sanctioned, one of which holds a copy of the customer database. No malware. No exploit. Just data walking out the front door of sanctioned and unsanctioned SaaS, with no control in the path to see it or stop it.

A Cloud Access Security Broker (CASB) is the control that sits in that path. It is a policy enforcement point placed between users and the cloud services they use, so that enterprise security policy follows the data into SaaS instead of stopping at the network edge. This guide covers what a CASB is and where the term came from, the four pillars of capability it is built on, the three ways it gets deployed and the tradeoffs of each, what it actually solves, and how it differs from a secure web gateway, DLP, and the SSE/SASE architectures that absorbed it. It is the cloud-facing layer of a broader cloud security program. It is written for the people who answer for cloud data: SOC analysts, threat hunters, and DFIR responders who have to reconstruct what an account did across a dozen SaaS tenants.

What is a Cloud Access Security Broker (CASB)?

A CASB is a security policy enforcement point, on-premises or cloud-hosted, that sits between cloud service consumers and cloud service providers and applies enterprise security policy as cloud resources are accessed. Gartner coined the term in 2012 and defined it that way: the broker interjects policy at the moment a user touches a cloud service, so controls that used to live on the corporate network now travel with the request into a SaaS application the organization does not own or run.

That positioning is the whole point. The traditional security stack assumed traffic crossed a network perimeter you controlled, where a firewall, a proxy, and a DLP engine could inspect it. SaaS broke that assumption. A user on a home network opening a browser tab to a cloud app never crosses your perimeter, so none of those controls see the session. A CASB re-inserts a control point into that flow, either by sitting inline in the traffic or by connecting to the cloud provider's own API, and enforces policy from there.

A CASB is not a single appliance you bolt on. It is a set of capabilities delivered through one of several deployment patterns, governing both sanctioned apps (the SaaS your organization pays for and administers) and unsanctioned ones (the shadow IT a CASB is often bought to find). The capabilities are what the next section covers.

The four pillars of a CASB

CASB capability is conventionally organized into four pillars. The grouping comes from Gartner's CASB research, not its one-line glossary definition, but it has become the standard way vendors and practitioners describe what a CASB does. The pillars answer four different questions about cloud usage.

Visibility answers "what cloud is even in use here?" A CASB ingests logs from firewalls and proxies to discover every cloud service touched from the environment, sanctioned or not, and builds an inventory with a risk rating per app. This is the shadow IT discovery that drives most initial CASB purchases. It also extends to visibility inside sanctioned apps: which users, which files, which sharing settings, which third-party OAuth grants.

Compliance answers "does this cloud usage meet the rules we answer to?" The CASB maps cloud data and configuration against regulatory and internal requirements, flags data residency or handling violations, and reports on which apps store regulated data. It is the pillar that turns "we use 200 SaaS apps" into "these 12 hold data subject to GDPR or HIPAA, and three of them are misconfigured."

Data security answers "is sensitive data leaving or sitting exposed in cloud apps?" This is where the CASB embeds data loss prevention: it inspects content moving to and within cloud services, applies DLP policy, and can encrypt, tokenize, quarantine, or block. A CASB does not replace an enterprise data loss prevention (DLP) program; it extends DLP enforcement into the cloud channel where a network DLP engine has no visibility.

Threat protection answers "is this cloud activity malicious?" The CASB watches cloud usage for compromised accounts, insider misuse, and malware moving through SaaS. It baselines normal behavior per user and flags anomalies: an account downloading the entire document store, a login from an impossible location, a sudden mass-share to external addresses. This pillar is the one a SOC consumes directly, because it produces the alerts and the telemetry an investigation runs on.

Most products lead with one pillar and grow into the others. A discovery-first tool starts in visibility; a data-protection tool starts in data security. The pillar a given CASB is strong in is usually a clue to which deployment mode it was built around, which is the next decision.

CASB deployment modes: API, forward proxy, reverse proxy

A CASB enforces policy in one of three ways, and the choice is not cosmetic. It decides what the CASB can see, what it can block in real time, and which devices it can cover. Most mature deployments use more than one mode at once, because each covers a gap the others leave open.

API-based (out-of-band). The CASB connects to the cloud provider's management API and inspects data already sitting in the SaaS tenant: files at rest, sharing settings, configuration, audit events. It sees inside sanctioned apps deeply and without touching user traffic, so it adds no latency and needs no agent. The tradeoff is timing. API inspection is near-real-time at best and often retroactive, so it scans data after it lands rather than blocking it in the request. It also works only for apps that expose an API the CASB supports, which excludes the long tail of unsanctioned SaaS.

Forward proxy (inline). The CASB sits in the outbound path and inspects traffic as it leaves, before it reaches the cloud service. Because it is inline, it can block in real time and cover any cloud destination, sanctioned or not. The cost is reach: a forward proxy needs the endpoint routed through it, usually via an agent or device configuration, which in practice limits it to managed devices. An unmanaged or personal device that bypasses the agent bypasses the control.

Reverse proxy (inline, agentless). The CASB integrates with the identity provider and SSO flow, so sessions to sanctioned apps are redirected through the broker without any agent on the device. That makes it the mode for unmanaged and BYOD access, where you cannot install software. The tradeoff is fragility and scope: reverse proxy can break with applications that hardcode URLs or use non-standard domains, and because it rides the SSO login it covers only the sanctioned apps wired into the identity provider, not shadow IT.

Deployment modes compared

The table makes the layering obvious. API mode owns data at rest and configuration but cannot block inline. Forward proxy blocks inline on managed devices but misses BYOD. Reverse proxy reaches BYOD but only for sanctioned apps. No single mode covers everything, which is why a real CASB deployment runs API plus at least one proxy mode and accepts that the seams are where coverage gaps live. For a defender, knowing which mode produced a given log matters: an API-sourced event is a snapshot of state, while a proxy event is a record of a request in flight.

What a CASB solves

A CASB earns its place by closing four specific gaps that opened when work moved to SaaS.

Shadow IT discovery. The original driver. Pull the proxy and firewall logs, resolve them against a catalog of known cloud services, and you get an inventory of every app in use with a risk score. The finance team's unsanctioned file-sharing app shows up here, and so do the unsanctioned AI tools employees are pasting source code into. Discovery is the first thing most organizations get from a CASB and often the thing that justifies it.

SaaS data control. Once you know which sanctioned apps hold sensitive data, the CASB enforces what can be done with it: block external sharing of files tagged confidential, quarantine a public link, encrypt regulated data before it lands, stop a download to an unmanaged device. This is DLP enforcement in the one channel a network-edge control cannot reach.

Access and usage policy. The CASB applies conditional rules to cloud sessions: allow read but not download from an unmanaged device, block uploads to a personal instance of a sanctioned app while allowing the corporate tenant, require step-up authentication for sensitive actions. It is access control expressed at the cloud-session layer rather than the network.

Threat detection on cloud usage. This is the defender's pillar. The CASB produces the telemetry that lets a SOC see a compromised SaaS account: anomalous downloads, impossible-travel logins, mass external sharing, OAuth grants to malicious third-party apps. Without it, a compromised cloud account leaves almost no trace in the on-premises tooling a SOC traditionally watches, and the first sign of trouble is the data breach notification.

CASB vs SWG vs SSE/SASE vs DLP

The acronyms around CASB overlap enough to confuse, and they have shifted as the market consolidated. Here is how they actually relate.

CASB vs SWG. A secure web gateway inspects and filters web traffic in general: URL categorization, malware scanning, web policy on HTTP and HTTPS. A CASB governs cloud and SaaS specifically: which apps, which data, which actions, with awareness of the app's own objects and sharing model. An SWG sees that a user went to a domain; a CASB sees that the user shared a confidential file externally inside the SaaS app behind that domain. They are complementary, and in modern architectures they are siblings rather than competitors.

CASB vs DLP. DLP is a data-protection discipline and engine: identify sensitive data, then prevent it from leaving. CASB is broader. Data security is one of its four pillars, and a CASB embeds DLP to enforce it in the cloud channel, but the CASB also does discovery, compliance, and threat detection that a standalone DLP product does not. The clean way to say it: DLP is a capability; a CASB is a control point that uses DLP as one of its capabilities, applied where network DLP is blind.

CASB and SSE/SASE. This is where CASB stopped being a standalone product for most buyers. Gartner introduced Secure Access Service Edge (SASE) in 2019 as a model that converges networking and security into a single cloud-delivered service. In 2021 it named the security half of that model Security Service Edge (SSE), which bundles three controls: CASB, SWG, and Zero Trust Network Access (ZTNA), often with cloud firewall alongside. SASE is SSE plus the network side (SD-WAN). The practical effect is that CASB is now usually one feature of an SSE platform rather than a product you buy on its own, sharing a policy engine and a log pipeline with the secure web gateway and ZTNA next to it. The capability did not go away; it got absorbed.

How defenders use a CASB

For a blue team, a CASB is less a thing you configure once and more a source of evidence and control you reach for during hunts and investigations. Three uses recur.

The first is reconstruction. When a SaaS account is compromised, the CASB log is often the only place the activity is recorded: which files were accessed, what was downloaded, what was shared externally, what sharing links were created, which OAuth apps were granted access. On-premises tooling never saw the session, so the CASB is the system of record for "what did this account do in the cloud?" An investigation that ignores it is reconstructing the cloud half of an incident blind.

The second is detection. The threat-protection pillar feeds anomalies into the SIEM: impossible-travel logins, mass downloads, bulk external sharing, first-seen OAuth grants. These are high-signal events because legitimate users rarely do them, and they catch the cloud-native attack patterns, account takeover and data exfiltration through SaaS, that endpoint and network tooling miss. Routing CASB alerts into the same triage queue as everything else is what turns the CASB from a compliance checkbox into a detection source.

The third is reducing the attack surface before an incident. Discovery output is a worklist: every unsanctioned app with sensitive data is a gap to close, every misconfigured sharing setting is exposure to fix, every stale OAuth grant is standing access to revoke. Working that list shrinks what an attacker can reach in the cloud, which is the same least-privilege discipline a defender applies everywhere, expressed in the SaaS layer.

The bottom line

A CASB is the policy enforcement point between users and cloud services, the control that puts security back in a path that SaaS routed around the corporate perimeter. Gartner coined the term in 2012, and its capability is organized into four pillars: visibility into which apps are used, compliance against the rules, data security through embedded DLP, and threat protection on cloud activity. It enforces through three deployment modes, API, forward proxy, and reverse proxy, each covering a gap the others leave, which is why real deployments combine them.

The market has since folded CASB into Security Service Edge alongside the secure web gateway and ZTNA, and SSE into SASE, so today CASB is usually a feature of a larger cloud-delivered platform rather than a product on its own. The capability is unchanged. For a defender, the CASB is the system of record for cloud-account activity and a high-signal detection source for account takeover and SaaS data exfiltration, the half of an incident that on-premises tooling never sees.