Cloud Access Security Brokers in 2025: What's Changed and Why It Matters

The Problem That Won't Go Away

Your employees are using cloud applications you've never heard of. They're uploading sensitive documents to file-sharing services that haven't been vetted. They're pasting customer data into ChatGPT to write emails faster. And your traditional network security tools—firewalls, proxies, endpoint agents—can't see any of it.

This isn't a future problem. Over 90% of enterprises now use multiple SaaS platforms, and shadow IT usage has increased 59% since organizations broadly adopted remote work. The average enterprise has between 500 and 1,000 cloud applications in use, and IT typically knows about fewer than half of them. Each unsanctioned application represents potential data leakage, compliance violations, and attack surface expansion.

Cloud Access Security Brokers emerged to address this visibility gap, providing a security control point between users and cloud services. But the CASB market in 2025 looks fundamentally different from what it did even three years ago. What started as standalone point solutions has been absorbed into comprehensive Security Service Edge platforms. Understanding this evolution is essential for anyone evaluating cloud security architecture today.

What a CASB Actually Does

At its core, a Cloud Access Security Broker acts as an enforcement point that sits between users and cloud applications, analyzing traffic and enforcing security policies. The technology provides four primary capabilities that work together to secure cloud environments.

The first capability is visibility and discovery. CASBs identify which cloud services are in use across your organization, including the shadow IT applications that employees adopt without IT approval. This discovery happens through multiple mechanisms: analyzing firewall and proxy logs to identify cloud traffic patterns, deploying agents that report on application usage, and integrating with cloud platform APIs to enumerate connected applications. Without this visibility, security teams are essentially defending territory they can't see.

The second capability is data protection. CASBs implement Data Loss Prevention policies that detect and block sensitive information from leaving the organization through cloud channels. This includes identifying personally identifiable information, financial data, intellectual property, and other sensitive content based on patterns, keywords, and classification labels. Beyond detection, CASBs can encrypt data before it reaches cloud storage, tokenize sensitive fields to render them useless if exfiltrated, and enforce access controls that limit who can view or download specific content.

The third capability is threat protection. CASBs detect and respond to security threats within cloud environments, including malware uploaded to cloud storage, compromised accounts exhibiting anomalous behavior, and unauthorized access attempts. Modern CASBs leverage machine learning to establish behavioral baselines and identify deviations that may indicate account compromise or insider threats.

The fourth capability is compliance enforcement. CASBs help organizations meet regulatory requirements by enforcing policies that align with frameworks like GDPR, HIPAA, PCI DSS, and SOC 2. This includes controlling where data can be stored geographically, ensuring appropriate access controls are in place, maintaining audit logs of cloud activity, and generating compliance reports for auditors.

The Market Has Fundamentally Shifted

If you're evaluating CASB solutions in 2025, you're not shopping for standalone products anymore. The CASB market has converged into Security Service Edge platforms that combine multiple security functions into unified cloud-delivered services.

SSE platforms typically integrate four capabilities: Secure Web Gateway for filtering internet traffic, Cloud Access Security Broker for SaaS application security, Zero Trust Network Access for private application access, and Firewall-as-a-Service for network-level protection. When vendors talk about CASB today, they're usually describing one component of a broader SSE offering.

The numbers reflect this transformation. The CASB market reached approximately $8.7-15.5 billion in 2025, with projections reaching $25-33 billion by 2030 at a compound annual growth rate of 16-20%. North America holds the largest market share at over 44%, while Asia-Pacific shows the fastest growth at over 21% CAGR driven by digital transformation initiatives and increasing regulatory requirements.

This convergence isn't just vendor marketing—it reflects how cloud security actually works in modern enterprises. Organizations need consistent security policies across web traffic, SaaS applications, and private applications. Maintaining separate products for each creates policy fragmentation, management overhead, and security gaps at the boundaries. The major players in this consolidated market include Microsoft (Defender for Cloud Apps), Netskope, Palo Alto Networks (Prisma Access), Zscaler, and Skyhigh Security (formerly McAfee).

