CASB drawbacks in remote work expose SaaS governance gaps

At a glance

What this is: This is a critique of CASB for remote work, arguing that legacy proxy-centered controls leave SaaS access, visibility, and lifecycle governance incomplete.

Why it matters: IAM, NHI, and SaaS governance teams need to see where perimeter-era inspection stops and where identity-led access control, offboarding, and policy automation must take over.

By the numbers:

• According to a Gartner report cited by Zluri, CASB solutions cost between $15/user/year and $85/user/year.
• Zluri says 99% of companies are using SaaS tools to get things done.
• The article says almost 360k new malware is found every day.

Context

CASB is a control pattern built around inserting a broker between users and cloud services, usually through proxying, log collection, or API integration. In remote work, that model collides with SaaS sprawl, BYOD, scattered endpoints, and identity-driven access paths that no longer behave like a neat network boundary.

The article argues that the governance gap is not just technical deployment friction. It is a mismatch between perimeter-era inspection and the way modern organisations grant, use, and revoke access across cloud applications, third parties, and remote endpoints.

For IAM and NHI programmes, that matters because the control problem shifts from seeing traffic to governing entitlement, usage, and offboarding across SaaS. If the broker cannot keep up with lifecycle and policy execution, the organisation is left with visibility but not operational control.

Key questions

Q: What breaks when CASB only covers live SaaS sessions?

A: You miss the exposures that persist after the session ends, including public file links, dormant users, missing MFA, and over-privileged accounts. Those controls live in the tenant state, not the browser flow, so inline inspection alone cannot remove them. Effective CASB must inspect SaaS APIs and route remediation to the owner who can safely change the exposure.

Q: Why does remote work make CASB less effective for SaaS governance?

A: Remote work widens the gap between where traffic is inspected and where identity decisions are actually made. With scattered endpoints, BYOD, third-party access, and many SaaS apps, the control model has to keep up with constant change. CASB struggles because its operating assumptions were built for a more bounded network environment.

Q: What are the signs that CASB visibility is not enough?

A: Warning signs include unknown or unsanctioned apps that remain outside coverage, policy decisions that require manual check-box work, and users who still retain meaningful access after the broker layer has done its inspection. If teams can see usage but cannot consistently revoke, restrict, or certify access, the control is informational rather than governing.

Q: Should organisations treat CASB visibility as a substitute for SaaS governance?

A: No. CASB visibility helps discover activity and flag risk, but governance still requires ownership, entitlement review, and lifecycle handling. Without those controls, the organisation may know an app is present and risky while still lacking a defensible way to approve, reduce, or remove access.

Technical breakdown

Why proxy-based CASB architectures struggle with SaaS visibility

CASB products commonly rely on forward proxy, reverse proxy, or API-based inspection. That creates different blind spots depending on how traffic is routed. Reverse proxies only see known applications, forward proxies usually cover web traffic but miss non-web paths, and API-only integrations can improve policy control without delivering live enforcement or threat protection. The architectural issue is that the control point sits between user and service, not inside the SaaS governance lifecycle. As SaaS usage expands, that separation becomes harder to reconcile with dynamic access, collaboration, and third-party participation.

Practical implication: map where your inspection layer loses coverage and treat those gaps as governance, not just tooling, defects.

Why manual policy handling breaks at cloud scale

The article shows that CASB administration often depends on manual classification, connector setup, PAC deployment, and repeated policy tuning. That workflow is expensive and slow because it assumes a bounded environment with relatively stable endpoints and application sets. In remote work, the number of devices, sites, and cloud apps grows faster than the human effort needed to maintain those controls. When policy decisions require check-box administration, the control plane becomes a bottleneck instead of an enabler. The result is delayed enforcement, inconsistent policy coverage, and misconfiguration risk.

Practical implication: reduce any control that still depends on repeated human classification before it can enforce policy.

Why CASB visibility stops short of identity governance

The article’s central governance point is that visibility after login is not the same as control over what a user can do inside a SaaS application. CASB may show activity, but it does not automatically govern entitlements, role fit, offboarding, or least-privilege drift inside collaborative tools. That makes it a partial control for identity-led SaaS risk. Once access is granted, the organisation still needs separate governance over privileged use, revoked access, and lifecycle closure. In other words, the broker can observe the doorway but not fully manage the room.

Practical implication: pair visibility controls with entitlement, offboarding, and access review processes that actually govern the SaaS session lifecycle.

NHI Mgmt Group analysis

