The average mid-market organisation runs well over 100 SaaS applications. IT typically knows about a fraction of them. Torii’s 2026 SaaS Benchmark Report found that more than 61% of discovered applications in the average enterprise are not formally approved or overseen by IT. Those unsanctioned apps create data leakage risks and compliance blind spots that most teams only discover after something goes wrong.
A Cloud Access Security Broker (CASB) is the technology designed to close that gap. But standalone CASB products are disappearing. Gartner folded the CASB Magic Quadrant into its Security Service Edge (SSE) evaluation several years ago, and major CASB-first vendors have been acquired or absorbed into broader platforms. For most organisations today, CASB capability lives inside a SASE platform. This post explains what CASB does, how it works, and why buying it separately no longer makes sense.
What is a CASB and what does it do?
A Cloud Access Security Broker is a security layer that sits between users and cloud applications. It discovers which SaaS services are in use, enforces access and data-sharing policies, detects risky behaviour, and prevents sensitive data from leaving the organisation through unsanctioned channels. CASB gives IT teams visibility and control over cloud usage that native SaaS security settings cannot provide on their own.
The problem CASB solves: shadow IT and SaaS sprawl
Shadow IT is not a theoretical risk. It is the daily reality of every IT team managing a mid-market organisation.
Microsoft has reported that roughly 80% of employees use non-sanctioned applications to get their work done. The Cloud Security Alliance’s 2025 State of SaaS Security survey found that 55% of employees adopt SaaS tools without involving the security team at all. And Gartner projects that by 2027, three out of four employees will acquire, modify, or create technology entirely outside IT’s oversight.
The numbers become more concrete when you look at actual environments. Organisations believe they run around 90 cloud services. Actual usage often exceeds 1,000. Grip Security’s 2025 analysis of 23,000 SaaS environments found that organisations average 140 AI-enabled SaaS apps alone, most of them adopted without formal evaluation.
That gap between perceived and actual usage is where risk lives. An employee signs up for a file-sharing service using their corporate email. A marketing team starts using an AI writing tool that ingests confidential product briefs. A finance analyst connects a personal cloud storage account to export reports. None of these actions require admin privileges. None of them trigger alerts in traditional security tools.
The consequences are real. AppOmni’s mid-2025 survey found that 75% of organisations experienced a SaaS security incident in the previous twelve months, with a significant share tied directly to unauthorised applications. When you combine tool sprawl with the rise of shadow AI, the attack surface expands faster than any manual governance process can track.
How a CASB works: proxy, API and inline modes
CASB products use three deployment modes to inspect and control cloud traffic. Each has a different role, and modern platforms typically combine them.
| Mode | How it works | What it catches | Limitation |
|---|---|---|---|
| Forward proxy | Routes user traffic through the CASB before it reaches the cloud app | Real-time policy enforcement, inline DLP, access control | Requires an agent or PAC file on endpoints |
| Reverse proxy | Sits in front of the cloud application, intercepting traffic at the app side | Agentless access control, session management | App-specific configuration needed, can break functionality |
| API-based | Connects directly to SaaS platforms via their APIs (e.g. Microsoft Graph, Google Workspace API) | Data at rest scanning, sharing permission audits, retrospective DLP | No real-time blocking, dependent on API coverage |
In a SASE context, the forward proxy and API modes matter most. The forward proxy becomes part of the platform’s inline inspection pipeline, where traffic is decrypted once and inspected by SWG, CASB, DLP and other engines simultaneously. This is what the industry calls single-pass inspection. If you want to understand how that pipeline fits together across all SASE components, Jimber’s SASE architecture guide walks through the full data flow.
The API mode runs in parallel. It connects to sanctioned SaaS platforms to audit sharing permissions, scan stored files for sensitive data, and flag configuration drift. The two modes are complementary, not competing. Inline catches threats in motion. API catches risks at rest.
CASB vs SWG: what each protects and where they overlap
This is one of the most common questions IT teams ask when evaluating cloud security. The short answer: SWG and CASB inspect the same traffic stream but look at different things.
| Capability | SWG | CASB |
|---|---|---|
| Primary focus | Web traffic (all HTTP/HTTPS) | Cloud application activity |
| What it inspects | URLs, domains, content categories, malware signatures | App-level actions: uploads, downloads, shares, API calls |
| Policy examples | Block gambling sites, scan downloads for malware, enforce acceptable use | Block file sharing to personal accounts, detect bulk data exports, restrict guest access |
| Shadow IT detection | Limited (can see which domains are visited) | Strong (identifies specific applications and usage patterns) |
| DLP scope | URL and file-level filtering | Application-aware data classification, content inspection in context |
| Overlap | Both inspect HTTPS traffic, both can block malicious content |
The distinction matters because SWG protects against web threats, while CASB protects against cloud data risks. A Secure Web Gateway will block a user from visiting a known phishing site. It will not stop that same user from sharing a confidential spreadsheet with an external Gmail account through a sanctioned SaaS application.
In a unified SASE platform, both engines share the same policy framework and traffic inspection pipeline. There is no need to choose between them. Policies defined for web access and cloud application control coexist in a single console and apply consistently to all traffic. For a deeper look at how SWG-specific metrics tie into this, the post on SWG metrics that actually matter covers what to measure and why.
Why standalone CASB is disappearing
The CASB market has undergone rapid consolidation. Understanding that trajectory helps explain why buying CASB as a standalone product is increasingly difficult and counterproductive.
Gartner stopped publishing a standalone CASB Magic Quadrant and folded the category into its SSE evaluation. That was not a minor reclassification. It reflected a market-wide recognition that cloud access control cannot be separated from web security, zero trust access, and network-level policy enforcement without creating gaps.
The vendor landscape tells the same story. McAfee’s enterprise CASB business became Skyhigh Security after the consumer-enterprise split. Symantec’s CASB was absorbed into Broadcom’s portfolio. Bitglass was acquired by Forcepoint. Every major standalone CASB vendor has either been acquired or pivoted to offer a broader SSE or SASE platform.
For an IT manager evaluating options today, this has practical implications. Standalone CASB products still exist, but they create integration overhead. You need to feed them traffic (via proxy chains or API connections), maintain separate policy consoles, correlate logs across tools, and manage another vendor relationship. That is exactly the tool-sprawl problem that drives mid-market teams to consolidate in the first place.
The question is no longer “which CASB should I buy?” It is “does my SASE platform include the CASB capabilities I need?”
How CASB works inside a SASE platform
In an integrated SASE platform, CASB is one of several inspection engines in the single-pass pipeline. Traffic from users, sites and devices flows to the nearest point of presence, where it is decrypted once and simultaneously analysed by the SWG, CASB, DLP, firewall and intrusion prevention engines. After inspection, traffic is re-encrypted and routed to its destination.
That architecture eliminates several problems that standalone CASB deployments create.
No separate deployment. CASB activates as a policy toggle, not as a separate appliance or proxy chain. There is no additional infrastructure to install, configure or maintain.
Consistent policy model. The same identity and device posture context that governs ZTNA access decisions also informs CASB rules. When a user connects from a managed device with a valid posture check, they get one set of cloud application permissions. From an unmanaged device, they get a restricted set. One policy engine, one logic.
Single audit trail. All web access events, cloud application activities, DLP detections and access decisions appear in one log stream. This matters for NIS2 and GDPR compliance, where auditors expect to see a coherent picture of who accessed what, when and from where.
Jimber’s SASE platform integrates SaaS visibility, application control and data loss prevention into the same console that manages ZTNA, SWG, FWaaS and SD-WAN. Cloud application discovery runs automatically against all inspected traffic. Policy rules for sanctioned and unsanctioned apps are defined alongside web filtering and access policies. For mid-market teams with three to ten people managing everything from desktops to firewalls, that consolidation is the difference between a capability that gets configured and one that sits unused.
What to look for when evaluating CASB in SASE
Not every SASE platform delivers CASB capabilities with the same depth. When evaluating options, five criteria separate adequate coverage from genuine cloud application security.
SaaS application coverage. The platform should automatically discover and categorise cloud applications based on actual traffic patterns, not just a static catalogue. Look for coverage of at least several thousand applications, including regional and industry-specific tools your teams may use.
Inline and API support. Real-time inline inspection catches threats in motion. API-based scanning audits data at rest in sanctioned platforms like Microsoft 365, Google Workspace and Salesforce. You need both. If a vendor only offers inline mode, you lose visibility into sharing permissions and stored data risks.
DLP integration. Data loss prevention should share the same classification engine as CASB, not operate as a separate module with its own policy console. When a DLP rule detects sensitive data in a cloud upload, the CASB policy should enforce the response automatically.
Compliance reporting. For organisations subject to NIS2 compliance requirements, GDPR or DORA, the platform should generate audit-ready logs that map cloud application activity to regulatory controls. This is particularly relevant for European organisations choosing local SASE alternatives over US-based mega-vendors, where data sovereignty and inspection jurisdiction matter.
Multi-tenant management. For service partners managing multiple customer environments, the CASB capability must work within the platform’s multi-tenant architecture. Separate policies per tenant, consolidated visibility across tenants, and per-tenant reporting are non-negotiable for managed service delivery.
Frequently asked questions
What does CASB stand for?
CASB stands for Cloud Access Security Broker. It is a security technology that sits between users and cloud services to enforce data security, compliance and threat protection policies for SaaS applications.
How does a CASB differ from a firewall?
A firewall controls traffic based on ports, protocols and IP addresses at the network level. A CASB operates at the application level, inspecting how users interact with specific cloud services. It can detect actions like file sharing, bulk downloads and permission changes that a firewall has no visibility into.
Do I need a separate CASB if I have a SASE platform?
In most cases, no. Modern SASE platforms include CASB as an integrated inspection engine. Buying a separate CASB alongside a SASE platform creates duplicate policy consoles, integration overhead and log fragmentation. The exception is if your SASE vendor’s CASB capability is limited, in which case the better answer is usually a different SASE vendor.
Does CASB work with Microsoft 365?
Yes. CASB connects to Microsoft 365 via API (using Microsoft Graph) and inspects traffic inline. API mode audits sharing permissions, scans OneDrive and SharePoint files for sensitive data, and detects configuration changes. Inline mode enforces real-time policies on uploads, downloads and external sharing.
Is CASB required for NIS2 compliance?
NIS2 does not mandate CASB by name. However, NIS2’s requirements for access control, incident detection, supply chain risk management and data protection are difficult to meet without visibility into cloud application usage. CASB provides the SaaS layer of that visibility. For organisations in scope, CASB capability within a SASE platform is a practical way to address multiple NIS2 controls from a single platform.
How does CASB detect shadow IT?
CASB analyses all outbound traffic to identify cloud services in use. It compares observed traffic against a database of known applications and categorises them by risk level, data handling practices and compliance certifications. This gives IT teams a complete picture of which services employees are actually using, compared to the applications that are formally approved.
Jimber’s SASE platform includes cloud application discovery, SaaS policy enforcement and data loss prevention in a single console, alongside ZTNA, SWG, FWaaS and SD-WAN. If your team is evaluating how to get control over SaaS usage without adding another standalone tool, book a demo and see how it works for a mid-market environment.
