By NHI Mgmt Group Editorial TeamBased on Push Security: “Why "good enough" isn’t enough: the case for best-of-breed browser security” (May 19, 2026)

TL;DR: Browser security has consolidated quickly, with three acquisitions in five months and 85% of organisations expecting to increase spend over the next 12 to 24 months, according to Push Security. The market signal is clear, but practitioners still have to separate platform convenience from the browser-layer identity controls needed to stop browser-based attacks.


At a glance

What this is: This is an analysis of browser security market consolidation, arguing that acquisitions are not the same as operational coverage for browser-layer identity threats.

Why it matters: IAM, NHI, and identity architecture teams need to evaluate whether consolidated browser tooling can actually govern authentication, session, and OAuth risks where attacks now occur.


Context

Browser security has become a control point for identity attacks, phishing, OAuth abuse, and browser-mediated access. When consolidation speeds up, the governance question is no longer whether a platform offers a browser capability, but whether that capability is built to detect and control the techniques that attackers are actually using.

For identity programmes, the issue cuts across human access, NHI exposure, and emerging AI usage in the browser. If teams accept a bundled feature set without testing how it handles session theft, consent abuse, and unmanaged browser activity, they can mistake procurement simplification for reduced risk.


Key questions

Q: How should security teams evaluate browser security after major market consolidation?

A: They should separate platform convenience from control effectiveness. A consolidated vendor may reduce procurement complexity, but teams still need evidence that the browser layer detects real identity attacks, governs sessions, and handles OAuth abuse. Evaluation should focus on observed technique coverage, operational fit, and roadmap velocity, not on whether the capability comes bundled.

Q: Why do browser attacks bypass so many traditional security controls?

A: Browser attacks bypass traditional controls because the malicious action often happens inside a legitimate browser session. Email gateways may never see the lure, EDR may only see a user action, and network tools may only observe normal traffic. The control failure is coverage, not just detection quality.

Q: What are the signs that browser security controls are not keeping up with modern phishing tactics?

A: Common signs include employees clicking malicious links, repeated exposure to spear phishing and browser in the browser attacks, and heavy reliance on external threat feeds instead of direct inspection. If teams cannot evaluate page structure and behaviour in real time, they will miss deceptive pages that look legitimate to users but are built to capture credentials or session access.

Q: What should teams do when browser security arrives as part of a broader platform?

A: Treat it as a separate control decision, not a packaging decision. Validate whether the acquired capability can still deliver the browser-layer visibility, research cadence, and detection depth your environment needs, and confirm that integration work has not diluted response speed or coverage.


Technical breakdown

Why browser-layer identity controls matter more than endpoint-only coverage

Browser-layer attacks often bypass controls that sit above or beside the session. The browser is where credentials are entered, OAuth consent is granted, sessions are established, and extensions can manipulate workflow in real time. Endpoint, network, and email tools may see the surrounding traffic, but they often miss the identity event itself. That is why browser security increasingly overlaps with IAM, SSO, MFA, and OAuth governance rather than sitting in a separate security category.

Practical implication: validate whether browser security controls can observe and act on identity events inside the session, not just on surrounding infrastructure signals.

IoCs are too weak for fast-rotating browser attacks

Indicator-based detection depends on known-bad domains, URLs, or IPs. In browser attacks, those indicators can disappear within hours or even minutes, which makes blocklist logic inherently reactive. Behavioural detection is stronger because it looks for technique patterns such as page structure, script activity, consent-flow manipulation, and credential-harvest mechanics. That distinction matters when attackers use fresh infrastructure to evade reputation-based controls.

Practical implication: require technique-based detection evidence, not just proof that the product recognises known phishing infrastructure.

Acquisition often changes the product roadmap before it changes the risk

When a specialist browser security product is absorbed into a broader platform, engineering priorities usually shift toward integration, packaging, and portfolio fit. That can slow the pace of new detections, especially where the acquired capability depends on rapid response to novel attacker tradecraft. In browser security, slower innovation is not a cosmetic issue, because attack techniques evolve quickly and are increasingly shaped by AI-assisted tooling.

Practical implication: assess post-acquisition roadmap velocity, detection release cadence, and support for novel techniques before treating consolidation as a capability win.


  • Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
  • AnyDesk breach 2024: Attackers compromised AnyDesk's production systems; it revoked its code signing certificate and reset all portal passwords. Stolen keys were reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Browser security consolidation is a governance test, not just a market event. When three acquisitions land in five months, the real question is whether platform bundling can keep pace with browser-native identity attacks. The browser has become the place where credential entry, session theft, OAuth abuse, and shadow SaaS activity converge, so procurement convenience must be weighed against control depth.

