By NHI Mgmt Group Editorial TeamBased on Push Security: “The CISO's data problem (and how browser telemetry can help)” (May 11, 2026)

TL;DR: Browser-based identity attacks now account for major enterprise entry points, and Push Security says browser telemetry exposes more of the attack surface needed for quantitative risk modelling than network or endpoint data alone. That shift makes risk estimates more defensible, but it also reveals shadow AI, OAuth sprawl, extension abuse, and ghost logins that many programmes still do not measure.


At a glance

What this is: This is an analysis of how browser telemetry improves quantitative identity risk modelling by making identity attack paths and control gaps directly observable.

Why it matters: IAM, IGA, PAM and security teams need this because identity risk cannot be defended with benchmarks alone when browser activity exposes real-world attack frequency and control failure.


Context

Browser telemetry is high-fidelity data collected from user browser activity, including authentication flows, login behaviour, OAuth grants, extension use and SaaS access patterns. In identity programmes, that matters because many attacks now happen in the browser rather than through traditional network or endpoint paths.

The core governance problem is measurement. Many teams still estimate credential compromise and account takeover risk from incomplete telemetry, then present those estimates as if they were quantitative. Browser visibility changes that by showing how often identity attacks occur and how often controls fail in the environments users actually use.


Key questions

Q: How should teams measure identity risk when browser telemetry is available?

A: Teams should measure identity risk from observed attack frequency and observed control failure, not from generic benchmarks or risk matrix scores. Browser telemetry gives evidence for how often attacks reach users, how often users authorise risky actions, and where session-level controls actually fail in production.

Q: Why do IdP-only metrics understate account takeover risk?

A: IdP-only metrics miss browser-mediated behaviour such as direct SaaS logins, OAuth consent abuse, device code phishing and extension-driven access. That leaves a gap between policy coverage at the identity provider and the real session path an attacker can use to get valid access.

Q: Why does browser-based identity telemetry create better risk signals than relying only on IdP and endpoint logs?

A: Browser telemetry captures activity at the point where users authenticate, reuse passwords, encounter phishing tools, and access SaaS apps. That matters because identity attacks often happen inside the browser, where traditional logs can miss context. When teams combine browser signals with IdP and endpoint data, they can spot compromised sessions, suspicious app use, and high-risk changes faster.

Q: How should security teams use browser telemetry in identity risk management?

A: Security teams should use browser telemetry as an identity signal source, not as standalone activity logging. The goal is to connect events like logins, downloads, profile changes, and session starts to an account’s privileges and downstream access. That makes browser data useful for spotting compromised credentials, shadow IT, and identity blast radius early.


Technical breakdown

Why browser telemetry changes identity risk measurement

Browser telemetry captures the identity transaction where many modern attacks actually happen. Credential phishing, device code phishing, ClickFix, session hijacking and OAuth abuse all leave observable traces in login flows, token grants and browser extensions. That matters because quantitative models such as FAIR depend on realistic inputs for threat event frequency and vulnerability. If the telemetry excludes browser-born activity, the model undercounts both attack frequency and control failure, which makes loss estimates look more precise than they are.

Practical implication: build risk models from observed browser activity, not from email-only or IdP-only proxies.

Ghost logins and the limits of central IdP visibility

Ghost logins are downstream authentication events that occur outside the main IdP visibility layer, often through direct SaaS access or reused credentials. They are especially dangerous because MFA coverage and SSO adoption at the central platform can look stronger than the actual estate. In practice, that means the control you think you are measuring is not the control the attacker is bypassing. Browser telemetry can surface these hidden logins because it sees the session as the user experiences it, not just as the IdP records it.

Practical implication: reconcile browser-level login data with IdP reports before treating MFA or SSO coverage as meaningful risk evidence.

Shadow AI, OAuth sprawl and extension abuse as measurable exposure

The article shows that browser telemetry also exposes SaaS and extension-driven exposure that conventional risk models miss. Unapproved AI app integrations, stored OAuth tokens and extensions with takeover-capable permissions all create identity risk without looking like classic malware or perimeter compromise. The technical issue is not simply that these tools exist, but that their lifecycle, permissions and ownership can change without visibility. That turns browser telemetry into an inventory and behaviour signal, not just a detection feed.

Practical implication: inventory browser-mediated access paths and tie them to authorization, ownership and change monitoring.


Threat narrative

