CASB in Plain Terms: Governing SaaS

By Taylor Thomas · 2026-08-31

Ask a firewall’s flow logs what your organization is doing in the cloud and you get an honest but shallow answer: thousands of allowed HTTPS connections to reputable domains. To flow- and URL-level policy, the employee sharing a customer list from a personal cloud-storage account and the employee doing legitimate work in the corporate tenant of the same service look nearly identical — telling them apart takes deeper measures such as TLS inspection with application-level and instance-aware controls. A cloud access security broker is the product category built around exactly that blind spot: policy enforced over cloud-service use, operating on the units that matter for SaaS — the application, the tenant, the account, the action, and the data.

The Gap Between Allowed and Governed

SaaS adoption inverted a quiet assumption of perimeter security: that applications live somewhere IT controls. When the application is someone else’s multi-tenant service, “allow HTTPS to it” and “govern what happens inside it” become different problems. A secure web gateway mediates the web session and can filter by URL and content, but the deepest tenant-level questions — who has this file been shared with, which third-party app holds an OAuth grant into our tenant, is a sanctioned account misconfigured — need a control that understands the application as an application. That is the CASB’s job description, often summarized in the industry’s four-pillar framing: visibility, data security, threat protection, and compliance.

API or Inline: Two Ways to Stand Between

The architecture question that shapes every CASB deployment is where the broker actually stands. API-based deployment integrates out-of-band with a sanctioned application’s own interfaces. Nothing sits in the traffic path; the CASB reads the tenant from the inside — files at rest and their sharing permissions, user activity logs, configuration, connected third-party apps. The visibility is deep — including activity that never crosses your network at all, such as cloud-to-cloud sharing — though what is exposed, and how quickly, depends on each provider’s APIs and the scopes granted. The limits are equally structural: it works only for applications and tenants where the organization can authorize the required API access, and it observes after the fact — with latency shaped by the provider’s event or polling mechanisms and the CASB’s own processing — rather than standing in front of the action.

Inline deployment puts the broker in the traffic path — commonly as a forward proxy sharing the steering infrastructure of the SWG — where it sees traffic to cloud services generally, sanctioned or not, provided the traffic is steered through it and is inspectable, and can block an action while it is happening: this upload, this download, this login to a personal instance. The costs are the proxy’s usual ones — being in the trust path, coverage bounded by what steering actually captures, and, for encrypted traffic, TLS decryption generally required for content-level decisions (coarser verdicts by destination, identity, or application category can be made without decrypting). The two modes cover each other’s gaps, which is why mature deployments commonly run both: API for depth inside the apps you own, inline for breadth and the real-time veto.

Starting With Shadow IT

Most organizations first meet CASB through discovery. Shadow IT analysis ingests the egress telemetry you already have — firewall and proxy logs carrying real usage evidence, DNS logs adding breadth — and resolves it against a catalog of cloud services, turning undifferentiated outbound traffic into an inventory: which services, roughly how much use, and a vendor-assessed risk profile your own review still has to validate. The point is not to generate a wall of shame; it is to make sanctioning decisions with evidence. Some discovered apps get blessed and brought under API governance, some get tolerated with inline guardrails, and some get blocked. Governance then extends past the apps themselves to what they connect to: third-party applications granted OAuth access into a sanctioned tenant can retain permissions or refreshable access well beyond the interactive session that approved them, and API-integrated CASB is one of the practical ways to inventory and revoke grants that ordinary flow logs cannot reliably reveal. The same discovery muscle is now doing fresh work on unsanctioned AI tools, where the governance question is the subject of shadow AI visibility.

Where CASB Lives Now: SSE

CASB began as a standalone product category, but its steering problem — getting user traffic to the enforcement point from anywhere — is the same one that pushed the web gateway into the cloud. The security service edge answer converges them: CASB, secure web gateway, and zero trust network access commonly delivered through one converged cloud platform, sharing identity, policy, and steering, the architecture unpacked in SASE vs SSE. On the blueprints this site teaches, the topic appears twice: SCOR 350-701 v2.0 names Cloud Access Security Broker among cloud security solutions (objective 3.3), and the SCAZT 300-740 Access domain takes it to configuration level with configuring CASB (objective 4.4). The SCAZT course treats it accordingly — not as a product tour, but as the governance layer SaaS was always going to need.

Frequently Asked Questions

My firewall and secure web gateway already filter web traffic. What does a CASB add?

A different unit of control. Baseline firewall and SWG policy makes verdicts about connections and URLs; at that level, an employee syncing customer data to a personal cloud drive and an employee using the sanctioned corporate tenant of the same app look nearly alike — allowed HTTPS to a reputable domain. (Modern NGFW and SWG platforms can reach further with TLS inspection and tenant restrictions — CASB-style capability converging into those products.) A CASB works at the application and tenant level: which account, which instance, which action, which data. That is where questions like personal-versus-corporate instance, risky OAuth grants, and sensitive-file sharing live.

API-based or inline CASB — which do I need?

They answer different questions. API integration inspects a sanctioned app from the inside — data already at rest, sharing permissions, activity logs — without touching the traffic path, but only for apps and tenants where you can authorize the API access, and it observes with latency that depends on the provider's event mechanisms and the CASB's collection model. Inline deployment sees steered traffic as it flows, including to apps you have not sanctioned, and can block an upload in the act, but it must be in the path, and content-level verdicts on encrypted traffic generally require TLS decryption. Mature deployments commonly combine both: API for depth in sanctioned apps, inline for breadth and real-time control.

Where does CASB appear on Cisco certification blueprints?

In two places. The SCOR 350-701 v2.0 blueprint names Cloud Access Security Broker in objective 3.3, whose task is selecting security solutions for cloud environments. The SCAZT 300-740 blueprint goes further: objective 4.4 is configuring CASB, sitting in the Access domain alongside secure web gateway and related edge services.