Why do unmanaged devices increase the risk of token theft?

Why This Matters for Security Teams

Unmanaged devices turn token theft from a credential problem into an endpoint trust problem. When a browser session, refresh token, or OAuth grant is created on a personal laptop or non-corporate tablet, the organisation is relying on controls it does not fully own. That is why session artefacts on unmanaged endpoints are so valuable to attackers: they bypass password strength, MFA prompts, and many help desk reset workflows.

This risk shows up quickly in cloud access, SaaS administration, and remote support paths where a stolen token can be replayed without the original device present. The pattern is visible in incidents such as the Salesloft OAuth token breach, where token misuse became an entry point into downstream systems. NIST’s Cybersecurity Framework 2.0 treats access governance and asset control as connected disciplines, which is exactly the point here: if the endpoint is not controlled, the session is not fully trusted.

NHIMG research on Top 10 NHI Issues consistently shows that token exposure and lifecycle failures are rarely isolated events; they compound when identities are active beyond their intended trust boundary. In practice, many security teams encounter token abuse only after cloud logs show impossible travel, anomalous API calls, or privilege use from a device they never enrolled.

How It Works in Practice

Token theft on unmanaged devices usually starts with one of three paths: malicious browser extensions, infostealer malware, or local session extraction from caches and profile stores. Once a token is copied, the attacker often does not need the password. If the application accepts the token as proof of identity, the session can be replayed from another device until the token expires or is revoked.

That is why good practice is shifting toward device-aware controls, short-lived sessions, and stronger binding between the token and the endpoint. Current guidance suggests combining identity checks with posture checks, especially for privileged access and admin consoles. For implementation detail, teams often align to the device security guidance from national cyber authorities and use browser hardening, managed profiles, and conditional access policies to reduce replay risk.

• Prefer phishing-resistant MFA, but do not assume MFA alone protects a stolen session token.
• Use short TTLs for access and refresh tokens where the application can tolerate it.
• Restrict admin access to managed devices or verified device posture when risk is high.
• Continuously monitor for token reuse, impossible travel, and session anomalies.
• Revoke sessions automatically when device compliance changes or account risk increases.

NHIMG’s Guide to the Secret Sprawl Challenge is relevant because token theft is often accelerated by overexposed secrets and poor lifecycle hygiene. For organisations managing many cloud apps, the real control is not just issuing tokens, but limiting where they can be stolen, replayed, and reused. These controls tend to break down in bring-your-own-device environments where the organisation cannot enforce uniform endpoint telemetry, browser policy, or local malware protection.

Common Variations and Edge Cases

Tighter endpoint controls often increase user friction and support overhead, so organisations must balance usability against the blast radius of session theft. That tradeoff becomes more visible in hybrid work, contractor access, and executive travel scenarios where unmanaged devices are sometimes unavoidable.

There is no universal standard for this yet, but best practice is evolving toward risk-based access rather than a blanket trust or deny posture. For low-risk apps, a token on an unmanaged device may be acceptable if TTLs are short and privileges are minimal. For high-risk systems such as finance, identity administration, or production cloud consoles, unmanaged access should be treated as a material exception, not a default.

One useful reference point is the NHI Lifecycle Management Guide, which emphasises that identity risk changes over time and must be reduced at issuance, during use, and at revocation. The same logic applies to user sessions on personal endpoints: if the device cannot be trusted, the token must carry more constraints and less lifetime. A second practical implication is that token theft is harder to prevent than to contain, so response plans should assume replay is possible and prioritize rapid revocation, device quarantine, and session review.

Where this guidance breaks down most often is in legacy SaaS applications that cannot bind tokens to device posture or support fine-grained revocation, because stolen sessions remain valid even after the endpoint is isolated.

Related resources from NHI Mgmt Group

• Why does remote work increase identity risk even when the company has VPNs?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?