Why do proxy-based CASB deployments struggle in remote and BYOD environments?

Why Proxy-Based CASB Assumptions Break in Remote and BYOD Use

Proxy-based CASB designs work best when user traffic follows a managed path that can be inspected, logged, and policy-checked in one place. Remote work and BYOD break that path because devices are unmanaged, sessions are split across browsers and native apps, and users can move between home networks, mobile networks, and SaaS APIs without a stable interception point. That makes policy enforcement uneven and visibility incomplete.

This matters because CASB programs are often judged on whether they can see the full set of cloud interactions, not just the traffic that happens to traverse a proxy. When the proxy is bypassed, controls such as DLP, shadow IT discovery, and session governance become inconsistent. The same problem appears in broader identity work: NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, a reminder that control loss often starts with visibility loss rather than with a single failed block.

For practitioners, the lesson is that proxy architecture is a path control, not a complete cloud control plane, which is why modern programs often align it with broader guidance such as the NIST Cybersecurity Framework 2.0 and the NHI governance issues discussed in Ultimate Guide to NHIs. In practice, many security teams discover CASB blind spots only after data has already moved through an unmanaged app or device, rather than through intentional policy design.

How Proxy CASB Fails Operationally Across Devices and Traffic Paths

In a controlled office network, a proxy can terminate sessions, inspect content, and apply policy before access reaches the SaaS app. In remote and BYOD environments, that model weakens because the endpoint is no longer trusted, the traffic path is no longer predictable, and many applications use APIs, embedded browsers, or background sync that do not respect a single proxy choke point. The result is partial inspection and inconsistent enforcement across the same user’s workflows.

Operationally, the failure is usually not that the proxy is “down.” It is that the architecture assumes the proxy will always be in-line. That assumption fails when users authenticate directly to SaaS, when mobile apps talk over native channels, or when browser-based sessions shift between authenticated and unauthenticated contexts. Current guidance suggests treating this as a visibility and control-placement problem, not just a network routing problem.

• Remote access can bypass the proxy through direct-to-cloud paths and split-tunnel VPNs.
• BYOD devices often cannot support endpoint agents or certificate-based interception reliably.
• API traffic may never present the same session metadata as browser traffic.
• Unsanctioned apps often appear first as normal cloud usage, then later as data exposure.

That is why cloud security programs increasingly pair CASB with identity-aware access, endpoint posture signals, and policy evaluation at the point of request. The Schneider Electric credentials breach is a useful reminder that exposed credentials and uncontrolled access paths amplify cloud risk once a trust boundary is weak. These controls tend to break down when unmanaged devices access SaaS over native APIs because the proxy never sees every transaction.

Where Organisations Need a Different Control Model

Tighter inspection often increases friction for users and support teams, requiring organisations to balance coverage against usability and device diversity. That tradeoff is especially visible in BYOD programs, where the goal is usually business enablement rather than full device control. In that environment, best practice is evolving toward layered controls instead of relying on a single proxy point.

For cloud-first environments, that usually means combining session controls, identity-based access, device risk checks, and API governance. The proxy still has value for managed endpoints and web sessions, but it should not be the only enforcement point. NHI Mgmt Group’s guidance on Ultimate Guide to NHIs is relevant here because the same visibility gaps that affect service accounts also affect cloud applications and automation paths. The practical question is whether the organisation can govern access when the session does not traverse a predictable perimeter.

There is no universal standard for this yet, but current guidance across cloud security practice points toward control planes that follow the identity and the workload rather than the network location. That is the more resilient model for remote and BYOD use, especially where users can switch devices, apps, and networks throughout the day.

Related resources from NHI Mgmt Group

• Why do perimeter-based security models fail in hybrid environments?
• Why do secrets create disproportionate risk in NHI environments?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• When does regex-based secret detection become too unreliable for production use?