Cloud Access Security Brokers (CASB) Explained
Cloud Access Security Brokers occupy a defined enforcement position between enterprise users and cloud service providers, functioning as policy arbitration points that govern how data moves into, out of, and across cloud environments. This page describes the CASB service category — its architectural role, functional modes, applicable regulatory contexts, and the boundaries that separate it from adjacent security controls. The subject is relevant to compliance officers, cloud architects, security engineers, and procurement professionals evaluating cloud defense providers across this sector.
Definition and scope
A Cloud Access Security Broker is a software-enforced control plane positioned between enterprise endpoints and one or more cloud services, applying security policies that the cloud provider itself does not enforce by default. The term was formalized as a security category by Gartner beginning around 2012 and has since been absorbed into federal and standards-body vocabulary. The National Institute of Standards and Technology references this architectural pattern in NIST SP 800-210, General Access Control Guidance for Cloud Systems, which addresses policy enforcement points in multi-tenant environments.
CASBs operate across four functional pillars, as defined by industry classification frameworks maintained by the Cloud Security Alliance (CSA):
- Visibility — Discovery and inventory of sanctioned and unsanctioned cloud applications in use across an organization, including shadow IT detection.
- Compliance — Enforcement of data residency requirements, regulatory retention rules, and policy mandates drawn from frameworks such as HIPAA, PCI DSS v4.0, and FedRAMP.
- Data Security — Application of data loss prevention (DLP) rules, encryption, tokenization, and rights management to content traversing cloud channels.
- Threat Protection — Detection of anomalous user behavior, compromised credentials, and malware propagation through cloud storage and collaboration services.
The scope of a CASB deployment extends across Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) models — the three deployment tiers defined in NIST SP 800-145. SaaS-focused deployments represent the most common CASB use case due to the volume and diversity of SaaS adoption in enterprise environments.
How it works
CASBs intercept and inspect cloud traffic through one of three deployment architectures, each with distinct trust and coverage characteristics:
API-based mode connects directly to cloud provider management APIs — such as Microsoft Graph API or Salesforce REST API — to scan stored data, audit user activity logs, and enforce policy retroactively. This mode does not require traffic redirection and introduces no latency, but it operates on a polling interval rather than real-time stream inspection.
Proxy mode (forward proxy) routes all outbound cloud traffic through the CASB before it reaches the cloud provider. Enforcement is inline and real-time. This mode requires either agent installation on managed endpoints or network-level traffic steering via PAC files and DNS configurations. Unmanaged devices present a coverage gap.
Proxy mode (reverse proxy) intercepts inbound cloud service traffic by redirecting users through the CASB via identity provider integration — typically SAML-based SSO. This mode extends enforcement to unmanaged and BYOD devices without endpoint agents, making it the standard approach when third-party contractor access is a compliance requirement.
The architectural contrast between API and proxy modes is material for compliance purposes: API mode captures historical state and logged events, while inline proxy mode enforces policy at the moment of transmission. Regulated environments operating under NIST SP 800-53 Rev 5 AC (Access Control) and SC (System and Communications Protection) control families typically require both modes in combination to satisfy continuous monitoring obligations.
The CASB policy engine evaluates traffic against rule sets encompassing user identity, device posture, application sensitivity classification, data content, and geographic location of the request origin. Enforcement actions include allow, block, alert, encrypt, quarantine, and step-up authentication challenges routed through an integrated identity provider.
Common scenarios
Regulated data in SaaS applications — Healthcare organizations subject to HIPAA, administered by the U.S. Department of Health and Human Services (HHS), use CASB DLP policies to prevent protected health information (PHI) from being uploaded to non-authorized cloud storage or collaboration tools. The CASB applies content inspection against PHI identifiers regardless of which SaaS application the user is attempting to access.
FedRAMP compliance monitoring — Federal agencies and their contractors operating under the Federal Risk and Authorization Management Program (FedRAMP) use CASB API integrations to produce continuous audit logs aligned with the IR and AU control families from NIST SP 800-53 Rev 5. This satisfies the continuous monitoring requirement defined in OMB Circular A-130.
Shadow IT discovery — Enterprise security teams use CASB traffic analysis to enumerate unauthorized application usage. CSA research documented in the Cloud Adoption and Risk Report has catalogued environments where employees access more than 1,000 distinct cloud services, the majority of which fall outside IT procurement review.
Insider threat detection — CASB behavioral analytics establish baseline activity profiles for individual users and flag deviations such as bulk downloads, off-hours access to sensitive repositories, or lateral movement across unrelated cloud tenants. These anomalies feed into SIEM pipelines for correlation against endpoint and network telemetry.
Decision boundaries
CASBs are not universal replacements for adjacent security controls. The boundaries between CASB, Secure Web Gateway (SWG), Zero Trust Network Access (ZTNA), and Cloud Security Posture Management (CSPM) are architecturally distinct and operationally non-overlapping in several dimensions.
| Control | Primary enforcement target | Policy scope |
|---|---|---|
| CASB | User-to-cloud application traffic | Data, identity, compliance |
| SWG | General web traffic (cloud and non-cloud) | URL filtering, malware, acceptable use |
| ZTNA | Application-level access (network layer) | Identity, device posture, network segmentation |
| CSPM | Cloud infrastructure configuration | Misconfiguration, IaaS/PaaS posture drift |
CASB is indicated when the operational requirement is data-centric policy enforcement across SaaS and IaaS applications — particularly where regulatory mandates require content inspection, DLP logging, or audit trails tied to individual user identities. CASB is not indicated as a primary control for network-layer segmentation, endpoint malware prevention, or infrastructure misconfiguration remediation; those functions belong to ZTNA, EDR, and CSPM respectively.
For organizations building procurement criteria or evaluating providers through the , the deployment architecture question — API-only versus inline proxy — is the first qualifying criterion, as it determines which compliance evidence the solution can produce. Environments with BYOD or contractor access requirements that cannot redirect endpoint traffic must account for the coverage gaps inherent in API-only deployments.
The CSA's Cloud Controls Matrix (CCM) maps CASB functional requirements to specific control domains, providing a vendor-neutral framework for evaluating whether a given CASB deployment addresses the compliance controls relevant to a specific regulatory regime. Practitioners using this reference alongside the how to use this cloud defense resource page can cross-reference functional requirements against the provider network's provider categories.