Notifications
Clear all
Topic starter
09/06/2026 11:55 pm
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.
NHIMG editorial — based on content published by Push Security: Browser telemetry is changing how teams quantify identity risk
By the numbers:
- 1 in 3 phishing payloads intercepted by Push are delivered outside of email.
- 4 in 5 ClickFix payloads intercepted by Push arrive via search engines, not email.
- 17 unique AI app integrations per organization in Microsoft and Google alone.
Questions worth separating out
Q: How should security teams use browser telemetry in identity risk modelling?
A: Use browser telemetry to measure real attacker exposure instead of relying only on inherited benchmarks.
Q: Why do MFA and SSO not fully cover browser-based identity attacks?
A: MFA and SSO reduce risk at authentication, but many attacks succeed after authentication has already occurred.
Q: How do organisations know if shadow AI is becoming a governance problem?
A: Shadow AI becomes a governance problem when users self-provision AI SaaS apps that retain tokenised access to company data without approval or review.
Practitioner guidance
- Instrument browser-layer identity telemetry Collect login, OAuth, extension, and session events so identity risk models are based on observed behaviour rather than boardroom estimates.
- Inventory shadow AI and delegated apps Build a discovered list of unapproved AI SaaS connections, with token scope, owner, and business justification, then compare it to approved app policy.
- Measure post-login control gaps Track the share of logins that are password-only, lack MFA, or occur outside central IdP visibility to understand where authentication assumptions break down.
What's in the full article
Push Security's full research covers the operational detail this post intentionally leaves for the source:
- The browser telemetry methodology used to estimate threat event frequency and vulnerability from observed identity behaviour
- The specific login, OAuth, and extension signals used to identify ghost logins and shadow AI exposure
- The detailed breakdown of browser-based delivery channels such as search, social media, and messaging lures
- The product-level control and detection examples for teams that want to operationalise these signals
👉 Read Push Security's analysis of browser telemetry and identity risk quantification →
Browser telemetry and identity risk: what IAM teams need to know?
Explore further
10/06/2026 2:28 am
Browser telemetry creates a different category of risk evidence: Identity risk has usually been measured with inferred probabilities, not directly observed attacker behaviour. When the browser becomes the execution environment, frequency, control weakness, and user interaction are all visible in-session. That makes browser telemetry one of the few places where quantitative security teams can replace broad assumption with environment-specific evidence.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: What should teams do when browser telemetry shows frequent non-email phishing?
A: They should expand threat models beyond email and align detection with the channels attackers actually use. Search ads, messaging apps, social platforms, and clipboard-based lures can all drive identity compromise, so email-only controls understate exposure and misdirect investment.
👉 Read our full editorial: Browser telemetry is changing how teams quantify identity risk
