Cloud Access Security Broker (CASB)

A Cloud Access Security Broker (CASB) is a security enforcement point positioned between enterprise users and cloud service providers, applying visibility, compliance, data security, and threat protection policies to cloud-bound traffic and data. This page covers the functional architecture of CASB platforms, the regulatory context driving adoption, classification distinctions among deployment models, and the known tensions inherent in CASB implementations. It serves as a reference for security architects, procurement professionals, and compliance teams navigating the cloud security service landscape.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix

Definition and scope

The Cloud Security Alliance (CSA) defines a CASB as software or hardware that sits between cloud service consumers and cloud service providers to enforce security, compliance, and governance policies over cloud-based resources. Gartner popularized the term in 2012, and the category has since been formalized within enterprise security architectures globally.

CASB scope spans four functional pillars — visibility, compliance, data security, and threat protection — originally articulated by Gartner and broadly adopted as the canonical framework across vendor and standards communities. Visibility encompasses discovery of sanctioned and unsanctioned cloud application usage (commonly called "shadow IT"). Compliance addresses regulatory policy enforcement, including controls mapped to frameworks such as NIST SP 800-53 and ISO/IEC 27001. Data security includes data loss prevention (DLP) and encryption for data in transit and at rest. Threat protection involves detection of compromised accounts, insider threats, and malware propagation across cloud storage.

The scope of a CASB deployment extends across Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) environments, as defined in NIST SP 800-145. In practice, SaaS protection — particularly for platforms such as Microsoft 365, Salesforce, and Box — represents the dominant use case in enterprise deployments.

Core mechanics or structure

CASB platforms operate through 3 primary enforcement mechanisms: API-based integration, forward proxy, and reverse proxy.

API-based (out-of-band) integration connects directly to cloud service provider APIs using OAuth tokens or administrator credentials. This model provides post-event visibility and governance — scanning existing data, reviewing activity logs, and applying DLP policies retroactively. It does not intercept real-time traffic. API integration is the dominant model for sanctioned SaaS governance because it requires no network redirection.

Forward proxy (inline) routes all outbound user traffic through the CASB before reaching cloud destinations. This enables real-time blocking, session control, and policy enforcement at the moment of access. Forward proxy deployments typically integrate with Secure Web Gateway (SWG) infrastructure or operate as cloud-delivered proxy services under a Secure Access Service Edge (SASE) architecture, as described by the Cloud Security Alliance SASE guidance.

Reverse proxy intercepts traffic between the user and a specific cloud application, enabling session-level controls without requiring a device agent. It applies to unmanaged device scenarios — third-party contractors, BYOD environments — where installing an endpoint agent is not feasible.

Enterprise deployments frequently combine all 3 mechanisms, applying API integration for sanctioned SaaS governance, forward proxy for real-time policy enforcement on managed devices, and reverse proxy for unmanaged device access to critical applications.

Within these mechanisms, the core policy enforcement engine applies rules across identity context (user role, group membership, authentication state), device posture (managed vs. unmanaged, compliance status), application risk scoring (typically derived from cloud application catalogs rating 50+ attributes), data classification labels, and geographic origin.

Causal relationships or drivers

The regulatory and threat environment provides the primary structural pressure accelerating CASB adoption. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule (45 CFR §164.312) requires covered entities to implement technical safeguards controlling access to electronic protected health information (ePHI) transmitted or stored in cloud environments — a requirement that CASB API integration directly addresses for SaaS platforms handling clinical data. The Federal Risk and Authorization Management Program (FedRAMP) mandates continuous monitoring controls for federal cloud deployments, creating explicit demand for the visibility and audit logging capabilities CASB provides.

The Payment Card Industry Data Security Standard (PCI DSS), administered by the PCI Security Standards Council, requires organizations to restrict access to cardholder data — a control that CASB DLP policies enforce across cloud storage and collaboration tools.

Shadow IT discovery is the operational driver most frequently cited by security teams deploying CASB. Enterprise employees access cloud services outside IT-approved channels at rates that consistently exceed internal estimates; the Cloud Security Alliance 2022 SaaS Security Survey found that 35% of respondents identified shadow IT as a top SaaS security concern. CASB forward proxy and DNS-layer integration provide the instrumentation to identify this unsanctioned usage.

Zero Trust architecture frameworks — particularly NIST SP 800-207 — position CASB as one enforcement component within a broader policy decision point (PDP) / policy enforcement point (PEP) model, driving integration between CASB, identity providers, and endpoint management platforms.

Classification boundaries

CASB classification boundaries align along 3 axes: deployment architecture, functional scope, and coverage model.

By deployment architecture: On-premises CASB appliances were the original form factor; cloud-delivered CASB (SaaS-based) is now the predominant model. Hybrid deployments retain on-premises components for data residency or latency requirements.

By functional scope: Single-pillar CASB focuses on one primary function — most commonly DLP or shadow IT discovery — and is often embedded within a broader security platform rather than deployed as a standalone product. Full-pillar CASB implements all 4 of the Gartner-defined pillars across API, forward proxy, and reverse proxy modes.

