Cloud Access Security Broker (CASB)

Cloud Access Security Broker (CASB) technology sits between enterprise users and cloud service providers, enforcing security policies on data, users, and applications traversing that boundary. This reference covers the architectural structure of CASB deployments, the regulatory environment shaping adoption, classification distinctions among deployment modes, and the documented tradeoffs that define procurement and operational decisions in this sector. The subject is relevant to security architects, compliance officers, procurement analysts, and anyone 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

CASB is formally defined by Gartner as "on-premises or cloud-based security policy enforcement points, placed between cloud service consumers and cloud service providers" that combine and interject enterprise security policies as cloud-based resources are accessed. NIST's guidance in SP 800-210 (General Access Control Guidance for Cloud Systems) provides the federal framing for access control architecture in cloud environments, within which CASB functions as a policy enforcement layer rather than an identity authority.

CASB scope spans four primary control domains: visibility into cloud service usage, data security (including cloud data loss prevention and encryption), threat protection, and compliance. These four pillars are the industry-standard organizing framework referenced by the Cloud Security Alliance (CSA) in its CASB working group materials.

The scope extends across sanctioned applications — those explicitly approved by IT — and unsanctioned applications accessed through shadow IT. Organizations operating under FedRAMP authorization requirements must account for CASB controls as part of the continuous monitoring mandate described by the Office of Management and Budget (OMB) Circular A-130 and operationalized through FedRAMP's Program Management Office.

CASB is distinct from adjacent technologies. A CASB is not a Secure Web Gateway (SWG), though both may inspect traffic. A CASB is not a Cloud Security Posture Management (CSPM) tool, which targets misconfiguration rather than inline policy enforcement. The boundary between these categories is examined in the Classification Boundaries section below.

Core mechanics or structure

CASB platforms operate through three deployment architectures, each with distinct technical mechanisms:

API-mode (out-of-band): The CASB connects to cloud services through native APIs — such as Microsoft Graph API or Google Workspace Admin SDK — and inspects data at rest, activity logs, and configuration states without sitting inline. This mode enables retroactive policy enforcement and deep content inspection but cannot block real-time traffic.

Proxy-mode (inline): Traffic is routed through the CASB before reaching the cloud service. Two sub-variants exist:
- Forward proxy: Intercepts outbound traffic from managed devices, typically requiring endpoint agent installation or PAC file configuration.
- Reverse proxy: Intercepts inbound traffic to a cloud application, routing users through the CASB without an endpoint agent. Suited for unmanaged or BYOD devices.

Log-based (discovery-only): Firewall, proxy, or SIEM logs are ingested and analyzed to map cloud application usage. This mode produces shadow IT inventories and risk scoring without enforcing policy inline. It is the lowest-friction entry point but provides no active enforcement capability.

The four functional pillars operate across these deployment modes as follows:

1. Visibility: Discovery of cloud application usage, user behavior analytics, and risk scoring of applications against databases such as the CSA Cloud Controls Matrix (CCM).
2. Data security: DLP policy enforcement, classification tagging, encryption key management integration (see cloud key management), and rights management.
3. Threat protection: Anomaly detection, user and entity behavior analytics (UEBA), malware scanning of cloud-stored files, and integration with cloud threat detection and response platforms.
4. Compliance: Policy mapping to frameworks including HIPAA, PCI DSS, SOC 2, GDPR, and FedRAMP requirements, with audit trail generation.

Causal relationships or drivers

CASB adoption is driven by a convergence of regulatory pressure, workforce distribution patterns, and cloud consumption growth. The primary causal chain runs as follows:

Enterprise migration to SaaS applications decoupled data from on-premises perimeter controls. Traditional Data Loss Prevention (DLP) systems and web proxies were designed for traffic that remained on a corporate network. When sensitive data moves to Salesforce, Microsoft 365, Slack, or ServiceNow, perimeter-based controls no longer intercept it. CASB arose as the architectural response to this gap.

Regulatory frameworks amplified the urgency. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule (45 CFR Part 164) requires covered entities to implement technical safeguards controlling access to electronic protected health information regardless of where it resides — including third-party SaaS environments. The Payment Card Industry Data Security Standard (PCI DSS), maintained by the PCI Security Standards Council, requires encryption and access controls that extend into cloud-hosted cardholder data environments. Neither framework exempts organizations simply because a third-party cloud provider hosts the data.

The shift to remote work patterns accelerated adoption by dramatically increasing the volume of unmanaged device access to corporate cloud applications. Unmanaged endpoints cannot be governed by endpoint agents alone, making reverse-proxy CASB architecture operationally necessary for organizations with large contractor or mobile workforces.

Shadow IT is a persistent structural driver. The CSA has documented that enterprise employees use cloud services outside IT visibility at rates that consistently exceed IT department estimates. CASB log-discovery mode addresses this gap before organizations have the visibility to enforce policy.

Classification boundaries

CASB is frequently conflated with adjacent security categories. Precise classification depends on three criteria: enforcement posture (active vs. passive), placement (inline vs. out-of-band), and primary target (data, identity, configuration, or threat).

CASB and Zero Trust Cloud Architecture intersect at the policy enforcement layer but serve different architectural roles. Zero Trust Network Access (ZTNA) governs which users can reach which network resources; CASB governs what those users can do with cloud application data once access is granted.

CASB and Cloud Identity and Access Management are complementary, not substitutes. IAM controls authentication and authorization; CASB enforces data handling and behavioral policies post-authentication.

