TL;DR: CASBs struggle to keep up with remote work because proxy-based deployment, manual policy handling, incomplete SaaS visibility, and weak offboarding support leave operational gaps that cloud-first teams still have to close, according to Zluri. The underlying issue is that legacy inspection models were built for network boundaries, not for SaaS sprawl and identity-driven access.
At a glance
What this is: This analysis argues that CASBs are a partial control for modern SaaS estates because remote work, BYOD, and hybrid access patterns expose visibility, enforcement, and lifecycle gaps.
Why it matters: It matters because IAM, SaaS governance, and identity lifecycle teams need controls that follow access all the way through onboarding, usage, and offboarding, not just perimeter inspection.
By the numbers:
- 99% of companies are using SaaS tools to get things done, and the security level shivers with constantly changing user access and third-party participation.
- According to a Gartner report, CASB solutions cost between $15/user/year to $85/user/year.
- The post says almost 360k new malware is found every day, which makes signature-based detection increasingly ineffective.
👉 Read Zluri's analysis of CASB drawbacks in remote SaaS environments
Context
CASBs are cloud access security brokers, meaning tools that sit between users and cloud services to inspect activity and apply policy. In a SaaS-heavy environment, that model becomes harder to sustain because identity, device, and app usage now change constantly across remote workers, contractors, and third-party access.
The article’s core point is that modern access governance has moved beyond network inspection. For identity teams, the real issue is not whether a CASB can see traffic, but whether it can keep up with app sprawl, policy enforcement, and lifecycle controls across SaaS, which is why the debate now overlaps with broader NHI governance and access management.
For teams trying to reduce risk without creating more manual work, the relevant question is where control should live: at the network, in the application, or in the identity layer. That is the same structural question raised by the Ultimate Guide to NHIs when access is no longer bounded by a simple perimeter.
Key questions
Q: How should security teams govern SaaS access when CASB only provides partial visibility?
A: They should use CASB as an inspection layer, not as the control point for lifecycle governance. The practical model is to connect app discovery, entitlement review, and deprovisioning so that visibility leads to an actual access decision. Without that handoff, the organisation can see risk but cannot reliably remove it.
Q: Why do proxy-based CASB deployments struggle in remote and BYOD environments?
A: Because they depend on traffic flowing through a predictable inspection path. Remote users, unmanaged devices, and mixed web and API traffic break that assumption, which leaves blind spots for unsanctioned apps and reduces the reliability of policy enforcement.
Q: What do organisations get wrong about CASB and DLP?
A: They often assume a CASB can act as a self-contained data protection stack. In practice, CASB may provide visibility and some policy controls, but DLP, PAM, and lifecycle offboarding still have to do separate work if the organisation wants real enforcement after access is granted.
Q: How can teams tell whether their SaaS governance model is actually working?
A: Look for automated outcomes, not just alerts. If app discovery does not lead to entitlement cleanup, if leaver access persists, or if policy classification depends on manual review, the programme is producing reporting rather than control.
Technical breakdown
Why proxy-based CASB architectures struggle in SaaS-first estates
CASBs typically use forward proxy, reverse proxy, or API-based integrations to inspect cloud traffic and enforce policy. The problem is architectural. Reverse proxy only sees known apps, forward proxy is limited by web protocols, and API-only enforcement does not deliver the same inline protection. In a remote world with BYOD, unmanaged endpoints, and scattered traffic paths, the control plane becomes fragmented. The result is partial visibility with growing blind spots, especially when unsanctioned apps or non-web usage sit outside the proxy path.
Practical implication: validate whether your current inspection model can actually see the traffic patterns your users and contractors generate.
Why manual policy tuning becomes a governance burden
Legacy CASB deployments often require PAC files, log collectors, identity connectors, endpoint agents, and ongoing box-checking for what is or is not sensitive. That makes governance dependent on repeated human configuration rather than policy automation. The article also notes that CASBs are not complete security systems and can be confused with DLP, which creates overlap without full control. In practice, the burden shifts to IT teams to keep policy state aligned across apps, devices, and user groups, which increases the chance of drift and misconfiguration.
Practical implication: treat manual policy assignment as a control gap, not an acceptable operating model.
Why CASB visibility does not equal access governance
CASB can show activity, but activity visibility is not the same as identity governance. The article points out that once a user is inside an app, CASB may not tell you what they are doing at a granular level, and it does not replace privileged access management or lifecycle offboarding. That means a tool can detect usage without actually governing entitlement, role change, or deprovisioning. For SaaS estates, the decisive failure is not lack of data, but lack of actionability after access is granted.
Practical implication: pair visibility controls with entitlement review and offboarding workflows that actually remove access.
NHI Mgmt Group analysis
CASB was built for perimeter-era control assumptions that no longer hold in SaaS-first identity estates. The article shows that proxy placement, log collection, and policy enforcement all depend on traffic flowing through a predictable control path. That assumption breaks when users work remotely, apps proliferate, and third-party participation becomes routine. Practitioners should treat CASB as a partial inspection layer, not the governance source of truth.
Identity visibility without entitlement action creates a governance illusion. The article repeatedly separates seeing activity from controlling access, which is the central failure mode in modern SaaS estates. A tool that reports usage but cannot reliably drive offboarding, privilege review, or cross-app policy alignment leaves the identity programme with evidence but no enforcement. Practitioners should measure whether visibility is leading to actual access decisions.
Shadow IT and unsanctioned app usage expose a named concept: the SaaS visibility gap. Reverse proxy models only cover known applications, so unmanaged apps stay outside the control surface. That gap widens as SaaS adoption grows and teams rely on manual classification of sensitive activity. The implication is straightforward for identity leaders: if app discovery and access governance are separate motions, the programme will always lag the estate.
CASB deployment cost is not only a licensing issue, it is an operating-model issue. The article’s pricing and infrastructure examples show that deployment overhead, extra appliances, and endpoint configuration all add friction to control adoption. That matters because governance controls that are expensive to operationalise are the first to drift out of date. Practitioners should assess whether the security model can be sustained at enterprise scale, not just whether it can be technically installed.
Modern SaaS governance now requires identity lifecycle control, not just network inspection. The article’s offboarding example is the clearest sign that access governance has moved into the lifecycle layer. When joiner, mover, and leaver workflows are not connected to app entitlements, security posture depends on manual follow-up. Practitioners should align SaaS control decisions with lifecycle management rather than treating CASB as the end state.
From our research:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
- For the lifecycle angle, read Ultimate Guide to NHIs for how access, visibility, and offboarding fit together across machine and human identities.
What this signals
SaaS visibility gap: As more access moves into distributed SaaS estates, security teams should expect inspection tools to lose authority unless they are tied to identity lifecycle and entitlement controls. The practical challenge is not whether the tool sees something, but whether it can drive the next governed action across joiner, mover, and leaver workflows.
With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per the 2026 Infrastructure Identity Survey, control models built around periodic inspection will continue to lag the pace of access change. That makes identity-led governance more important than perimeter inspection for both SaaS and autonomous systems.
Teams should also rethink how they separate monitoring from enforcement. The more remote and app-fragmented the environment becomes, the more control has to move toward the identity layer, where access can be certified, removed, or narrowed in the same workflow that discovered it.
For practitioners
- Map control coverage to the actual SaaS traffic path Identify where forward proxy, reverse proxy, and API-only enforcement leave blind spots for unmanaged apps, mobile users, and non-web traffic. Use that map to decide which SaaS controls need identity-layer enforcement instead of network-layer interception.
- Separate visibility from governance in your operating model Require a clear handoff from activity monitoring to entitlement review, access removal, or privilege tightening. If a CASB can surface an issue but cannot trigger a governed action, treat that as an unresolved control gap.
- Reduce dependence on manual policy classification Replace box-checking workflows with policy logic tied to user role, app sensitivity, and lifecycle state. Manual identification of sensitive data and applications does not scale in remote environments and increases misconfiguration risk.
- Tie SaaS offboarding to lifecycle automation Ensure leaver workflows remove app access quickly and consistently across the applications actually in use, not just the sanctioned ones. Offboarding should close entitlements automatically rather than waiting for manual review after departure.
Key takeaways
- CASBs still provide useful inspection, but they do not solve the full identity governance problem in SaaS-first environments.
- The main operational weakness is the gap between visibility and enforceable action, especially for offboarding and privilege control.
- Identity teams should judge controls by whether they can follow access from discovery to removal, not by whether they can inspect traffic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | CASB limitations affect how access is managed after authentication in SaaS estates. |
| NIST Zero Trust (SP 800-207) | ID | The article shows why network-centric trust checks fail in distributed cloud access. |
| OWASP Non-Human Identity Top 10 | NHI-01 | SaaS access and offboarding gaps mirror common non-human identity governance failures. |
Treat app access as governed identity state and close lifecycle gaps that CASB cannot enforce.
Key terms
- Cloud Access Security Broker: A cloud access security broker is a control layer that sits between users and cloud services to inspect activity and apply policy. In practice, it is strongest where traffic can be routed predictably, but weaker when access patterns are distributed across remote users, APIs, and unsanctioned apps.
- Shadow IT: Shadow IT is software or cloud usage that happens outside approved procurement or governance processes. In identity programmes, it creates an access problem as much as a visibility problem because entitlements can exist outside the systems that enforce review, offboarding, and policy alignment.
- SaaS Management Platform: A SaaS management platform is a toolset for discovering, governing, and optimising software-as-a-service usage across the organisation. Unlike inspection-only controls, it is designed to connect application discovery with lifecycle actions such as onboarding, renewal decisions, and offboarding.
- Identity Collector: An identity collector is a connector that links directory data and user identity state to a security or governance platform. It helps a control plane understand who has access, but it does not by itself remove the need for entitlement governance or deprovisioning workflows.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity security in your organisation, it is worth exploring.
This post draws on content published by Zluri: IT Teams Drawbacks of CASBs in the Remote World. Read the original.
Published by the NHIMG editorial team on 2025-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org