For practical purposes, this means your CASB evaluation should consider the broader SSE platform capabilities even if your immediate need is SaaS security. Starting with CASB functionality and expanding to other SSE components as needs evolve is a common adoption pattern.

Deployment Architecture: API vs Proxy

The more relevant architectural decision today isn't whether to deploy on-premises or in the cloud—it's whether to use API-based or proxy-based deployment modes, or some combination of both.

API-Based Deployment

API-based deployment connects directly to cloud service provider APIs to monitor activity and enforce policies. The CASB authenticates to services like Microsoft 365, Salesforce, or Box using OAuth or service account credentials, then queries activity logs, scans stored content, and applies policy actions through the API.

When connecting to Microsoft 365, your CASB requires specific Microsoft Graph API permissions:

# Microsoft Graph API OAuth Scope Requirements for CASB Integration

Required Application Permissions:
├── User.Read.All              # Read all user profiles
├── AuditLog.Read.All          # Access Azure AD audit logs
├── SecurityEvents.Read.All    # Read security alerts and events
├── Sites.Read.All             # Scan SharePoint/OneDrive content
├── Mail.Read                  # Email DLP scanning (scope carefully)
├── Files.Read.All             # Access files across all drives
└── Directory.Read.All         # Read directory data for group policies

You can verify your CASB's API connectivity and permissions using Microsoft's Graph Explorer or direct API calls:

# Test Microsoft Graph API connectivity
# First, obtain an access token using your CASB service principal

curl -X POST "https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id={client-id}" \
  -d "client_secret={client-secret}" \
  -d "scope=https://graph.microsoft.com/.default" \
  -d "grant_type=client_credentials"

# Verify user read permissions
curl -X GET "https://graph.microsoft.com/v1.0/users" \
  -H "Authorization: Bearer {access-token}" \
  -H "Content-Type: application/json"

# Check audit log access
curl -X GET "https://graph.microsoft.com/v1.0/auditLogs/directoryAudits" \
  -H "Authorization: Bearer {access-token}"

For Salesforce integration, CASBs typically use Connected Apps with OAuth 2.0:

# Salesforce OAuth token request for CASB integration
curl -X POST "https://login.salesforce.com/services/oauth2/token" \
  -d "grant_type=password" \
  -d "client_id={consumer-key}" \
  -d "client_secret={consumer-secret}" \
  -d "username={service-account}" \
  -d "password={password}{security-token}"

# Query Salesforce Event Monitoring logs
curl -X GET "https://{instance}.salesforce.com/services/data/v59.0/query/" \
  -H "Authorization: Bearer {access-token}" \
  --data-urlencode "q=SELECT Id, EventType, LogDate FROM EventLogFile WHERE LogDate = TODAY"

API-based deployment offers several advantages. It doesn't introduce latency because traffic doesn't route through the CASB infrastructure. It can scan data at rest—content already stored in cloud services—not just data in transit. It works regardless of how users access cloud services, whether from managed devices, personal devices, or mobile applications.

However, API-based deployment has limitations. It only works with cloud services that offer sufficiently capable APIs, which excludes many smaller SaaS applications. Policy enforcement is reactive rather than preventive—the CASB detects policy violations after they occur and then remediates, rather than blocking the action in real time. And API rate limits can constrain how quickly the CASB can scan large content repositories.

Proxy-Based Deployment

Proxy-based deployment routes traffic through the CASB infrastructure, enabling real-time inspection and blocking. Forward proxy mode requires configuring user devices to send cloud traffic through the CASB. Reverse proxy mode intercepts traffic at the application level, typically by modifying DNS or using identity provider integrations.

Verify proxy connectivity and certificate chain for forward proxy deployments:

# Test CASB proxy connectivity (example with Netskope)
curl -v --proxy https://gateway.netskope.com:443 https://www.office.com

# Verify CASB SSL inspection certificate chain
openssl s_client -connect gateway.netskope.com:443 -showcerts

# Check certificate details
echo | openssl s_client -connect gateway.netskope.com:443 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

# Test connectivity through Zscaler proxy
curl -v --proxy http://gateway.zscaler.net:80 \
  -H "X-Zscaler-Client: test" \
  https://login.microsoftonline.com

