SASE CASB is the Cloud Access Security Broker (CASB) function inside a Secure Access Service Edge (SASE) architecture, responsible for cloud visibility, data protection, compliance, and threat defense across cloud applications.
A CASB enforces consistent policy on cloud usage through three deployment modes, forward proxy, reverse proxy, and API, and rests on four pillars: visibility, compliance, data security, and threat protection.
This article defines the CASB, explains how it works inside SASE, covers its deployment modes and Zero Trust role, compares it with the Secure Web Gateway (SWG) and Data Loss Prevention (DLP), and outlines how to choose a platform.
What is a CASB (Cloud Access Security Broker)?
A Cloud Access Security Broker (CASB) is a security control point that sits between users and cloud service providers to enforce enterprise policy on cloud application usage. Gartner coined the CASB category in 2012, and the market consolidated rapidly.
Microsoft acquired Adallom in September 2015 for a reported 250 million USD. Cisco acquired CloudLock in 2016 for 293 million USD. McAfee acquired Skyhigh Networks in January 2018, and Forcepoint acquired Bitglass in October 2021. The consolidation moved the CASB from a standalone product into platform functions, and SASE completed that move by absorbing the CASB as a native component in Gartner's 2019 SASE definition. A CASB governs both sanctioned platforms (Microsoft 365, Salesforce, and Google Workspace) and unsanctioned applications that employees adopt without approval.
How Does a CASB Work Within a SASE Architecture?
A CASB works within a SASE architecture as a control point that intercepts every interaction between users and cloud providers at the SASE enforcement layer. The CASB identifies the cloud application inside the traffic stream, binds the session to the authenticated identity, and evaluates the action, such as login, upload, download, or share, against policy.
Enforcement happens in two directions. Inline, the SASE edge inspects live sessions in the same pass as the SWG and Firewall as a Service (FWaaS). Out of band, API connections to platforms such as Microsoft 365 scan data already at rest. The inline deployment runs in vendor points of presence (PoPs), while distributed architectures such as Zenarmor run their CASB at the organization's own edge, keeping cloud-session inspection inside customer boundaries.
What Role Does a CASB Play in SASE?
The CASB plays the role of the cloud application governor in SASE, covering the four duties of visibility, compliance, data security, and threat protection for Software as a Service (SaaS) and Infrastructure as a Service (IaaS) usage. The CASB executes these duties within the platform's shared identity context, so a risk signal raised by the CASB immediately tightens Zero Trust Network Access (ZTNA) and SWG decisions for the same user. The scope boundary between the component and the full architecture is analyzed in SASE vs CASB.
What are the Four Pillars of CASB in SASE?
Gartner defined the four pillars of CASB as visibility, compliance, data security, and threat protection. They are listed below.
- Visibility: Discovers and inventories cloud application usage across the organization, sanctioned or not (including Shadow IT), and flags which services store or process corporate data. McAfee measured an average of 1,935 cloud services in use per enterprise in 2019, roughly 10 times the IT department's estimate.
- Compliance: Maps cloud usage to regulatory frameworks such as the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA), and the Payment Card Industry Data Security Standard (PCI DSS), and turns cloud adoption into documented, auditable controls.
- Data security: Protects sensitive information in and moving through cloud applications, enforcing DLP policy, monitoring file sharing, and blocking unauthorized exposure.
- Threat protection: Detects malware, compromised accounts, risky behavior, and other cloud attacks that perimeter tools cannot see.
How Does a CASB Provide Cloud Visibility in SASE?
A CASB provides cloud visibility in SASE by classifying every session at the enforcement point against a catalog of tens of thousands of known cloud applications. The CASB sees the complete usage picture rather than the office-only slice that a legacy proxy saw because SASE carries all user traffic, from offices, homes, and mobile devices.
Each discovered application receives a risk score built from attributes such as SOC 2 and ISO/IEC 27001 certification status, breach history, data residency, and encryption practices. Dashboards then report usage by application, user, department, and data volume, which converts anonymous traffic into an auditable inventory. Visibility feeds the compliance pillar because regulators judge what the organization can prove about its data flows.
How Does a CASB Enforce Compliance Within SASE?
A CASB enforces compliance within SASE by translating regulatory requirements into machine-enforced policy on cloud usage. The CASB restricts the personal data of EU residents to platforms and regions that satisfy GDPR requirements, complying with Articles 32 and 44 to 49 on security and cross-border data transfers. The Irish Data Protection Commission reinforced that requirement by issuing a 1.2 billion EUR fine against Meta in May 2023 for transfer violations.
The CASB blocks protected health information from leaving sanctioned tenants, supporting compliance with HIPAA, where the annual penalty cap for repeated violations of a single requirement runs to roughly 2 million USD. The CASB detects primary account numbers in cloud storage and enforces the PCI DSS 4.0 requirements that became mandatory on March 31, 2025.
How Does a CASB Protect Data in a SASE Framework?
A CASB protects data in a SASE framework by applying content inspection and sharing controls to every file and message that touches a cloud platform. The CASB scans uploads and downloads against DLP classifiers for patterns such as the 16-digit primary account number validated by the Luhn algorithm, national identifiers, and source code. API scans sweep data at rest in sanctioned tenants out of band and remediate exposure by revoking public links, quarantining files, or applying encryption.
Sharing policy enforces rules such as blocking external sharing of files labeled Confidential in Microsoft Purview or Google Drive. Deep classification is handled by the DLP engine covered in the SASE DLP guide, which the CASB invokes in the same single-pass inspection. Data protection closes the accidental loss paths; threat protection closes the deliberate ones.
How Does a CASB Detect Threats in SASE Traffic?
A CASB detects threats in SASE traffic by combining behavioral analytics on cloud sessions with content scanning of cloud-borne files. User and entity behavior analytics (UEBA) baselines each account's normal geography, device set, and data volume, then flags anomalies such as an impossible travel login from two countries within one hour or a 10 GB download at 03:00.
Auth governance detects malicious third-party app grants, the technique behind consent-phishing campaigns that Microsoft has repeatedly documented since 2020. Sandboxing and signature engines scan files in cloud storage, catching malware that entered through a personal sync client. A detection can trigger step-up multi-factor authentication (MFA) or session termination in ZTNA within the same platform because the CASB shares the SASE identity plane.
What are the CASB Deployment Modes in SASE?
A CASB attaches to cloud traffic in three ways, listed below.
- API-based: Connects directly to sanctioned cloud apps through their management APIs to inspect data at rest, check configuration risk, and enforce policy without adding latency. It covers only API-exposing apps and acts after the fact.
- Forward proxy: Inspects user traffic inline before it reaches cloud apps, routing it through the CASB from the SASE agent or edge to monitor sanctioned and unsanctioned apps and block violations in real time.
- Reverse proxy: Places sanctioned apps behind the CASB and rewrites sessions to inspect unmanaged and bring-your-own-device (BYOD) endpoints without an agent, at the cost of ongoing app-compatibility maintenance.
Mature SASE platforms run API and forward proxy modes together, a setup called multimode CASB.
How Does a CASB Protect SaaS Applications Under SASE?
A CASB protects SaaS applications under SASE by pairing inline session control with API-based hygiene on each sanctioned tenant. The forward proxy distinguishes the corporate Microsoft 365 tenant from personal accounts on the same domain, blocks uploads of classified data to unsanctioned services, and strips risky actions from tolerated applications. The CASB audits tenant configurations against benchmarks such as the Center for Internet Security (CIS) Microsoft 365 Foundations benchmark, while detecting public sharing links and removing malware from OneDrive, SharePoint, and Google Drive through APIs. The division of duties follows the shared responsibility model of Cloud Security: the provider secures the application, and the CASB enforces the customer's share on identities, data, and configuration.
How Does a CASB Support Zero Trust in SASE?
The CASB strengthens Zero Trust in three ways, listed below.
- Granular access control: Enforces action-level permissions inside cloud sessions, allowing low-risk actions (viewing) while blocking download, copy, or share on unmanaged devices, so least privilege extends past authentication.
- Continuous monitoring: Evaluates user and device behavior throughout an active session, applying the continuous-verification principle of NIST SP 800-207 (August 2020) to catch risk changes after login.
- Unified policy: Shares identity, device, and risk context across CASB, ZTNA, and SWG, so a CASB detection raises the user's risk score and lets connected SASE services tighten or revoke access.
How Does a CASB Detect Shadow IT in a SASE Environment?
A CASB detects Shadow IT in a SASE environment by fingerprinting every cloud destination in the traffic and comparing the discovered inventory against the sanctioned list. Detection draws on Transport Layer Security (TLS) metadata such as Server Name Indication (SNI), DNS queries, and application signatures, so it identifies services even without full decryption. The gap is consistently large: discovery projects typically reveal 3 to 10 times more cloud services than IT records, in line with the McAfee figure above. Distributed SASE architectures such as Zenarmor perform this discovery at the local edge with the same deep packet inspection (DPI) engine that enforces policy, so Shadow IT is detected without exporting traffic metadata to an external cloud. Discovery output feeds graduated policy: sanction, tolerate with restrictions, or block.
What is the Difference Between CASB and SWG in SASE?
The difference between CASB and SWG in SASE is the object of control: the CASB governs cloud applications and their data, while the SWG governs web traffic and its threats. The table below compares the two across 5 attributes.
| Attribute | CASB | SWG |
|---|---|---|
| Control object | SaaS and IaaS applications | Web destinations and content |
| Core question | What happens inside cloud apps | Which web traffic is safe and allowed |
| Key mechanisms | API scans, app risk scores, session control | URL filtering, TLS inspection, malware blocking |
| Data focus | Data at rest and in motion | Data in the web channel |
| Category origin | Gartner, 2012 | Proxy market, 1990s to 2000s |
The two run in the same pass and hand off to each other in SASE: the SWG classifies the destination, and the CASB takes over when the destination is a cloud application.
What is the Difference Between CASB and DLP in SASE?
The difference between CASB and DLP in SASE is that the CASB is a control point for cloud applications, while DLP is a content-inspection engine that any control point invokes. DLP classifies data, deciding that a file contains 340 credit card numbers or a patient record; the CASB decides what that classification means for a specific cloud action, such as blocking an upload to an unsanctioned tenant. DLP is a shared engine, not a CASB feature. The same engine plugs into several control points: the CASB inspects cloud uploads and sharing, the SWG inspects web uploads, and email security inspects attachments. In a converged SASE platform they all call that one engine, so the same data-classification rules apply consistently across cloud, web, and email.
Is a CASB Required for SASE?
Yes, a CASB is required for SASE because Gartner's SASE definition lists CASB among the core security service edge functions alongside SWG and ZTNA. A platform without cloud application control cannot govern the SaaS estate that dominates enterprise traffic. The practical qualifier is sequencing: organizations activate the CASB in phases, commonly starting with API mode on Microsoft 365 before enabling full inline control.
Is CASB the Same as SASE?
No, CASB is not the same as SASE, because CASB is one security function, and SASE is the converged architecture that contains it together with software-defined wide area networking (SD-WAN), SWG, ZTNA, and FWaaS. The standalone CASBs of the 2012-2018 market generation solved cloud control in isolation. SASE, defined in the framework covered by SASE Solutions, solves it as part of one policy plane. Gartner predicts that by 2026, 85% of organizations buying CASB, SWG, or ZTNA will buy them from a converged platform.
How to Choose a CASB Solution for SASE?
Choosing a CASB solution for SASE is a 5-step evaluation that tests the function inside the platform rather than as a standalone product.
- Verify multimode coverage: Confirm API, forward proxy, and reverse proxy support, because single-mode CASBs leave either data at rest or unmanaged devices unprotected.
- Count API integrations: Check depth against the organization's sanctioned stack, including Microsoft 365, Google Workspace, Salesforce, ServiceNow, and Slack, since integration counts range from a dozen to several hundred across vendors.
- Test discovery accuracy: Run a 2-week pilot, comparing the discovered application inventory and risk scores against a known sample of unsanctioned usage.
- Evaluate the shared DLP engine: Measure false-positive rates on the organization's own document set rather than vendor benchmarks.
- Confirm single-pass integration: Check that CASB, SWG, and ZTNA decisions share one identity context and one console, the property that separates converged SASE from stitched portfolios.
Score step 5 highest, because a CASB that operates as a bolted-on proxy recreates the tool sprawl that SASE consolidation exists to end.