How do you detect Primary Refresh Token access attempts on Microsoft Entra joined devices?

What Primary Refresh Token activity looks like on a joined device

primary refresh token access on microsoft entra joined device is most useful to think about as a device-backed sign-in and token-use pattern, not just a single event. Detection works best when you compare Entra sign-in records, device posture, and local endpoint behaviour to establish whether the token use is consistent with the device, user, and session that should have produced it. That is why anomalies in browser, shell, and process activity matter as much as cloud sign-in telemetry.

A joined device should normally show a stable relationship between the user, the device, and the services that receive authentication from that device. When that relationship changes sharply, such as a device suddenly authenticating to many services, or sign-in geography and timing no longer matching the user’s normal pattern, the event becomes more suspicious. A practical control baseline is to pair token telemetry with device trust and posture signals, because posture drift often appears before the access pattern becomes obvious.

It also helps to distinguish ordinary token refresh from access that suggests token theft, session abuse, or delegated use from a compromised endpoint. The strongest detections usually combine identity-plane evidence with endpoint evidence, such as suspicious process access, credential dumping, or abnormal browser session reuse. For the token lifecycle itself, the Token and Session Security Guide is the most relevant internal reference because the detection problem is ultimately about misuse of bearer material and session continuity, not just sign-in volume.

Where the detection signal becomes meaningful

The signal is strongest when token use diverges from the device’s expected trust state. For example, a device that is Entra joined but suddenly starts issuing access to many cloud services in a short window deserves attention, especially if the activity coincides with unusual shell activity, browser token access, or processes that commonly support credential harvesting. A joined device that begins to behave like a proxy for broader cloud access is often more important than one noisy failed sign-in.

Microsoft Entra sign-in logs are useful, but they rarely tell the whole story by themselves. You need correlation logic that joins cloud identity telemetry with endpoint telemetry and then scores the combination of user, device, time, location, and process behaviour. If the access pattern suggests consented authentication but the endpoint shows token extraction or session abuse, the problem is no longer simply “unexpected login”, it is likely compromise or replay. The Conditional Access Guide is relevant here because the policy signals that reduce access uncertainty also improve the quality of the detection surface.

Joined-device access is also easier to interpret when posture and identity governance are aligned. If a device is marked compliant but shows signs of local abuse, that mismatch is often more valuable than the raw sign-in event. When the same user or device begins touching many services outside its normal application set, it can indicate token replay, session hijacking, or a compromised endpoint acting as an access pivot.

How to investigate and confirm abuse

Start by validating whether the access pattern matches the user’s established behaviour, then inspect the local endpoint for evidence that would explain abnormal token use. That means looking for browser session tampering, suspicious child processes, memory access patterns associated with credential theft, and any tool activity that would let an attacker reuse an existing authentication context. If the token is being used from a joined device but the local machine shows signs of tampering, treat the device as the primary containment target.

The best investigation path is to build a narrow timeline: sign-in event, token issuance or refresh, endpoint process activity, and any downstream service access that followed. That helps separate a benign roaming session from a session that was harvested and replayed. If the same device is also failing expected posture checks or appears outside its normal location pattern, the probability of abusive token use rises sharply. For the broader access model behind this kind of event, RFC 6749: The OAuth 2.0 Authorization Framework remains the key external reference for understanding why bearer-style access must be treated as reusable authority once exposed.

When the local evidence points to reuse rather than ordinary authentication, contain first and investigate second. Preserve endpoint telemetry, Entra sign-in logs, and any browser or shell artefacts that can show how the token was accessed. If the device has been used to reach multiple services unusually fast, review whether those services share the same trust path, because a single stolen session can widen access quickly.

Risk and Threat Considerations

Primary Refresh Token abuse matters because it can turn a single joined device into a high-trust access pivot. Once an attacker can reuse the device’s authentication context, they may not need password theft or repeated interactive logins, which makes the activity harder to spot and faster to scale across services.

Failure mechanism: A compromised endpoint, browser session, or local process extracts or reuses token material, then uses that existing trust relationship to authenticate as the user from the joined device.

Impact: The attacker can expand access across SaaS and cloud services, blend into legitimate sign-in noise, and persist until the token, session, or device trust path is revoked.

Practitioner Guidance

What to prioritise: Treat correlation quality as the main detection problem. If your sign-in analytics and endpoint telemetry are not joined, you will see either too many false positives or too few high-confidence alerts, especially for roaming users and heavily used joined devices.

What to verify: Confirm that the device, user, location, and service set form a coherent story. A joined device that authenticates to many services suddenly, or that combines normal-looking cloud access with suspicious local process behaviour, is the strongest candidate for escalation.

Decision rule: If the evidence suggests token reuse or local extraction, isolate the endpoint and invalidate the session path before waiting for additional cloud indicators. If the activity is only anomalous but not yet corroborated, monitor closely and tighten policy rather than assuming compromise.

Practitioner takeaway: The most reliable detections do not look for “a token event” in isolation, they look for a broken relationship between the user, the joined device, and the endpoint evidence that should have produced the access.

Related resources from NHI Mgmt Group

• How do you manage local administrators on Microsoft Entra joined devices?
• How do you require compliant devices with Conditional Access in Microsoft Entra ID?
• How do you configure access token lifetimes in Microsoft Entra ID?
• How do you detect Conditional Access policy changes by unapproved actors in Microsoft Entra ID?