For reverse proxy configurations, verify DNS resolution points to your CASB:

# Check DNS resolution for reverse proxy deployment
# Your SaaS apps should resolve to CASB infrastructure

dig +short login.microsoftonline.com
# Should return CASB proxy IPs if reverse proxy is configured

nslookup mycompany.sharepoint.com
# Verify CNAME points to CASB reverse proxy

# Trace the full resolution path
dig +trace app.box.com

# Verify TLS certificate presented through reverse proxy
echo | openssl s_client -servername mycompany.sharepoint.com \
  -connect {casb-proxy-ip}:443 2>/dev/null | \
  openssl x509 -noout -text | grep -A2 "Issuer"

Proxy-based deployment enables real-time blocking of policy violations before sensitive data leaves the organization. It can inspect traffic to any cloud service, not just those with API integrations. And it provides more granular control over specific actions within applications.

The tradeoffs include latency introduction from traffic routing, complexity in deploying and maintaining proxy configurations, and potential user experience impacts if the proxy infrastructure experiences issues. Most organizations deploy both modes: API-based for sanctioned applications where deep visibility and content scanning matter, and proxy-based for broader coverage and real-time blocking capabilities.

The GenAI Problem You Can't Ignore

Perhaps the most significant development in cloud security over the past year is the emergence of generative AI as a data loss vector. Employees across every department are using tools like ChatGPT, Claude, Google Gemini, and Microsoft Copilot to accelerate their work. In doing so, they're often pasting sensitive information—customer data, proprietary code, strategic documents—into services that may train on or retain that input.

This isn't a future concern. It's happening now, and CASB platforms that lack GenAI governance capabilities are already behind the curve. Effective GenAI controls require several capabilities working together.

Discovery identifies which AI tools employees are using, including both well-known platforms and the long tail of specialized AI services emerging weekly. Your security team needs visibility into AI tool adoption patterns before you can apply policy.

Content inspection examines data being submitted to AI services in real time, detecting sensitive information before it reaches the AI provider. This requires the CASB to understand GenAI interaction patterns—prompt submission, file uploads, copy-paste operations—and apply DLP scanning appropriately.

Policy enforcement blocks or warns when users attempt to submit sensitive content to AI tools. Policies might vary by AI service: permitting use of enterprise-licensed tools with data protection agreements while blocking consumer AI services, or allowing AI assistance with non-sensitive content while preventing exposure of customer data.

# GenAI DLP Policy Configuration (Conceptual)
# Block sensitive data submission to consumer AI services

policy:
  name: "Block PII to Consumer AI"
  enabled: true

  trigger:
    destinations:
      - "chatgpt.com"
      - "chat.openai.com"
      - "claude.ai"
      - "gemini.google.com"
      - "copilot.microsoft.com"
      - "perplexity.ai"
    actions:
      - paste
      - file_upload
      - form_submit
    content_match:
      - pattern: "SSN"
        regex: '\b\d{3}-\d{2}-\d{4}\b'
      - pattern: "credit_card"
        regex: '\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b'
      - pattern: "email_pii"
        regex: '\b[A-Za-z0-9._%+-]+@company\.com\b'
      - pattern: "api_key"
        regex: '(sk-|api_key|apikey|api-key)[A-Za-z0-9]{20,}'

  response:
    action: block
    user_notification: true
    message: "This content contains sensitive data that cannot be shared with external AI services."
    logging:
      siem_forward: true
      alert_threshold: 5
      alert_window: "1h"

Common GenAI service endpoints to monitor:

# GenAI Service Domains for CASB Policy Configuration

OpenAI / ChatGPT:
├── chat.openai.com
├── api.openai.com
├── platform.openai.com
└── cdn.openai.com

Anthropic / Claude:
├── claude.ai
├── api.anthropic.com
└── console.anthropic.com

Google AI:
├── gemini.google.com
├── bard.google.com
├── aistudio.google.com
└── generativelanguage.googleapis.com

Microsoft Copilot:
├── copilot.microsoft.com
├── bing.com/chat
└── copilot.cloud.microsoft

Other Notable Services:
├── perplexity.ai
├── you.com
├── poe.com
├── huggingface.co
├── replicate.com
└── together.ai

