How should security teams detect compromised logins when browser telemetry is available only on managed devices?

Security teams should correlate identity provider sign-ins with browser telemetry from managed devices, then treat missing telemetry as suspicious only when the device and login pattern should normally produce it. This approach reduces false positives from hybrid work while still surfacing likely credential compromise. The strongest detections come from combining identity events, endpoint signals, and a clear expectation of what legitimate access looks like.

When browser telemetry exists only on managed devices, the detection problem is not simply whether a login happened, but whether the observed access path matches the expected device state. That matters because identity logs alone rarely tell security teams whether a session came from a corporate browser, a borrowed device, or a stolen credential being replayed from somewhere else. The control challenge is to treat telemetry absence as meaningful only inside a known baseline.

That baseline approach is especially important in hybrid work, where legitimate access often shifts across devices and networks. The strongest signal is the mismatch between a successful sign-in and the browser or endpoint evidence that should normally accompany it. NHI Management Group research on non-human identity operations shows how often teams overestimate their visibility into identity-linked activity, which is a useful warning here: monitoring confidence is usually higher than actual observability.

In practice, many security teams discover that “missing browser telemetry” is not a detection rule but a timing and coverage problem that becomes visible only after an account has already been abused.

The State of Non-Human Identity Security

How Correlation Works When Only Managed Devices Emit Browser Data

The practical method is to correlate identity provider events with endpoint and browser signals from the managed fleet, then interpret gaps against a device-specific expectation model. A managed laptop that routinely emits browser telemetry should be treated differently from a phone, a kiosk, or an unmanaged home system where that signal may never exist. The point is not to require browser telemetry for every login, but to know when its absence is unusual for that user, device class, and access pattern.

Useful inputs usually include sign-in time, geolocation or ASN, device compliance state, user agent, browser session markers, and whether the login led to privileged or sensitive application access. When these are combined, teams can distinguish three broad cases: expected managed-device activity, plausible but lower-confidence access, and suspicious logins where identity evidence and endpoint evidence do not line up. A common refinement is to require stronger corroboration when the account is privileged or when the login is followed by token issuance, email access, or configuration changes.

Use managed-device telemetry as a confidence booster, not the only proof of legitimacy.
Define which device classes should normally produce browser signals and which should not.
Escalate when the identity event is successful but the managed endpoint never shows a corresponding browser session.
Weight post-login actions heavily, because abuse often becomes clearer after the first successful authentication.

The absence of browser telemetry is most useful when the organisation already has stable device inventory, consistent endpoint coverage, and well-defined expectations for how each access path should behave.

NIST Cybersecurity Framework 2.0

Common Variations, False Positives, and Edge Cases

Tighter correlation between identity events and browser telemetry often increases investigation overhead, so teams need to balance sensitivity against the reality of browser privacy settings, app-based sign-ins, and mixed device populations. A successful login without browser telemetry is not automatically suspicious if the user authenticated through a native app, a legacy protocol, or an unmanaged endpoint that cannot emit the same signals.

Best practice is evolving toward device-aware expectations rather than a single universal rule. For example, managed Windows or macOS devices may produce rich browser telemetry, while mobile access, VDI, or hardened browser configurations can suppress it. Cross-tenant administrators and service desks also create edge cases because their legitimate access patterns are often broader than ordinary users. The right question is whether the missing signal is anomalous for that identity, device class, and business function.

Teams also need to distinguish telemetry loss from telemetry suppression. The former may indicate an endpoint issue, while the latter can be a sign that an attacker is using a path that avoids the managed browser stack altogether. In that sense, the detector is only as good as the organisation’s understanding of which access paths should be observable in the first place.

Risk and Threat Considerations

Compromised login detection becomes weaker when defenders assume browser telemetry should exist everywhere, or when they treat its absence as suspicious without knowing the expected access path. The material risk is twofold: false positives can desensitise analysts, while true credential abuse can slip through when attackers use unmanaged devices, native clients, or sessions that never generate the managed-browser signal.

Failure mechanism: Attackers who obtain valid credentials can authenticate successfully from a device or client that does not produce managed browser telemetry, or they can use a legitimate managed device after privilege abuse to blend into expected identity logs. If teams do not model which sign-ins should produce endpoint evidence, they may either miss the compromise or burn time investigating normal hybrid-work behaviour.

Impact: The organisation can lose early warning on session takeover, token abuse, and follow-on access to sensitive applications. In the worst case, the compromise is only detected after downstream actions such as mailbox access, data export, or privilege escalation have already occurred.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-1 — Monitoring for Anomalies and Events	Correlating sign-ins with endpoint telemetry is anomaly monitoring for identity abuse.
	DE.AE-1 — Anomalies and Events	Missing expected telemetry is an anomaly only when the access path should emit it.
Recommendation — Correlate identity and endpoint signals to detect sign-ins that diverge from normal access patterns. Define expected telemetry for each device class and alert when a login departs from it.
CIS Controls v8	8.5 — Account Monitoring and Control	Compromised logins are exposed through account activity correlation and unusual sign-in paths.
	6.3 — Access Control Management	Managed-device expectations depend on knowing which accounts and devices should access which apps.
Recommendation — Monitor account activity for impossible, atypical, or uncorroborated authentication events. Restrict access paths so only expected managed devices can reach sensitive services.
NIST Zero Trust (SP 800-207)	3.3 — Device Security Posture	Browser telemetry from managed devices depends on trusted device posture and observability.
Recommendation — Base access decisions on device posture and trust signals rather than login success alone.

Practitioner Guidance

What to prioritise: Build the detector around expected telemetry presence by device class, not around a blanket assumption that every successful login should emit browser evidence. The most useful investigations start with managed devices that should normally be observable and then work outward to exceptions.

What to verify: Confirm that the same identity event can be matched to a managed endpoint record, a plausible browser session, and a device posture state before suppressing the alert. If any one of those is missing, decide whether that absence is explainable by the access path or whether it represents an exposure worth escalating.

Decision rule: Treat missing browser telemetry as high-signal only when the user, device, and application path normally produce it. If the access path is ambiguous, shift to a lower-confidence investigative queue rather than forcing a binary verdict.

Practitioner takeaway: The goal is not to prove that every login is good, but to make “good enough” observable for the access paths that should already leave a trail.