By coverage model: Application-centric CASB governs a defined set of sanctioned applications through API integration. Traffic-centric CASB inspects all cloud-bound traffic regardless of application. The two models are architecturally distinct: application-centric integration does not require network routing changes; traffic-centric inspection requires proxy infrastructure.

CASB is distinct from — but frequently integrated with — adjacent categories: Cloud Security Posture Management (CSPM) focuses on IaaS/PaaS configuration hygiene rather than user access and data flows; Secure Web Gateway (SWG) governs general web traffic rather than cloud-application-specific policy; and Cloud Workload Protection Platforms (CWPP) protect server workloads rather than user-to-application data paths. The cloud security providers on this site provide provider-level detail organized by these functional categories.

Tradeoffs and tensions

Visibility vs. privacy: CASB inline inspection of user traffic creates organizational tension between security visibility and employee privacy. In unionized environments or jurisdictions governed by data protection regulation — including the EU General Data Protection Regulation (GDPR) under Regulation (EU) 2016/679 — scanning personal communications routed through a forward proxy may require data protection impact assessments and formal legal basis documentation.

Performance vs. coverage: Inline proxy inspection introduces latency. Reverse proxy architectures in particular can add 50–150 milliseconds of round-trip latency for session-heavy applications, which affects real-time collaboration tools. Organizations with latency-sensitive workloads face a direct tradeoff between full inline coverage and application performance.

Integration complexity vs. breadth: Comprehensive CASB deployments require integration across identity providers (IdP), endpoint management (MDM/UEM), SIEM platforms, and individual SaaS API endpoints. Each integration point introduces a dependency that increases operational complexity and potential failure surface. Single-vendor SASE bundles reduce integration overhead but introduce vendor lock-in.

API coverage gaps: Not all cloud applications expose APIs with sufficient granularity to support full policy enforcement. Applications lacking OAuth 2.0 or SCIM support may provide only limited log data, leaving DLP and activity monitoring incomplete through the API model.

Common misconceptions

Misconception: CASB replaces a firewall or SWG.
CASB is not a general-purpose network security tool. It operates at the application and data layer for cloud services specifically. General web traffic to non-cloud destinations, internal network segmentation, and perimeter-based controls remain outside CASB scope.

Misconception: API-mode CASB provides real-time blocking.
API integration is inherently asynchronous. It scans data already uploaded or actions already taken. Real-time blocking requires inline proxy deployment. Organizations relying solely on API-mode CASB for data exfiltration prevention face a structural gap — the data has already reached the cloud service before any policy action occurs.

Misconception: CASB deployment is a point-in-time project.
CASB policy effectiveness degrades without continuous tuning. Cloud application catalogs require ongoing updates as new applications emerge; DLP policies require refinement as false positive rates accumulate; API tokens require rotation and permission scope review. CASB is an operational program, not a configuration task.

Misconception: CASB covers all cloud traffic by default.
Without explicit network routing changes or endpoint agent deployment, CASB does not intercept traffic from unmanaged devices, off-network access, or mobile applications that bypass the enterprise proxy. Coverage scope is bounded by architecture, not by subscription tier.

The page provides additional context on how CASB fits within the broader cloud security provider landscape referenced across this resource.

Checklist or steps

The following sequence represents the operational phases of a CASB implementation program as documented in industry deployment frameworks, including guidance from the Cloud Security Alliance:

1. Cloud application discovery — Deploy DNS-layer or proxy-based traffic analysis to identify all cloud services in use across the organization. Produce a catalog distinguishing sanctioned, tolerated, and unsanctioned applications.
2. Risk scoring and classification — Apply a structured risk scoring methodology (attribute count: minimum 50 attributes per application) to categorize applications by data sensitivity, compliance posture, and access risk.
3. Identity and device integration — Connect the CASB to the organizational IdP (e.g., Azure AD, Okta) and MDM/UEM platform to establish user context and device posture as policy variables.
4. API integration for sanctioned SaaS — Configure API connectors for each sanctioned application with administrative credentials scoped to the minimum necessary permissions.
5. DLP policy definition — Define data classification labels and corresponding DLP rules, mapped to applicable regulatory requirements (HIPAA, PCI DSS, GDPR, or sector-specific mandates).
6. Proxy deployment for inline inspection — Configure forward proxy routing for managed devices; configure reverse proxy for unmanaged device access to critical applications.
7. Incident workflow integration — Connect CASB alerting to the organizational SIEM and incident response ticketing system to ensure policy violations generate actionable alerts.
8. Baseline review and tuning — Run the platform in monitor-only mode for a defined period (typically 30–60 days) to establish baselines and reduce false positive rates before switching to enforcement mode.
9. Ongoing policy governance — Establish a recurring review cadence for application catalog updates, DLP policy refinements, access token audits, and policy exception reviews.

The how to use this cloud security resource page describes how the service provider providers on this site are organized relative to these functional categories.

Reference table or matrix

CASB Deployment Model Comparison

CASB Functional Pillar Coverage by Model

Regulatory Frameworks with CASB Relevance