Push expands browser detections and file download telemetry

At a glance

What this is: Push Security’s update adds browser-level custom detections, file download telemetry, password-entry blocking, and longer event retention for faster triage.

Why it matters: These controls matter because browser activity is where modern identity misuse, secret exposure, and risky user behaviour increasingly surface across NHI, autonomous, and human programmes.

By the numbers:

• Push Security’s Events page now displays up to 30 days of data, instead of 7.

👉 Read Push Security’s update on browser detections, download telemetry, and password protection

Context

Browser controls increasingly sit on the identity edge, where sign-in behaviour, secrets exposure, and policy enforcement intersect. For IAM teams, the problem is not just authentication. It is whether the browser can surface enough context to detect risky actions before they become incidents, especially when identities are interacting with web apps, downloads, and non-standard execution paths.

This update is best read as a shift from passive observation to policy-enforced browser telemetry. Custom detections, file download events, and password-field protection all point to the same governance challenge: identity controls need visibility into what users and workloads do inside the session, not only who authenticated at the start.

Key questions

Q: How should security teams use browser detections to stop identity abuse?

A: Security teams should map browser detections to the specific actions that precede misuse, such as suspicious DOM interactions, unusual request patterns, or policy-violating page behaviour. The control works best when it is tied to identity workflows, not generic web activity. Pair the detections with clear Warn or Block outcomes and test them against known abuse cases.

Q: When do file download events become useful for investigation and response?

A: File download events become useful when teams need to connect browser activity to potential exfiltration, malware staging, or unsafe content transfer. Metadata such as file name, MIME type, URL, and unsafe status helps analysts decide whether the download was expected, risky, or part of a larger incident. In practice, they matter most when correlated with user and session context.

Q: What breaks when password entry is not blocked in non-password fields?

A: When password entry is not blocked in non-password fields, users can accidentally place secrets into application logs, support traces, or analytics fields that were never meant to hold credentials. That creates avoidable exposure, especially in high-value applications such as identity providers. The failure is not authentication itself, but secret leakage through everyday form behaviour.

Q: Who should own browser telemetry when the console keeps only 30 days of events?

A: Security operations should own the short-term triage workflow, while logging, detection engineering, and IAM teams should ensure the events are forwarded into SIEM or SOAR for longer retention and correlation. The console window is helpful, but it is not a substitute for durable evidence handling or audit-ready retention.

How it works in practice

Custom browser detections and page-level telemetry

Push’s custom detections extend browser inspection into the page DOM, web requests and responses, and HTTP headers such as cookies. That means detections can be built around specific content, request patterns, or response conditions rather than only coarse sign-in signals. The practical effect is a closer fit between security policy and real browser behaviour, including malicious campaigns, suspicious user actions, and policy violations. Because the rules are written in YAML and can trigger Warn or Block responses, the control is closer to an enforcement layer than a passive log source.

Practical implication: define detections around the browser events that actually precede abuse, not just around login outcomes.

File download telemetry and browser-constructed files

File download telemetry adds a stream of download events to SIEM or SOAR, including metadata such as file name, download URL, MIME type, and an unsafe flag. The notable detail is coverage of both network downloads and files constructed in the browser, such as blob or data URLs. That matters because browser-generated content can bypass assumptions built around traditional download paths. By exposing the download origin and type, the telemetry gives defenders a better starting point for triage and for correlating suspicious downloads with user and session context.

Practical implication: treat browser-constructed downloads as first-class telemetry in monitoring and investigation workflows.

Password entry protection and event retention

Preventing password entry into non-password fields is a targeted control for reducing accidental secret exposure in browser forms, especially where a password may be recorded in application logs if entered into the wrong input. Expanding the events window from 7 to 30 days changes operational triage, but it does not replace longer-term SIEM retention. The architectural pattern is clear: short-horizon browser evidence supports fast response, while centralised logging remains necessary for correlation and retention beyond the console’s built-in window.

Practical implication: use browser-side protections to reduce immediate leakage, then route events into central storage for longer investigations.

NHI Mgmt Group analysis

Browser telemetry is becoming a control plane, not just an observation layer. The practical meaning of this update is that identity teams can now attach policy to browser behaviour at the point where many risky actions occur. That is especially relevant for service accounts, human users, and emerging agent-driven workflows that operate through web interfaces. The broader governance shift is from post-event review to in-session enforcement, which is where modern misuse is most likely to surface.

