Browser-based SaaS security exposes the limits of legacy CASB

At a glance

What this is: This is an analysis of why browser-based SaaS security is being positioned as a response to CASB blind spots in environments with sanctioned and shadow SaaS.

Why it matters: It matters because IAM and security teams need controls that follow identity and activity into the browser, where SaaS access, data movement, and risky behaviour actually happen.

By the numbers:

• Organizations now utilize an average of 371 SaaS apps, a 32% increase since 2021.

👉 Read LayerX Security's analysis of browser-based SaaS security and CASB gaps

Context

SaaS security is the governance problem of controlling who can do what inside cloud applications, across both approved and unsanctioned tools. The challenge is no longer just authentication at the front door. It is visibility and enforcement across the browser session, where most SaaS activity now occurs and where legacy CASB models often lose fidelity.

As SaaS portfolios expand, organisations have to manage sanctioned apps, shadow SaaS, managed devices, and unmanaged devices under the same risk umbrella. That creates an identity and access problem as much as a data-security problem. The primary issue is not the browser itself, but the mismatch between old inspection points and modern app behaviour.

Key questions

Q: What breaks when SaaS governance relies only on CASB visibility?

A: CASB visibility alone breaks down when teams need to stop actions in the moment. API-based and proxy-based controls often see activity too late, miss unmanaged devices, or fail to cover shadow SaaS. The result is a governance model that can report risk but cannot consistently prevent uploads, downloads, or credential misuse inside the browser.

Q: Why do shadow SaaS apps create identity governance risk?

A: Shadow SaaS creates identity governance risk because users can store or move corporate data outside approved identity controls. Without SSO, device trust, and lifecycle oversight, the organisation loses visibility into who accessed the app, what data moved, and whether access was ever properly approved or revoked.

Q: How can teams tell if browser-based SaaS controls are actually working?

A: They should verify that the control can observe and block risky activity during the live session, not only after the event. Useful signals include blocked downloads, prevented uploads, and denied access from unsupported devices. If the product only reports on activity later, it is not functioning as a true enforcement layer.

Q: How should security teams combine browser controls with SaaS access policy?

A: Use browser controls as a runtime enforcement layer and keep access policy upstream in SSO, device trust, and application approval. That combination lets teams reduce shadow SaaS exposure without confusing activity monitoring with entitlement governance. The browser should enforce policy, not define who deserves access.

Technical breakdown

Why CASB architectures miss browser-level activity

Traditional CASB deployments rely on forward proxy, reverse proxy, or API-based inspection. Forward proxy only sees traffic from managed devices, reverse proxy is usually strongest for sanctioned applications, and API access is retrospective rather than real time. None of those models consistently observe in-session actions such as uploads, downloads, copy-paste, or credential reuse once the user is inside the application. That leaves a visibility gap between authentication and activity enforcement. In practice, the control point is too far from the actual behaviour that matters.

Practical implication: map which SaaS actions your current CASB can actually stop in-session, not just what it can report after the fact.

Sanctioned apps and shadow SaaS create different control problems

Sanctioned SaaS apps typically sit behind SSO and policy oversight, so the main risks are malicious access, privilege escalation, and data exfiltration from approved tools. Shadow SaaS is different: it is used outside IT approval, often from unmanaged devices, and can expose corporate data without any governance baseline at all. Browser-based controls aim to cover both domains because the browser is the common interaction layer. That matters when identity, device posture, and user behaviour need to be assessed together rather than separately.

Practical implication: treat shadow SaaS discovery as a governance input, not just an inventory exercise.

Browser-based enforcement shifts the control point closer to user action

A browser extension or browser-native control can observe user activity at the moment it happens, which makes it possible to apply context-aware policy to downloads, uploads, and risky credential behaviour. This is different from relying only on API logs or perimeter inspection. The architecture effectively turns the browser into a policy checkpoint for SaaS interactions, especially where device management is incomplete. The security value is not the form factor itself, but the proximity to the actual action that creates risk.

Practical implication: if you evaluate browser-based SaaS security, test whether it can enforce controls on real user actions across both managed and unmanaged endpoints.

NHI Mgmt Group analysis