The challenge is that GenAI interactions often look like normal web browsing from a network perspective. Detecting sensitive content being pasted into a chat interface requires application-layer inspection that many traditional security tools can't provide. This is where CASB capabilities—specifically inline inspection and DLP—become essential.

Implementation Realities

Deploying a CASB is more complex than vendors' sales presentations suggest. Nearly 40% of enterprises reported difficulties integrating CASB solutions with legacy infrastructure in 2024. Understanding common challenges helps you plan realistic implementations.

Shadow IT Discovery

Shadow IT discovery sounds straightforward but requires multiple data sources to be effective. Log analysis from firewalls and proxies identifies cloud traffic but misses applications accessed from unmanaged devices or over personal networks. Agent-based discovery provides device-level visibility but requires deployment across endpoints. API-based discovery can enumerate connected applications for platforms like Microsoft 365 but doesn't reveal applications accessed outside the corporate identity fabric.

# Shadow IT Discovery: Analyzing Firewall Logs
# Extract and categorize cloud service traffic from Palo Alto logs

# Parse traffic logs for cloud application domains
cat traffic_log.csv | \
  awk -F',' '{print $5}' | \
  grep -E '\.(saas|cloud|app|io|ai)' | \
  sort | uniq -c | sort -rn | head -100 > cloud_domains.txt

# Cross-reference against known SaaS database
# Most CASBs maintain 30,000+ application signatures

# Extract high-bandwidth cloud destinations
cat traffic_log.csv | \
  awk -F',' '{sum[$5]+=$8} END {for (domain in sum) print sum[domain], domain}' | \
  sort -rn | head -50

# Identify potential file-sharing services by upload patterns
grep -E "POST|PUT" traffic_log.csv | \
  awk -F',' '$8 > 1000000 {print $5}' | \
  sort | uniq -c | sort -rn

For more sophisticated shadow IT discovery, query your DNS logs:

# DNS-based shadow IT discovery
# Analyze DNS query logs for cloud service patterns

# Extract unique domains from DNS logs
cat dns_queries.log | \
  awk '{print $5}' | \
  grep -vE '(internal\.company\.com|arpa)' | \
  sort | uniq -c | sort -rn > external_domains.txt

# Identify SaaS patterns
grep -E '(slack|dropbox|box|drive|onedrive|sharepoint|salesforce)' \
  external_domains.txt

# Find potential AI services
grep -E '(openai|anthropic|claude|gemini|copilot|hugging)' \
  external_domains.txt

# Query categorization API (example with Netskope)
curl -X POST "https://api.netskope.com/api/v1/app_instances" \
  -H "Netskope-Api-Token: {api-token}" \
  -H "Content-Type: application/json" \
  -d '{"domains": ["unknown-app.io", "newservice.cloud"]}'

Identity Provider Integration

Integration with identity providers is essential but technically involved. CASBs need to understand user identity to apply role-based policies, which requires federation with corporate identity providers through SAML or OIDC. Group membership, department, location, and device posture should all factor into policy decisions.

# SAML Attribute Mapping for CASB Integration
# Configure your IdP to pass these attributes in SAML assertions

saml_assertion:
  attributes:
    - name: "uid"
      value: "user@company.com"
      format: "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"

    - name: "groups"
      value: ["engineering", "contractors", "us-employees"]
      format: "urn:oasis:names:tc:SAML:2.0:attrname-format:basic"

    - name: "department"
      value: "Product Development"

    - name: "mfa_completed"
      value: "true"

    - name: "device_trust_level"
      value: "managed"  # Options: managed, compliant, unmanaged

    - name: "risk_score"
      value: "low"  # From identity protection signals

# CASB Policy Application Logic
casb_policy:
  rule: "Engineering Data Access"
  conditions:
    - department: "Product Development"
    - groups: contains("engineering")
    - device_trust_level: "managed"
    - mfa_completed: true
  actions:
    allow_upload: true
    allow_download: true
    allow_external_share: false
    dlp_scan: enabled

Verify SAML configuration with these diagnostic steps:

