Cloud Access Security Broker

Most of a modern company's work happens inside software-as-a-service applications — email, documents, CRM, chat, file sharing — running on someone else's infrastructure, reachable from any device, anywhere. The corporate network stopped being the boundary around company data years ago; the boundary is now hundreds of cloud apps, most of which IT never formally approved.

A cloud access security broker (CASB) sits between users and those cloud services as a policy enforcement point: it reveals which apps are actually in use, and applies security and data-protection rules to the ones the organization sanctions.

The problem it solves

The first problem is visibility. Employees adopt cloud tools on their own — a file converter here, an AI assistant there — and each unsanctioned app is a place company data can end up with no contract, no security review, and no way to get it back. Security teams routinely discover their organization uses ten times more cloud apps than they thought.

The second problem is control inside the apps they do sanction. A file share set to "anyone with the link," a customer export synced to a personal account, a sign-in from a stolen credential — none of this crosses a firewall or touches a managed server. The activity lives entirely inside the SaaS provider's platform, where traditional network and endpoint controls simply cannot see.

How it works

Discovery starts with traffic metadata: by analyzing logs from firewalls, proxies, or endpoint agents, the broker identifies which cloud services are being used, by whom, and how much data flows to each — then scores each app's risk so IT can decide what to sanction, tolerate, or block.

For sanctioned apps, enforcement comes in two modes. API-based deployment connects directly to the SaaS provider's management interfaces, inspecting stored files, sharing settings, and user activity out-of-band — easy to deploy and able to see data already at rest, but acting after the fact. Inline deployment routes traffic through a proxy, letting policy block an action — an upload, a download, a share — as it happens, at the cost of more deployment complexity. Most products offer both, layering data-loss-prevention rules, malware scanning, behavior analytics for compromised accounts, and adaptive controls that restrict what a risky session can do rather than blocking it outright.

CASB vs SWG

A secure web gateway also inspects traffic between users and the internet, and the two overlap enough to be confused. The difference is depth versus breadth: a web gateway filters traffic to any destination, deciding mainly whether a site can be visited at all, while a broker understands specific applications — distinguishing a download from a share-setting change inside the same app, and enforcing different rules for corporate versus personal instances of the same service.

In practice the two have converged: most vendors now sell both as components of a security service edge platform, sharing one policy engine.

Choosing one

The buying decision increasingly starts with what you already own: standalone products are rare, and both major suite vendors and SSE platforms include this capability. Evaluate the module against your actual app estate — coverage depth varies sharply beyond the biggest SaaS suites, so test against the long tail of apps your discovery phase turns up. Confirm both deployment modes are real and usable, since API-only offerings cannot block anything in the moment, and check how well identity integration works — adaptive controls are only as good as the risk signals feeding them.