What do security teams get wrong about telemetry when responding to in-browser attacks?

Why This Matters for Security Teams

In-browser attacks often look like routine user activity until the browser session, identity provider, and downstream app logs are stitched together. Security teams get into trouble when they treat telemetry as a single source of truth, because browser events alone rarely prove whether a click was malicious, whether a token was replayed, or whether an attacker pivoted into another service. That gap is why layered visibility is now a core control, not a nice-to-have.

NHIMG’s analysis of The 52 NHI Breaches Report shows how often weak visibility and poor logging slow detection across identity-driven incidents. The same pattern appears in browser-based compromise: the browser is just one sensor, while the real evidence is distributed across identity, endpoint, and cloud access layers. Current guidance from NIST Cybersecurity Framework 2.0 still points teams toward coordinated detection and response, but many operations teams under-collect the identity context needed to interpret browser telemetry correctly.

In practice, many security teams discover the missing context only after an account has already been abused and the initial phishing path has been lost.

How It Works in Practice

Effective response starts by correlating three views: browser telemetry, identity provider events, and resource access logs. Browser data can show tab changes, suspicious redirects, token storage behaviour, or unusual script execution, but it does not tell you whether a session token was accepted downstream. Identity logs show authentication, MFA prompts, conditional access decisions, and token issuance. Downstream logs show whether a session actually touched mail, storage, admin, or API endpoints.

That correlation is what separates a harmless link click from a successful compromise. For example, a user may click a phishing page, authenticate, and then never complete the attacker’s intended chain. Without identity and access logs, that can be misread as a breach. Likewise, a malicious session may appear benign in the browser while the real abuse happens through token replay or service-to-service access.

Security teams should also preserve timestamps carefully. Browser events are often high volume and local time can be misleading, so time normalization is essential before any investigation. This is where standards and threat-mapping resources help: MITRE ATT&CK Enterprise Matrix helps map observed behaviour to known intrusion patterns, while NHIMG’s Top 10 NHI Issues highlights how identity misuse and insufficient logging frequently combine in real incidents.

• Collect browser events, IdP logs, and downstream access records into one case timeline.
• Look for token issuance, MFA success, and session reuse rather than click activity alone.
• Differentiate user interaction from attacker automation by comparing sequence, source, and device context.
• Preserve raw logs before enrichment, because alert summaries often strip away the detail needed for attribution.

These controls tend to break down in high-churn SaaS environments where logging is fragmented across many vendors and session correlation keys are inconsistent.

Common Variations and Edge Cases

Tighter telemetry collection often increases storage, tuning, and privacy overhead, requiring organisations to balance forensic depth against operational friction. That tradeoff matters because in-browser attacks do not always leave clean signals, especially when attackers reuse legitimate sessions, exploit single sign-on, or move quickly across cloud apps.

One common edge case is “benign click, malicious follow-on.” The user may only open a page, but the browser later hands off to a token-based workflow that the attacker exploits elsewhere. Another is session theft without obvious password compromise, where the browser appears normal while the IdP shows unusual token issuance or impossible travel. There is no universal standard for how much browser telemetry should be retained for these cases, so current guidance suggests prioritising whichever logs best connect identity events to downstream activity.

NHIMG’s The State of Non-Human Identity Security shows how often organisations struggle with visibility and monitoring gaps, which is directly relevant when response depends on stitching together partial evidence. For emerging agentic or automated browser activity, the problem becomes harder because automation can generate human-like clicks while hiding the actual execution path. In those cases, the browser is only one clue, not the answer.

When telemetry is incomplete in federated SaaS, teams often over-attribute the incident to the browser and miss the identity layer that actually explains compromise.

Related resources from NHI Mgmt Group

• What do security teams get wrong about post auth phishing attacks?
• What do security teams get wrong about malicious copy and paste attacks that deliver infostealers?
• What do security teams get wrong about monitoring secret leakage in developer environments?
• What do security teams get wrong about MFA in identity attacks?