The Secure Access Service Edge (SASE) framework, defined by Gartner, bundles CASB, SWG, ZTNA, and SD-WAN into a converged architecture. In SASE implementations, CASB functions as one enforcement module rather than a standalone product, which affects procurement boundaries and vendor selection criteria.

Tradeoffs and tensions

API-mode vs. proxy-mode latency: Inline proxy enforcement introduces network latency. For high-volume SaaS transactions, proxy-mode inspection adds measurable overhead. Organizations must weigh real-time blocking capability against performance impact, particularly for latency-sensitive applications.

Decryption and privacy tension: Proxy-mode CASB must decrypt TLS traffic to inspect content. This creates legal and policy tensions in jurisdictions with strong employee privacy protections. The EU General Data Protection Regulation (GDPR), enforced by national Data Protection Authorities (DPAs) under Article 51, treats employee monitoring as a processing activity requiring legal basis and documentation — decryption-based inspection triggers these obligations.

Coverage gaps on unmanaged devices: API-mode cannot enforce real-time controls on unmanaged devices. Reverse-proxy mode addresses this but introduces session handling complexity and user experience friction on mobile clients.

False positive rates in DLP: Content-based DLP policies generate false positives that create operational burden. Overly broad policies block legitimate business activity; overly narrow policies miss sensitive data. Tuning is a sustained operational cost, not a one-time configuration task.

Vendor lock-in: CASB platforms often integrate deeply with specific SaaS ecosystems through proprietary API connectors. When a SaaS vendor changes its API structure, CASB functionality for that application may degrade until the CASB vendor updates its connector — a dependency with documented service continuity implications.

Common misconceptions

Misconception: CASB protects all cloud usage.
Correction: CASB coverage is limited to applications for which the platform has an active integration (API-mode) or through which traffic is routed (proxy-mode). Unrouted traffic to unsupported applications is invisible to enforcement policies.

Misconception: CASB replaces endpoint DLP.
Correction: CASB governs data in transit to and from cloud services and data at rest in cloud storage. It does not monitor data copied to local drives, printed, or exfiltrated through non-cloud channels. Endpoint DLP and CASB address distinct threat vectors and are typically deployed together in mature programs. See the cloud data loss prevention reference for endpoint-cloud DLP boundary distinctions.

Misconception: FedRAMP authorization of a SaaS vendor eliminates the need for CASB controls.
Correction: FedRAMP authorization attests that a provider meets NIST SP 800-53 baseline controls at the infrastructure level. It does not govern how agency users interact with that system or what data they upload. FedRAMP requirements place responsibility for access control and data governance on the authorizing agency, not solely on the provider.

Misconception: CASB and CSPM are interchangeable.
Correction: CSPM identifies misconfigured cloud infrastructure resources (e.g., open S3 buckets, overly permissive IAM roles). CASB governs user and application behavior at the data layer. The two address different attack surfaces. Cloud misconfiguration risks fall under CSPM scope, not CASB.

Misconception: Reverse-proxy CASB requires no endpoint configuration.
Correction: Reverse-proxy mode requires DNS redirection or identity provider (IdP) integration to route sessions through the CASB. While no endpoint agent is needed, the architecture requires SSO integration and may not function correctly with all authentication flows, particularly non-browser clients.

Checklist or steps

The following sequence describes the standard deployment phases for a CASB implementation as documented in CSA and NIST guidance frameworks. These phases are descriptive of industry practice, not prescriptive recommendations.

Phase 1 — Discovery and inventory
- Deploy log-based discovery using firewall, proxy, or SIEM data sources
- Generate cloud application inventory with risk scoring
- Identify regulated data types present in cloud storage (PHI, PCI data, PII)
- Map existing sanctioned applications and data flows

Phase 2 — Architecture selection
- Evaluate API-mode feasibility for sanctioned SaaS applications
- Assess proxy-mode requirements for unmanaged device populations
- Determine IdP integration prerequisites for reverse-proxy deployment
- Document TLS inspection legal basis under applicable jurisdiction

Phase 3 — Policy definition
- Define DLP policies mapped to applicable regulatory frameworks (HIPAA, PCI DSS, GDPR, CMMC)
- Establish acceptable use policies for cloud application categories
- Define anomaly detection baselines for UEBA functionality
- Configure access control policies aligned with cloud privileged access management standards

Phase 4 — Integration
- Connect API-mode integrations for priority SaaS applications
- Configure IdP (Okta, Azure AD, Ping) for proxy session routing
- Integrate with SIEM for alert forwarding and audit log retention
- Establish feedback loop with endpoint DLP for cross-channel visibility

Phase 5 — Operationalization
- Establish DLP policy tuning cadence (minimum quarterly review)
- Define incident response workflows for CASB-generated alerts
- Conduct user acceptance testing for proxy-mode session handling
- Document compliance evidence artifacts for audit readiness

Reference table or matrix

CASB Deployment Mode Comparison

Regulatory Framework Applicability

References

• NIST SP 800-210: General Access Control Guidance for Cloud Systems
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations
• Cloud Security Alliance (CSA) — Cloud Controls Matrix (CCM)
• FedRAMP Program Management Office — Authorization Documentation
• OMB Circular A-130: Managing Information as a Strategic Resource
• HHS Office for Civil Rights — HIPAA Security Rule (45 CFR Part 164)
• PCI Security Standards Council — PCI DSS v4.0
• GDPR Full Text — EUR-Lex
• DoD CMMC 2.0 Model Overview