Notifications
Clear all
Topic starter
12/06/2026 9:12 pm
TL;DR: Enterprises now use an average of 371 SaaS apps, a 32% increase since 2021, and that expansion has outgrown legacy CASB visibility and control models, according to LayerX Security. Browser-level enforcement matters because SaaS governance now spans sanctioned apps, shadow apps, managed devices, and unmanaged devices at once.
NHIMG editorial — based on content published by LayerX Security: browser-based SaaS security and the limits of legacy CASB
By the numbers:
- Organizations now utilize an average of 371 SaaS apps, a 32% increase since 2021.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Audit browser-side SaaS visibility coverage Identify which SaaS actions are visible only in logs today and which are enforceable in-session.
- Inventory sanctioned and shadow SaaS separately Maintain a distinct view of approved applications and unsanctioned usage so policy design reflects real user behaviour.
- 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.
What's in the full article
LayerX Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Architecture-by-architecture comparison of forward proxy, reverse proxy, and API-based CASB coverage
- Browser extension deployment considerations for managed and unmanaged endpoints
- Examples of in-session policy enforcement for uploads, downloads, and credential reuse
- How LayerX describes integration with identity providers and user activity monitoring
👉 Read LayerX Security's analysis of browser-based SaaS security and CASB gaps →
SaaS security blind spots: what legacy CASB misses in practice?
Explore further
12/06/2026 11:07 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Browser-based SaaS security exposes the limits of legacy CASB