# Test SAML IdP metadata endpoint
curl -s "https://idp.company.com/metadata" | \
  xmllint --format - | \
  grep -E "(entityID|Location|X509Certificate)"

# Decode SAML assertion for troubleshooting
# Base64 decode the SAMLResponse from browser developer tools
echo "{base64-saml-response}" | base64 -d | xmllint --format -

# Verify IdP certificate hasn't expired
curl -s "https://idp.company.com/metadata" | \
  grep -oP '(?<=<ds:X509Certificate>).*(?=</ds:X509Certificate>)' | \
  base64 -d | \
  openssl x509 -noout -dates

# Test OIDC discovery endpoint
curl -s "https://login.company.com/.well-known/openid-configuration" | jq .

DLP Policy Tuning

DLP tuning requires significant effort to reduce false positives without creating dangerous blind spots. Out-of-box DLP policies tend to be either too aggressive—blocking legitimate business activities and frustrating users—or too permissive, missing actual data exposure. Plan for an iterative tuning process that takes months, not days.

# DLP Policy Testing and Tuning
# Generate test files with known patterns for validation

# Create test file with credit card patterns
cat << 'EOF' > dlp_test_cc.txt
Test credit card numbers (invalid checksums for testing):
Visa: 4111-1111-1111-1111
Mastercard: 5500 0000 0000 0004
Amex: 3400 000000 00009
EOF

# Create test file with SSN patterns
cat << 'EOF' > dlp_test_ssn.txt
Test SSN formats:
Standard: 123-45-6789
No dashes: 123456789
With spaces: 123 45 6789
EOF

# Test DLP detection via CASB API (example)
curl -X POST "https://api.casb.example.com/v1/dlp/scan" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: multipart/form-data" \
  -F "file=@dlp_test_cc.txt" \
  -F "policies=credit_card,ssn,pii"

# Review DLP incident logs for false positive tuning
curl -X GET "https://api.casb.example.com/v1/incidents" \
  -H "Authorization: Bearer {token}" \
  --data-urlencode "filter=severity:low" \
  --data-urlencode "timerange=7d" | \
  jq '.incidents[] | {file: .filename, policy: .policy_name, user: .user}'

User experience impacts can undermine adoption if not managed carefully. Inline inspection adds latency. Authentication challenges disrupt workflows. Blocked actions without clear explanations drive users to unsanctioned workarounds, increasing shadow IT rather than reducing it. The goal is security that enables rather than hinders—promoting approved applications and streamlining access while quietly blocking dangerous activities.

Performance Monitoring

Monitor CASB impact on user experience:

# Measure latency impact of CASB proxy
# Compare direct vs proxied connections

# Direct connection baseline
curl -o /dev/null -s -w "Direct: %{time_total}s\n" \
  https://www.office.com

# Through CASB proxy
curl -o /dev/null -s -w "Proxied: %{time_total}s\n" \
  --proxy https://gateway.casb.example.com:443 \
  https://www.office.com