CASB is being asked to solve a governance problem it was not built to own: the control model assumes that network mediation plus policy inspection can keep pace with SaaS sprawl, but remote work breaks that assumption. Zluri’s critique points to a deeper issue than deployment friction: modern identity governance needs lifecycle execution, not only traffic observation. The practitioner conclusion is that visibility without operational enforcement leaves the programme looking controlled while remaining materially incomplete.

Identity-driven SaaS access turns offboarding into the real control boundary: the article correctly highlights that access inside the application is where exposure continues after the broker has done its job. That means the meaningful security question is not whether the user reached the app, but whether entitlement, privilege, and removal were governed across the full SaaS lifecycle. For IAM teams, this shifts attention from perimeter inspection to joiner-mover-leaver execution and access recertification.

Remote work exposes the CASB deployment tax as a governance tax: proxy configuration, log forwarding, and repeated manual policy work all consume operational capacity that should be spent on continuous control. The issue is not only cost, but that the programme becomes too brittle to keep up with constant SaaS change. Practitioners should read this as a signal that controls dependent on repeated human setup are losing fit in cloud-first operating models.

SaaS visibility without action creates identity blind spots: the article’s core warning is that seeing application activity does not equal governing it. That is especially relevant where third-party participation, collaborative tools, and hybrid data flows blur ownership and accountability. The practitioner conclusion is that identity governance must move closer to the application and the entitlement source, or else visibility will remain informational rather than protective.

Identity governance gap: the modern failure is not a missing dashboard, but a missing closed loop between access grant, use, and removal. CASB can illuminate the problem, but the programme still needs a governed path from discovery to enforcement. For practitioners, that means deciding which control owns lifecycle closure when the application, endpoint, and user are no longer in one network boundary.

What this signals

Remote work has made identity-led SaaS governance more important than network-mediated inspection. When the same user may switch devices, locations, and applications throughout the day, the programme has to manage entitlement and removal directly rather than relying on traffic redirection.

CASB governance gap: the lasting issue is not whether the broker can see cloud traffic, but whether it can support lifecycle closure after access is granted. That distinction matters for teams trying to govern SaaS sprawl, third-party participation, and offboarding at speed.

For IAM and NHI programmes, the practical signal is clear: controls that cannot follow the identity through the full application lifecycle will become increasingly partial in SaaS-first environments.

For practitioners

• Define the SaaS governance boundary Document where CASB visibility ends and where entitlement, offboarding, and privileged access controls must take over for each critical SaaS application.
• Replace manual policy handling Remove any CASB workflow that still depends on repeated manual classification, connector setup, or check-box policy tuning before enforcement can occur.
• Tie remote access to lifecycle controls Align remote endpoint access with joiner-mover-leaver processes so SaaS permissions are granted, reviewed, and removed through the same governance path.
• Audit post-login privilege exposure Review collaborative SaaS tools for users who can continue working inside the application after CASB inspection has ended, then map those gaps to access reviews.

Key takeaways

• CASB remains useful for inspection, but remote work exposes that inspection alone does not govern SaaS access end to end.
• The article shows that manual policy handling, proxy complexity, and incomplete visibility create operational gaps that scale poorly as SaaS adoption grows.
• Teams need lifecycle-aware identity controls around SaaS applications because visibility without entitlement and offboarding enforcement leaves the programme exposed.

Key terms

• CASB: Cloud Access Security Broker is a control layer for visibility, policy enforcement, and data protection in cloud applications. It helps organisations discover unsanctioned apps, apply DLP rules, and monitor cloud usage, making it a governance control for SaaS-heavy environments.
• SaaS Lifecycle Governance: SaaS lifecycle governance is the set of controls that manage applications from onboarding through access assignment, renewal, and decommissioning. It matters because the security value of SaaS management depends on whether the organisation can prove ownership, revoke access, and retire unused tools on demand.
• Proxy-based Inspection: Proxy-based inspection routes user traffic through an intermediate control point so activity can be monitored or filtered before reaching the destination service. It can improve visibility, but it also creates coverage gaps when traffic paths, endpoints, or application protocols do not fit the proxy model.
• Joiner-Mover-Leaver Lifecycle: The joiner-mover-leaver lifecycle describes the access changes that should happen when a person or account is created, changes role, or exits the organisation. It is the basic operating model for keeping entitlements aligned to current need, and it becomes critical when automation replaces manual ticket handling.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload 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 an IAM or identity security programme, it is worth exploring.