Browser proximity is becoming the new SaaS governance control point. Legacy CASB architectures were built for traffic inspection and post-event visibility, not for in-session enforcement across browser-driven SaaS use. That matters because the browser now mediates most application interaction, including approved and unsanctioned tools alike. The implication is that SaaS governance is moving from perimeter inspection to activity-level control.

Shadow SaaS is an identity governance problem before it is a data-loss problem. Unapproved applications create access paths outside normal IT oversight, which means organisations lose the chance to apply SSO, policy, and lifecycle governance consistently. The result is not just hidden data movement, but unmanaged identity spread across personal and corporate contexts. Practitioners should treat discovery as the first governance step, not the last remediation step.

Browser-based controls narrow the gap between authentication and authorisation, but they do not replace identity policy. The browser can observe and block risky actions in real time, yet it still depends on upstream identity decisions about who should have access in the first place. That makes it a compensating control for weak SaaS visibility, not a substitute for access governance. The lesson is to align browser enforcement with SSO, device trust, and application approval.

Named concept: browser-native SaaS enforcement. This model places policy decisions at the point where SaaS activity occurs, rather than relying only on proxy or API layers. It addresses the blind spot between login and behaviour, which is where many SaaS risks now accumulate. Practitioners should expect more governance tools to shift toward runtime control rather than retrospective monitoring.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly identity compromise can repeat once control is lost.
• For the broader identity control model, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and sprawl issues that underpin runtime enforcement.

What this signals

Browser-based SaaS security is likely to become part of the broader identity control stack, not a standalone point product. As SaaS usage expands, the question for practitioners is whether they can enforce policy at the moment of action instead of relying on retrospective logs and post-event review.

Browser-native SaaS governance: the practical shift is from inspecting application traffic to controlling user behaviour inside the session. That change matters most where unmanaged devices and shadow apps make traditional perimeter assumptions unreliable.

With 70% of organisations already granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, the same governance instinct applies across SaaS, machine identity, and agentic systems: if the control point is not where the action happens, it will miss the decision that matters.

For practitioners

• Audit browser-side SaaS visibility coverage Identify which SaaS actions are visible only in logs today and which are enforceable in-session. Test managed and unmanaged devices separately, because proxy and API controls often behave differently across those environments.
• Inventory sanctioned and shadow SaaS separately Maintain a distinct view of approved applications and unsanctioned usage so policy design reflects real user behaviour. Use discovery data to decide where SSO, browser enforcement, or application restriction is the right control.
• Align browser enforcement with identity policy Tie browser-level rules to SSO, device trust, and application approval so controls remain consistent across the session lifecycle. This reduces the risk of blocking harmless activity while leaving unauthorised data movement untouched.
• Test real-time blocks for risky SaaS actions Validate whether uploads, downloads, and credential reuse can be blocked at the point of action rather than detected after the fact. If enforcement is retrospective, the control is informational, not preventative.

Key takeaways

• Legacy CASB models are increasingly mismatched to browser-mediated SaaS behaviour, especially when unmanaged devices and shadow apps are in scope.
• The practical issue is not just visibility, but whether identity and activity controls can stop risky actions during the live session.
• Teams should align browser enforcement with SSO, device trust, and SaaS approval so runtime control and access governance work together.

Key terms

• Shadow SaaS: Shadow SaaS is software used by employees or teams without formal IT or security approval. It creates governance risk because corporate data can move through applications that are outside standard identity, logging, and lifecycle controls, leaving the organisation blind to access, sharing, and retention behaviour.
• CASB: A Cloud Access Security Broker is a control layer used to inspect and govern access to cloud applications. In practice, many CASB designs are strongest at discovery or logging, while real-time SaaS activity control becomes harder when devices are unmanaged or the application is accessed outside the broker's preferred path.
• Browser-native enforcement: Browser-native enforcement applies security policy inside the browser where the user interacts with the application. It can observe and block actions such as uploads, downloads, or risky credential use in real time, which makes it useful when network-based or API-based controls cannot see enough of the session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by LayerX Security: browser-based SaaS security and the limits of legacy CASB. Read the original.