Browser-layer controls now sit inside the identity perimeter. This is not a point product discussion anymore. Browser security now governs how users authenticate, how sessions persist, how extensions interact with identity flows, and how AI tools are accessed in-session. That makes browser security part of IAM and NHI governance, not a bolt-on to endpoint strategy.

Technique-based detection is becoming the baseline expectation. Known-bad lists cannot keep up with short-lived infrastructure and AI-assisted phishing operations. The category will increasingly split between products that inspect attacker behaviour inside the session and products that depend on reputation signals inherited from older control models. Practitioners should judge tools on how they detect technique, not on whether they share a platform logo.

Browser security consolidation creates identity governance drift if teams confuse ownership with coverage. A platform vendor can own the contract while still leaving gaps in consent abuse, session manipulation, extension governance, and unmanaged AI usage. The implication is simple: identity programmes need separate evidence for control effectiveness, even when the control arrives inside an existing stack.

What this signals

Browser consolidation raises the bar for evidence. Security buyers should assume that a bundled browser capability must prove itself against live identity attack techniques, not against stale test cases or generic phishing demos. The control question is whether the browser layer can see and govern what happens during authentication, consent, and session use.

Identity governance now extends into the browser session. That means browser extensions, OAuth grants, MFA gaps, and unmanaged AI usage all belong in the same governance conversation. If those events are invisible, the identity programme is only governing the outer edge of access, not the place where access is actually exercised.


For practitioners

  • Define browser security outcomes before vendor evaluation Specify the exact outcomes you need, such as account takeover prevention, advanced phishing detection, identity posture hardening, browser extension security, and OAuth governance.
  • Test for technique-based detection Ask vendors to prove they can detect live attacker behaviour such as AiTM phishing, ClickFix, and consent abuse rather than relying on known-bad indicators.
  • Challenge acquired-product roadmaps Review detection release cadence, research output, and feature changes since acquisition to understand whether engineering effort is shifting toward integration instead of innovation.
  • Assess browser governance across identity and AI use Map browser-layer visibility for SSO bypass, MFA gaps, OAuth integrations, unmanaged extensions, and public GenAI usage so policy covers what happens inside the session.

Key takeaways

  • Browser security consolidation does not eliminate the need for strong browser-layer identity controls, because the browser is where many modern attacks now land.
  • The article argues that platform bundling can improve procurement simplicity while still leaving technique-detection and governance gaps unresolved.
  • Practitioners should test browser security products on live attack behaviour, roadmap pace, and control visibility inside the session, not on bundled feature lists.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationBrowser-based credential capture and MFA bypass sit at the center of this article.
NHI-05 — Overprivileged NHIOAuth consent abuse and browser-mediated access can create excessive delegated privilege.
NHI-10 — Human Use of NHIEmployees using browsers interact with tokens, extensions, and AI tools that behave like NHIs in practice.
Recommendation — Test browser controls against authentication abuse, not just known-bad infrastructure. Review delegated browser-access paths for privilege scope that exceeds business need. Govern browser-mediated access paths where human activity creates machine-like credential exposure.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article centres on governing who can do what in the browser session and OAuth flows.
Recommendation — Apply PR.AA-05 to validate browser-session entitlements and delegated access.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe article describes credential theft, session hijacking, and post-entry movement enabled through the browser.
Recommendation — Map browser attack techniques to credential access and lateral movement to prioritise detection.

Key terms

  • Browser-Layer Identity Control: The use of browser telemetry and policy to govern identity events that happen inside the session, such as login, consent, extension activity, and data movement. It treats the browser as part of the identity stack, not just a rendering surface.
  • Technique-level detection: Technique-level detection identifies the method of attack rather than the artefact an attacker used to deliver it. In browser-based identity abuse, that means watching interaction sequences, redirect behaviour, and protocol misuse that remain stable even when infrastructure, domains, and frontends change.
  • OAuth Governance: OAuth governance is the discipline of controlling delegated app access after consent is granted. It covers ownership, scope, review, revocation, and downstream propagation, because the real risk often emerges after the initial approval when connected systems inherit trust.
  • Browser Security: Browser security is the set of controls that protects data moving through web sessions, where many users now access SaaS apps, upload files, and interact with AI tools. It helps detect, block, redact, or monitor sensitive content in the browser before information is copied, shared, or exposed outside policy.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org