Browser security consolidation is testing identity governance models

At a glance

What this is: Browser security is consolidating around major platforms, and the key finding is that identity-driven browser attacks are outpacing broad platform coverage.

Why it matters: This matters because IAM, NHI, and autonomous-system programmes increasingly depend on browser-layer controls to stop account takeover, OAuth abuse, and AI-driven misuse.

By the numbers:

• The browser security market already accounts for 12.6% of the average security budget.
• 85% of organizations expect to increase that spend over the next 12 to 24 months.
• 92% of organizations allow employees to use public GenAI applications.

👉 Read Push Security's analysis of browser security consolidation and identity risk

Context

Browser security is now the control point where user identity, session trust, OAuth consent, and AI-assisted browsing meet. That makes the category materially different from endpoint or network security, because the attack surface is defined by what happens inside the session rather than outside it.

The consolidation wave shows that buyers are being pushed toward platform bundling just as browser-based identity attacks are becoming more industrialized. For IAM and NHI teams, the practical question is whether a consolidated stack can still see the session-level techniques that drive account takeover, token theft, and unsafe AI usage.

The browser has become the place where people work, NHIs authenticate, and emerging AI tools operate. When that layer is weak, every identity programme above it inherits the same blind spots, even if the rest of the stack looks mature.

Key questions

Q: How should security teams evaluate browser security for identity risk?

A: Security teams should evaluate browser security by asking whether it can see and stop identity abuse inside the session, not just block known malicious sites. The right test is whether it detects AiTM phishing, OAuth consent abuse, token theft, and device code attacks in live conditions. If those events are invisible, the control is not covering the real identity risk.

Q: Why do browser controls matter so much for IAM programmes?

A: Browser controls matter because the browser is where modern identity attacks are executed and where trust is created at login time. IAM policy may exist at the IdP, but attackers exploit the browser to capture sessions, approvals, and tokens after authentication. That makes browser telemetry a necessary input for access governance and incident response.

Q: What do security teams get wrong about bundled browser security?

A: Teams often assume that a bundled browser feature is adequate if it reduces vendor count. In practice, the question is whether the control can detect the identity techniques driving real breaches, including fresh phishing infrastructure and browser-based token abuse. Convenience does not close a control gap if the telemetry is too shallow.

Q: How can organisations tell if browser security is actually working?

A: They should look for evidence that the control catches live attacks that other layers miss, such as AiTM phishing, ClickFix, risky OAuth consent, and unsanctioned AI usage. They should also measure whether the tool produces usable identity findings for remediation, not just high-volume alerts. A working control changes governance decisions.

Technical breakdown

Why browser security now sits inside identity attack paths

Modern browser attacks increasingly target identity rather than code execution. Attackers use adversary-in-the-middle phishing, device code abuse, OAuth consent manipulation, and session hijacking to get valid access without triggering traditional perimeter controls. Those techniques succeed because the browser is where authentication happens and where tokens, sessions, and consent flows are exposed in real time. A product that only watches domains or malware indicators will miss the behaviour that actually matters: how the session was established, what was approved, and how the attacker persisted after login.

Practical implication: evaluate browser security as an identity control plane, not as a generic web protection layer.

IoC detection fails when attacker infrastructure is disposable

Indicator-based detection relies on known-bad domains, URLs, IPs, or hashes. That model breaks when attackers rotate infrastructure every few minutes, use bot protection, and generate fresh phishing kits faster than blocklists update. In browser security, the important signal is technique, not infrastructure. Behavioural telemetry can identify the page structure, user interaction pattern, consent sequence, or clipboard abuse associated with a live attack even when the external indicators are brand new.

Practical implication: test for technique-based detection against live attacker behaviour, not static sample URLs.

Browser telemetry is now the only reliable source for some identity risks

Many of the highest-value browser findings are invisible from endpoint, network, and email controls. Session events reveal password use where SSO should exist, MFA gaps, risky browser extensions, shadow SaaS, OAuth integrations, and AI tools that employees are using outside policy. That makes the browser a unique telemetry source for both human IAM and NHI-adjacent governance. Without visibility at this layer, security teams cannot reliably tell whether access, consent, and session trust are being created in sanctioned ways.

Practical implication: align browser telemetry with IAM and SaaS governance workflows so identity risk can be acted on, not just observed.

Threat narrative

Attacker objective: The attacker wants durable trusted access that bypasses authentication controls and can be used to move through cloud apps, identities, and data without raising traditional alerts.

1. Entry occurs through browser-mediated identity abuse, such as AiTM phishing, device code manipulation, or malicious OAuth consent.
2. Escalation follows when the attacker captures a valid session, token, or approved application grant that survives the initial login event.
3. Impact comes from persistent account takeover, unauthorized SaaS access, and downstream data theft or extortion conducted through trusted browser sessions.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser security consolidation is a governance problem before it is a procurement story. The market is moving quickly toward platform bundling, but identity risk does not consolidate at the same pace. If the browser is where credentials are entered, tokens are minted, and AI tools are invoked, then the buyer is really choosing how much session-level identity visibility they are willing to lose. Practitioners should treat consolidation as an architectural decision, not a line-item savings exercise.

