Securing the browser vs. securing the organization via the browser — what's the difference? Most browser security solutions defend against the browser being hacked, but these aren't the attacks that are actually leading to major breaches.
Securing the browser vs. securing the organization via the browser — what's the difference? Most browser security solutions defend against the browser being hacked, but these aren't the attacks that are actually leading to major breaches.
TL;DR: Not all browser security investments address the same threat. Seraphic (Crowdstrike) focuses on browser exploitation, SquareX (ZScaler) on malware sandboxing, LayerX on internal governance. None of these address the attacks that are actually causing the most damaging breaches today: identity theft, credential abuse, and session hijacking that play out entirely inside the browser using legitimate authentication flows. Push Security is built specifically for that threat model — delivering the greatest coverage against the most damaging attacks, without the user friction, operational management burden, or stability risks associated with other solutions.
When a security team evaluates browser security solutions, they're usually asking the right question: “How do we protect our users as they work in the browser?”
But the answer they get from many vendors is shaped by a fundamentally different threat model — one that treats the browser as a piece of software to be hardened against exploitation, rather than as the arena where your users’ identities get stolen.
This distinction has enormous consequences for your security posture and the return you can expect from your investment in a new solution.
Two different problems, dressed the same
When it comes to protecting users as they work in the browser, security tools typically fall into one of two camps:
The first camp: represented by solutions like Seraphic (now CrowdStrike) — is built around the threat of attacking the browser itself. The architecture is designed to scramble the browser’s JavaScript runtime and prevent exploits from detonating and breaking out of the browser sandbox. This is browser hardening: defending the browser as software against exploitation by attackers who want to compromise the underlying device.
The second camp: and the one Push Security occupies uniquely, focuses on what happens inside the browser when a user is working normally. Phishing pages harvesting credentials. Session tokens being stolen. Malicious OAuth applications being granted access through social engineering. Adversary-in-the-middle proxies intercepting authentication flows. These attacks don't exploit the browser. They exploit the human — and now agents — using it via the browser's legitimate capabilities (think of it as LOTL, browser edition).
The question for any security team evaluating this space: which of these threat models presents the greatest risks to my organization?
How organizations are actually being breached
Let's look at the major breach campaigns of the last three years without the marketing filter and a pattern emerges immediately. Scattered Spider and its successors breached MGM Resorts, Caesars, M&S, JLR, and Salesforce customers — not through browser exploits, but through social engineering, phishing and Adversary-in-the-Middle attacks that stole session tokens and SSO credentials.
You can read about Scattered Lapsus$ Hunters and ShinyHunters’ 2026 campaigns and TTPs in our dedicated blog posts.
In every case, the attack happened in the browser — using stolen identities to log into legitimate cloud services — not on the browser through exploitation of the browser engine itself.
The data from major threat intelligence sources is unambiguous:
Identity weaknesses played a material role in almost 90% of Unit 42 incident response investigations (Palo Alto Networks Unit 42 IR Report)
Credential abuse and phishing combined accounted for 38% of all breaches, making identity the single largest breach vector (Verizon DBIR 2025)
Cloud-conscious intrusions — attackers using stolen identities to access cloud services — rose 37% in 2025, up 266% among state-nexus actors (CrowdStrike 2026 Global Threat Report)
In cloud-related incidents, identity issues drove initial access in 83% of cases (Mandiant / Google Cloud Threat Horizons H1 2026)
82% of attack detections are now malware-free — they don't touch the endpoint and abuse legitimate access and functionality (CrowdStrike 2026 Global Threat Report)
49% of organizations suffered a successful browser-based attack in the last 12 months (Omdia 2026)
These aren't edge cases. This is now the primary attack playbook.
The economics of attack choice
Attackers are rational actors. They pick the cheapest, most reliable path to their objective. The economics of browser exploitation versus identity theft tell the whole story:
Chrome sandbox RCE exploit (bug bounty value): $250,000
IAB-provided IdP admin account: ~$3,000
1-year phishing kit rental (PhaaS): ~$1,000
Bulk stolen credential list: ~$15
Browser zero-days accounted for just 9% of all zero-days reported to Google in 2025 — described by Google's own researchers as a "historic low." Chrome's sandbox architecture, site isolation, and hardware-backed security features are the result of years of sustained hardening investment. When a browser vulnerability is discovered, Google typically deploys a patch within days.
It's worth heading off the obvious counterargument: won't AI-assisted vulnerability discovery eventually make browser exploits cheaper? Perhaps — but it will simultaneously make them easier for browser vendors to find and patch, and vendors like Google and Microsoft have the engineering capacity and financial incentive to scale AI-driven remediation far faster than attackers can scale exploit development.
The bottom line: browser exploits are extraordinarily expensive to develop, increasingly difficult to execute reliably against a hardened modern browser, and patched rapidly when discovered. In sharp contrast, identity attacks are cheap to run, highly scalable, and have a low technical barrier to adoption — that’s why they’re responsible for the overwhelming majority of enterprise breaches. Attackers have voted with their resources.
What you're actually buying with each vendor
Understanding the core architectural choice each vendor has made helps decode what their solution can and cannot protect you from.
Seraphic (CrowdStrike)
Seraphic's architecture is built to inject into the browser's JavaScript runtime at the OS layer, scrambling browser internals to prevent exploits from executing. This is a technically sophisticated approach to a technically interesting problem that is, by every threat intelligence measure, not the problem causing enterprise breaches at scale.
Beyond the threat model mismatch, there are structural concerns with the approach itself. Injecting an agent into the browser's JS runtime is a technique with well-documented stability consequences. This is the same approach antivirus vendors have used for years, often at the cost of system stability. Seraphic now runs alongside the CrowdStrike Falcon sensor on managed devices, combining two heavyweight agents on the same machine. For any organization with CrowdStrike already deployed, the question isn't theoretical: how has that combination been validated in production environments?
There's also the managed-device limitation. Seraphic requires a kernel-level agent, which means it loses meaningful capability on unmanaged devices, BYOD machines, and contractor endpoints. This is not a niche concern: according to Omdia's 2026 browser security survey, 32% of users access corporate applications from unmanaged devices at least occasionally. Agent-based solutions are blind to nearly a third of your actual attack surface by design. The Okta breach began on a support engineer's personal device, where corporate credentials had synced via Chrome's built-in profile sync. No agent, no visibility.
Teams evaluating Seraphic today are also buying into an integration roadmap, not a shipped capability. The acquisition by CrowdStrike closed in early 2026. The work of wiring browser telemetry into Falcon Fusion and correlating it with endpoint signals is currently a promise, not a production feature.
SquareX (Zscaler)
SquareX's core capability is sandboxing suspicious file downloads inside disposable browser containers before they reach the endpoint. This is a legitimate approach to a real but declining problem. 82% of attack detections are now malware-free (CrowdStrike 2026 Global Threat Report) — attacks don't arrive as files to be sandboxed, they arrive as authenticated sessions. And the delivery channel shift makes the picture even starker: across Push's customer base, 1 in 3 phishing payloads are now delivered outside of email entirely — via social media, ads, and messaging platforms — and 4 in 5 ClickFix payloads arrive through search engines, not email. The threat that SquareX was architecturally designed to address is a shrinking share of the actual attack surface, and it's shrinking fast.
Zscaler already has sandboxing built into ZIA. For an existing Zscaler customer evaluating SquareX, the honest question is: what does this add beyond some extension analysis capability and what you already have? The AiTM phishing campaign that stole your user's credentials and accessed your cloud applications generates no malicious file, triggers no sandbox, and produces no network signal for Zscaler's traffic inspection to catch — because it happened entirely inside a browser session using legitimate authentication flows.
The acquisition also raises product focus questions. Being absorbed into a network-centric platform means SquareX is now optimized for Zscaler's priorities, not for standalone browser detection and response. Teams that care about investigation, threat hunting, and incident response should ask specifically what SquareX adds in those workflows under Zscaler ownership.
LayerX
LayerX is primarily a policy enforcement and risk scoring platform focused on internal governance — controlling which applications employees access, what data moves through the browser, and whether behavior complies with internal rules.
Push Security covers that ground too. Push provides full visibility over AI tool usage, shadow SaaS, unmanaged identities, and data loss vectors — including sensitive data submitted through AI prompts, file uploads to personal cloud destinations, and OAuth grants to third-party applications. The same browser telemetry that detects external attacks also surfaces insider risks and powers DLP controls and compliance audit evidence, all from a single extension.
The critical difference is that Push goes significantly further. Where LayerX scores risk and enforces policy, Push detects active external attack techniques in real time: AiTM phishing kits as they execute, session tokens being stolen, ClickFix lures through behavioral analysis of page structure. These are the attacks causing the most damaging breaches today, and they don't surface on a risk score until after the damage is done. Push addresses both the governance problem and the external threat problem from the same platform. LayerX addresses only the first.
Securing the organization via the browser: Push Security
Push Security is built on a different architectural premise: the browser is not primarily a piece of software to harden against exploitation. It is the primary workplace, the primary SaaS access point, and the arena where the majority of modern identity attacks play out. The goal is to secure the organization via the browser — not just to secure the browser itself.
This means Push's detection surface is built around the attacks that are actually causing breaches: adversary-in-the-middle phishing, ClickFix and its many variants, credential stuffing against shadow identities, session token theft and replay, OAuth consent abuse, and the full spectrum of identity-based initial access techniques that dominate the modern threat landscape.
The deployment model reflects the threat model. Push deploys as a lightweight browser extension — no kernel-level agent, no device dependency, no migration to a new browser. It works on managed and unmanaged devices, across every traditional, enterprise and AI browser where employees are doing work and attackers are targeting them. The operational overhead is minimal by design: Push has been deployed to 100,000 users in under one hour during normal business hours.
Detection philosophy: targeting what attackers can't change
Push's detection approach targets attacker TTPs rather than indicators of compromise that attackers can rotate in minutes. 95% of attacks detected by Push used some form of bot protection service — meaning the specific domain and IP were deliberately obscured. If your primary detection relies on blocklists, recent reports tell us that 89% of phishing domains will evade you: because they're active for less than two days, they can be spun up, down, and replaced faster than blocklists can keep up.
Behavioral detection of the attack technique — the AiTM relay structure, the credential entry on a cloned login page, the anomalous session context — remains valid regardless of what domain the attack is hosted on or which PhaaS kit was used to build it.
Measuring the identity attack surface (it's bigger than you realize)
Because Push has visibility into actual login behavior across thousands of organizations, it can quantify the attack surface that identity-based attacks exploit. Of the last million logins observed by Push:
15 corporate identities were identified per employee used to access cloud apps
1 in 4 were password logins, not SSO
2 in 5 were not protected by MFA
1 in 5 used a weak, breached, or reused password
And it's not just login hygiene. Across Push's customer base, 46%+ of browser extensions in corporate environments have the permission combinations required for direct account takeover via session theft if they are malicious or compromised by an attacker. Most organizations have no inventory of what's running in their employees' browsers, let alone visibility into what those extensions can access.
These aren't theoretical vulnerabilities. They're the specific weaknesses that browser-native identity attacks are designed to exploit. This visibility turns browser security from a reactive posture into a proactive one — you can see and remediate the identity weaknesses before an attacker exploits them, not just detect the attack while it's in progress.
The ROI case
The ROI question for any security investment is: what quantum of real risk does this tool address, at what cost in money and operational friction?
That calculation looks very different depending on your threat model.
A solution focused on browser engine exploits and sandbox escapes is defending against an attack category that represents a tiny fraction of actual enterprise breaches, requires extraordinary attacker resources to execute, and is increasingly mitigated by browser vendors themselves through hardening and rapid patching. Chrome's automatic update cycle means that even when a browser vulnerability is discovered and disclosed, it is typically in front of users as a patch within days. The defenders here are Google, Mozilla, and Microsoft — with multi-billion dollar security teams and full access to the browser internals.
A solution focused on identity attacks via the browser — phishing, credential theft, session hijacking, OAuth abuse, malicious browser extensions — is defending against the primary cause of enterprise breaches, one that is accelerating (cloud-conscious intrusions up 37% in 2025, browser-based attacks increasing at 68% of organizations over the past two years per Omdia) and increasingly automated through PhaaS infrastructure that gives low-skill attackers enterprise-grade capability for $1,000 a year.
There's also a forward-looking dimension. The threat landscape isn't moving toward more browser exploitation. It's moving further into identity abuse. AI-powered phishing lowers the social engineering barrier. Agentic browsers will automate credential stuffing and account takeover at a scale that wasn't previously possible. And attackers are already adapting to authentication improvements: device code phishing has increased 37x since the start of 2026, a technique specifically designed to circumvent passkeys by bypassing the authentication flow entirely — the attacker never encounters a login page. The investment in identity-centric browser detection compounds over time as the attack surface evolves in the same direction.
Solutions optimized for browser exploitation are defending against a shrinking attack category. Browser vendors are very good at closing those vulnerabilities, quickly. The ROI trajectory points the wrong way.
The verdict
Browser security is a real and growing priority — according to Omdia Research, it is now a top-five priority for 88% of security leaders and the top priority for 26% of them. 85% expect their browser security spending to increase over the next 12–24 months. The question isn't whether to invest. It's what to invest in.
The browser is where your users work, where attackers target them, and where the identity attacks causing the majority of enterprise breaches play out. But not all browser security investments address the same problem.

Solutions like Seraphic are built to defend against a browser being exploited by an attacker trying to break out of the sandbox — an attack that represents a historic low as a share of enterprise incidents, and one that Google's own hardening and rapid patching increasingly mitigates automatically. SquareX is built around malware sandboxing — a legitimate but declining share of the initial access landscape, and a capability Zscaler's existing customers already partially have. LayerX focuses on internal governance rather than external threats.
Push Security is built to defend against the attacks that are behind the major breaches hitting the headlines: identity theft, credential abuse, session hijacking, and the full identity attack kill chain that plays out inside the browser every time an attacker logs in as your user. Every major threat intelligence report points to these as the primary breach vectors. The economics of attack choice guarantee they'll remain so.
The security team that deploys Push gets the greatest coverage of the highest-impact threats, on managed and unmanaged devices, with the lightest operational footprint. That is the browser security investment that moves the needle on real organizational risk — not the browser security investment that defends the software nobody's actually attacking.