Attacker objective: The attacker aims to obtain valid browser-mediated identity access that can be turned into SaaS compromise, token abuse and downstream data or credential exposure.

  1. Entry occurs through browser-delivered credential phishing, device code phishing, ClickFix or OAuth consent abuse rather than through a conventional network breach path.
  2. Privilege or session access is gained when the victim authorises a malicious app, enters credentials, or pastes and runs attacker-supplied commands in the browser context.
  3. Impact follows when attackers reuse tokens, hijack sessions or reach SaaS dashboards, internal data and keys through downstream browser-mediated access.
  • Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
  • CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

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 telemetry is now a governance input, not just a detection source: identity risk models built on benchmarks and analyst estimates are weaker than models built on observed user behaviour. Browser data shows when attacks actually reach users, how often they succeed, and where controls fail in practice. That makes quantitative identity risk more defensible to finance and board stakeholders, and it should become part of the core identity evidence set.

Identity attack measurement has shifted from the IdP to the browser: many identity attacks now succeed after the authentication step, which means central IAM reporting no longer captures the full control boundary. Password strength, MFA adoption and SSO coverage still matter, but they no longer describe the whole risk surface. Practitioners should treat browser-layer evidence as the missing layer between identity policy and user reality.

Shadow AI and OAuth sprawl create identity exposure that traditional risk models systematically omit: browser-mediated app consent and self-provisioned integrations can create standing downstream access without formal approval. That is not a niche issue, it is a control blind spot. The implication is that identity governance must account for browser-observed authorisation behaviour, not just recorded system-of-record entitlements.

Telemetry quality is now the bottleneck in quantitative identity risk: the frameworks for risk modelling exist, but the inputs are often too coarse to defend. Browser telemetry improves the quality of threat event frequency and vulnerability estimates because it captures the actual session path. For practitioners, the decisive question is whether the programme can observe the identity attack surface where it now lives.

Identity blast radius is becoming measurable before it becomes containable: the value of browser telemetry is not only that it finds attacks, but that it exposes which identities, apps and extensions create the largest exposure window. That shifts the conversation from generic account compromise to measurable identity blast radius. Teams should use that visibility to prioritise controls where observable misuse is already happening.

What this signals

Browser-level identity measurement is becoming a programme design issue, not a tooling preference: if your control set only sees IdP events, it will keep undercounting the attack surface that actually drives account takeover and SaaS compromise. The practical shift is toward session evidence, consent behaviour and browser-mediated access paths as first-class governance inputs.

Identity risk programmes need a sharper boundary between recorded access and observed access: recorded access shows what the system of record thinks happened, while observed access shows what users and attackers did in the browser. That distinction matters for auditors, CISOs and risk committees because it changes both the confidence in the model and the prioritisation of controls.


For practitioners

  • Instrument browser-layer identity telemetry Capture authentication flows, OAuth grants, SaaS access patterns and extension activity so your risk model reflects what users actually do in the browser.
  • Rebuild identity risk inputs from observed behaviour Use observed attack frequency and observed control failure rates instead of relying on benchmarks, whiteboard estimates or broad risk matrices.
  • Reconcile IdP reports with ghost login evidence Compare browser-level login telemetry with central IdP data to identify access paths that bypass your normal authentication visibility.
  • Inventory OAuth and AI app consent paths Track unapproved integrations, stored tokens and self-provisioned app grants as part of the identity attack surface, not as isolated SaaS exceptions.
  • Monitor browser extensions for permission drift Watch for ownership changes, privilege escalation and anomalous behaviour in extensions that can support account takeover without user interaction.

Key takeaways

  • Browser telemetry exposes identity attacks at the point where they execute, which makes quantitative risk modelling more defensible than models built on indirect proxies.
  • The biggest blind spots are browser-mediated identity behaviours such as ghost logins, OAuth sprawl, unapproved AI app connections and extension abuse.
  • Teams that rely on IdP-only reporting will continue to undercount account takeover risk until browser-layer evidence becomes part of the risk model.

Key terms

  • Browser telemetry: Browser telemetry is the event data produced by enterprise browser activity, including logins, profile changes, downloads, session starts, and extension or site interactions. In identity governance, it becomes useful when those events are correlated with account state and privilege context rather than treated as generic activity logs.
  • Ghost Login: A ghost login is a direct authentication path that remains active after an organisation believes it has moved to central single sign-on. It creates a parallel trust model that can still accept passwords, so the identity team sees one policy posture while attackers exploit another.
  • Threat Event Frequency: Threat Event Frequency is the rate at which a threat acts against an asset over a given period. In browser-based identity risk, it should be grounded in observed attack attempts and authorisations rather than broad industry estimates, because the browser often contains the most accurate evidence of attack contact.
  • Browser-mediated access: Browser-mediated access is access that is exercised through the browser rather than through a tightly controlled native client or backend workflow. It matters because many modern identity and data control failures occur after sign-in, during the live session where users interact with SaaS and AI tools.

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