Custom detections are most valuable when they reflect identity misuse patterns, not generic web security. The strongest use cases are IOC and TTP detection, red-team validation, and policy violations tied to specific application behaviour. That aligns browser control with NHI and IAM governance because the browser often becomes the execution surface for secrets handling, delegated access, and workflow abuse. Practitioners should treat this as a way to express identity policy in the session layer.

File download telemetry closes a common blind spot in identity investigations. Downloaded files often become the handoff point between authenticated access and downstream exfiltration or malware staging. Capturing unsafe status, MIME type, and browser-constructed downloads gives analysts better evidence than authentication logs alone. This is a reminder that identity telemetry must include what happens after access is granted, not just the access event itself.

Password-entry controls address a small action with large downstream risk. Mistyped passwords in non-password fields create avoidable exposure in application logs and support workflows. For IAM programmes, that is a hygiene issue with compliance implications because it turns a user error into a potential secret leakage path. The field-level control is narrow, but the governance lesson is broad: identity protections need to account for how humans actually interact with apps.

Events retention is useful, but only as part of a wider evidence pipeline. A 30-day console window improves triage, yet the vendor still recommends SIEM ingestion for longer retention and correlation. That reflects a familiar NHI and IAM pattern: local operational visibility is helpful, but durable governance depends on externalised logs, shared correlation, and investigation continuity. Practitioners should not mistake a longer console window for a complete evidence strategy.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why browser-side telemetry must be paired with identity inventory and investigation workflows.
• The NHI Lifecycle Management Guide helps teams connect browser evidence to provisioning, rotation, and offboarding decisions rather than treating telemetry as a stand-alone control.

What this signals

Browser-side enforcement is becoming the practical bridge between identity policy and user behaviour. Teams that already struggle to observe NHI activity will find the same issue appears in human and workflow sessions: the browser is where intent becomes action. Pairing session telemetry with the NIST Cybersecurity Framework 2.0 gives practitioners a better path from identify and detect to respond and recover.

The new control point is not just access, but what the authenticated session does next. That matters because many organisations still rely on logs and reviews that arrive after the fact. With Top 10 NHI Issues as a baseline, teams can sharpen their view of where secret leakage, risky downloads, and policy violations actually occur.

Browser telemetry will expose where governance is weakest, not just where attacks succeed. The value is less about alert volume and more about turning opaque user actions into evidence that can be correlated across IAM, NHI, and endpoint workflows. Session evidence gap: when controls stop at authentication, the browser becomes the place where governance either holds or fails.

For practitioners

• Build custom detections around identity abuse patterns Use browser telemetry to detect specific DOM elements, request patterns, headers, and responses that map to risky credential use, policy violations, or red-team test cases. Keep the rules close to the user actions that matter in your environment.
• Ingest file download events into your SIEM Route download metadata, unsafe flags, and browser-constructed file events into central logging so analysts can correlate downloads with session context, user identity, and downstream alerts.
• Block password entry into non-password fields Enable controls in core applications, especially identity provider sign-in flows, to prevent accidental secret leakage into logs and support channels when users paste or type credentials into the wrong field.
• Use the 30-day events window for fast triage only Treat the console retention increase as an operational convenience, then move events into longer-term storage for correlation, audit, and incident reconstruction.

Key takeaways

• Browser controls are moving deeper into the session layer, where identity misuse and secret exposure actually happen.
• File download telemetry, custom detections, and password-field protection extend visibility, but they still need central logging for durable governance.
• The operational priority is to turn browser events into actionable identity evidence, not to treat them as isolated product features.

Key terms

• Browser Telemetry: Browser telemetry is the capture of activity signals from within the web session, including requests, responses, downloads, and form interactions. In identity governance, it extends visibility beyond login so teams can see what users and workflows do after authentication, where many risky actions actually occur.
• Custom Detection: A custom detection is a rule written to identify a specific behaviour, pattern, or control violation that matters to one organisation. In browser security, it can target DOM activity, headers, or request flows so defenders can detect business-specific abuse instead of relying only on generic signatures.
• File Download Telemetry: File download telemetry is event data about files retrieved through the browser, including metadata such as file name, source URL, MIME type, and safety status. It helps security teams identify potentially malicious or risky downloads and connect them to the session, user, or workload that initiated them.
• Session Evidence: Session evidence is the record of actions taken inside an authenticated session after access has been granted. It matters because identity logs alone rarely show what was done, and many governance failures only become visible when the browser, application, and downstream security data are correlated.

Deepen your knowledge

Browser telemetry, secret exposure, and identity-session enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around browser-side identity activity, it is worth exploring.

This post draws on content published by Push Security: Custom detections, file download telemetry, and more. Read the original.