Browser-based identity attack paths now define the control gap. The issue is no longer whether a platform can block known phishing pages, but whether it can detect live identity abuse inside the session. That is a different problem from endpoint malware prevention or network filtering, and it requires behavioural telemetry that sees consent flows, token use, and user interaction patterns. The practitioner conclusion is straightforward: if a browser tool cannot see the identity event, it cannot govern the identity risk.

Identity posture hardening now depends on the browser layer. The browser is where password reuse, missing MFA, risky extensions, and shadow SaaS often become visible for the first time. That creates a new governance boundary for IAM teams, because policy can no longer stop at the IdP. The practical implication is that browser controls must feed access, investigation, and remediation workflows across human identity and NHI-adjacent access paths.

Session-level defence is becoming the decisive category capability. Attackers are using AI to compress the time between phishing creation, infrastructure rotation, and live exploitation, which makes old blocklist-style controls structurally weaker. The market is rewarding vendors that can observe and act within the session, not merely classify known infrastructure. Security teams should assume the browser is now an active control point in identity defence, not a passive workspace.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For the broader identity picture, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility, sprawl, and privilege issues that browser-layer governance now exposes.

What this signals

Browser-layer governance is becoming a required input to identity programmes, not a specialist add-on. With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is signalling that identity risk is now being managed across more than just human login flows. For practitioners, that means browser telemetry, session evidence, and SaaS consent data need to sit alongside IdP and PAM signals in the same operational workflow.

Session visibility will separate teams that can govern identity from teams that can only report on it. The practical shift is toward controls that can explain why access was trusted, not just whether authentication succeeded. That is especially relevant where AI tools, browser extensions, and shadow SaaS create access paths that do not appear in standard IAM reports.

Browser security is starting to expose the same governance pattern seen in NHIs: too much access is invisible until it is exploited. That makes the browser a strong candidate for unified identity-risk analysis across human users, service accounts, and emerging AI-driven workflows. Practitioners should expect this layer to become part of baseline Zero Trust and access-review design, not a separate tooling discussion.

For practitioners

• Re-evaluate browser controls as identity controls Map browser security requirements to the identity attacks you actually need to stop, including session hijack, OAuth consent abuse, and device code phishing. If the tool cannot observe the session, it cannot meaningfully protect access.
• Test technique-based detection against live attacker behaviour Use realistic phishing kits and consent abuse scenarios rather than old URLs or known indicators. Validate whether the control can detect page structure, interaction patterns, and token abuse when infrastructure is freshly rotated.
• Tie browser telemetry into IAM and SaaS governance Route browser findings into identity workflows for access review, account takeover investigation, and risky SaaS suppression. The goal is to turn browser evidence into governance action, not leave it as isolated alert noise.
• Inventory AI tools and extensions visible only in the browser Track unsanctioned GenAI use, browser extensions, and OAuth integrations that never show up in endpoint or network tools. Prioritise the exposures that create the largest identity and data-loss blast radius.

Key takeaways

• Browser security now sits inside the identity attack path, which means platform bundling cannot be judged on procurement convenience alone.
• The important test is whether a browser control can see live session abuse, not whether it can block static malicious indicators.
• IAM teams should treat browser telemetry as governance evidence, because the browser is where identity trust, consent, and AI usage increasingly converge.

Key terms

• Browser-layer identity risk: Browser-layer identity risk is the exposure created when authentication, consent, and session trust are handled inside the browser rather than at the perimeter. It includes token theft, phishing that targets live sessions, risky extensions, and unsafe SaaS authorisations that traditional tools often cannot see.
• Session-level telemetry: Session-level telemetry is the record of what happens inside an authenticated browser session, including page loads, user actions, consent approvals, and token-related behaviour. It is valuable because it reveals identity abuse after login, when perimeter controls have often already been bypassed.
• Identity posture hardening: Identity posture hardening is the practice of reducing avoidable identity exposure before it is exploited. In browser security, that means detecting weak login patterns, missing MFA, over-permissive extensions, and unsanctioned integrations that expand the usable attack surface.
• Technique-based detection: Technique-based detection looks for the behaviour of an attack rather than a known malicious indicator such as a domain or IP address. It is more durable against fast-moving browser attacks because it focuses on how the session is abused, not where the attacker hosted the infrastructure.

Deepen your knowledge

Browser security as an identity control plane is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance model that has to account for browser-mediated access and AI usage, it is worth exploring.

This post draws on content published by Push Security: Why "good enough" isn't enough when it comes to browser security, and a best-of-breed approach is needed to tackle emerging threats. Read the original.