# Continuous monitoring script
while true; do
  DIRECT=$(curl -o /dev/null -s -w "%{time_total}" https://login.microsoftonline.com)
  PROXIED=$(curl -o /dev/null -s -w "%{time_total}" --proxy https://gateway.casb.example.com:443 https://login.microsoftonline.com)
  echo "$(date +%H:%M:%S) Direct: ${DIRECT}s Proxied: ${PROXIED}s Delta: $(echo "$PROXIED - $DIRECT" | bc)s"
  sleep 60
done

# Check CASB service health endpoints
curl -s "https://status.netskope.com/api/v2/status.json" | jq '.status'
curl -s "https://trust.zscaler.com/api/status" | jq '.overall_status'

What Success Looks Like

Rather than abstract benefits, here's what effective CASB deployment achieves in practical terms.

Visibility transforms from guessing to knowing. Security teams can answer questions like "Which cloud storage services contain customer data?" and "Who accessed sensitive files last month?" with actual data rather than assumptions. This visibility extends to previously invisible shadow IT, often revealing hundreds of applications that weren't on anyone's radar.

# Example CASB API queries for visibility reporting

# Get shadow IT summary
curl -X GET "https://api.casb.example.com/v1/apps/discovered" \
  -H "Authorization: Bearer {token}" \
  --data-urlencode "risk_level=high" \
  --data-urlencode "sancti | \
  jq '.apps[] | {name: .app_name, users: .user_count, risk: .risk_score}'

# Query data exposure by application
curl -X GET "https://api.casb.example.com/v1/dlp/exposure" \
  -H "Authorization: Bearer {token}" \
  --data-urlencode "timerange=30d" | \
  jq '.exposures | group_by(.app) | map({app: .[0].app, incidents: length})'

# User activity audit trail
curl -X GET "https://api.casb.example.com/v1/audit/activities" \
  -H "Authorization: Bearer {token}" \
  --data-urlencode "user=suspect@company.com" \
  --data-urlencode "timerange=7d" | \
  jq '.activities[] | {time: .timestamp, app: .application, action: .activity_type}'

Data exposure incidents decrease measurably. DLP policies catch sensitive content before it leaves the organization through cloud channels. This includes both intentional exfiltration attempts and the far more common accidental exposures—employees sharing documents with external parties who shouldn't have access, or uploading files to personal cloud storage for convenience.

Compliance evidence becomes auditable. Instead of asserting that appropriate controls exist, security teams can demonstrate them with logs showing policy enforcement, access controls, and data handling practices. Compliance audits become less stressful when you can produce specific evidence for each control requirement.

Threat detection catches compromised accounts that would otherwise operate undetected. When an attacker gains access to cloud credentials, they typically exhibit behavioral patterns that differ from the legitimate user—accessing unusual data, downloading bulk content, logging in from unexpected locations. CASB behavioral analytics detect these anomalies and alert security teams.

Making the Decision

For organizations evaluating cloud security investments, the decision framework depends on your current maturity and specific challenges.

If shadow IT visibility is your primary concern—you don't know what cloud services are in use—start with discovery capabilities. API integrations with your major platforms and log analysis can provide visibility quickly without deploying inline infrastructure.

If data protection is the priority—preventing sensitive data from leaving through cloud channels—prioritize DLP capabilities and consider proxy-based deployment for real-time blocking. API-only deployment provides visibility and reactive remediation but can't prevent the initial exposure.

If you're early in cloud adoption with few SaaS applications, a CASB may be premature. Focus on securing the specific applications you're using through native security controls and identity federation before adding a security layer that may not have much to protect.

If you're already using Microsoft 365 extensively, evaluate Microsoft Defender for Cloud Apps before purchasing third-party solutions. Microsoft's CASB integrates deeply with the 365 ecosystem and may meet your needs without additional licensing—though it has limitations for non-Microsoft cloud services.

For most organizations with significant SaaS footprints and cloud security concerns, evaluate SSE platforms rather than standalone CASB products. The convergence of CASB, SWG, and ZTNA capabilities provides more comprehensive protection and simplifies management compared to maintaining separate point solutions.

What's Coming Next

The CASB market continues evolving in response to changing threats and enterprise needs. Several trends will shape the technology over the next few years.

GenAI governance will move from emerging capability to table stakes. Every major platform is racing to add AI-specific controls, and solutions without robust GenAI discovery and policy enforcement will fall behind rapidly.

Data security posture management is extending CASB concepts to infrastructure. DSPM products discover and classify data across cloud infrastructure—databases, object storage, data warehouses—applying similar visibility and control principles that CASB brought to SaaS applications.

Integration depth will differentiate platforms. As the market consolidates, competition will shift from feature checklists to integration quality—how well the CASB works with identity providers, SIEM platforms, endpoint agents, and cloud-native security tools.

Automation will reduce operational burden. Today's CASB implementations require significant manual effort for policy tuning, incident investigation, and remediation. AI-assisted security operations will automate routine tasks and accelerate response to genuine threats.

The fundamental challenge CASB addresses—maintaining security visibility and control as data and applications move beyond traditional network boundaries—isn't going away. If anything, the proliferation of cloud services, remote work, and AI tools makes this challenge more acute. The technology will continue evolving, but the need for enforcement points that protect data wherever it flows will remain central to enterprise security architecture.

---