Why do device code flows create NHI risk even when the user authenticates in a browser?

Why the browser step is not the security boundary

The browser confirms the human, but it does not own the full transaction. In a device code flow, the terminal or CLI still starts the flow, polls for approval, receives the resulting token, and can keep that token alive in memory, history, logs, or stdout. The security question is therefore not just “did a person authenticate?”, but “which non-human process now holds usable access?”

This is why the same pattern can be safe in one tool and risky in another. The browser step proves consent or presence, but the CLI remains the credential-bearing actor after that point. If the terminal session is compromised, shared, recorded, or automated poorly, the attacker may inherit the token path even though the human login was legitimate.

Device code flow also blurs ownership. The user identity may be human, but the authorization artifact is issued into a non-human execution context that can outlive the browser session. That makes lifecycle, storage, and post-authentication handling part of the security model, not an implementation detail.

What actually creates the NHI exposure

The risk comes from the gap between human authentication and machine use. Once the token is issued, the CLI can act independently of the browser, which means the terminal becomes a governed access path with its own exposure profile. If the token is cached, copied, exported, or left in a long-running shell, the attack surface persists after the human step is complete.

That exposure is especially important where the CLI has broad API access, elevated scopes, or access to production systems. A valid token in a terminal session can be abused for exfiltration, command execution, or lateral movement just as effectively as any other stolen bearer credential. The browser approval does not neutralize those downstream effects.

In practice, the dangerous part is not the login screen, it is the post-login credential handling. A device code flow can be perfectly legitimate and still create NHI risk if the receiving process stores, reuses, prints, or forwards the token in ways the operator did not intend. Ultimate Guide to NHIs is a useful reference point for the broader lifecycle and governance issues that make these terminal-held credentials material.

How practitioners should assess and contain the risk

Device code flows should be treated as a delegated access pattern, not a simple “user login.” The critical control question is whether the CLI can be trusted to handle the token safely after issuance, especially when the token is short-lived, refresh-capable, or usable against high-value APIs. If the answer is no, the problem is not authentication failure, it is authorization sprawl into an unmanaged execution path.

That is why teams should look at the scopes granted, the token lifetime, where output is written, and whether the tool caches credentials on disk or in shell history. A workflow that is acceptable for a local developer machine may be too permissive for shared jump hosts, CI runners, support terminals, or admin workstations. NHI Authentication Guide helps frame the wider set of machine authentication patterns that are safer when the non-human side of the flow needs tighter control.

For teams designing or reviewing the flow, the right comparison is not “browser or no browser,” but “what happens to the token after the browser step?” When the post-authentication path is opaque, a browser-assisted login can still produce a persistent, reusable credential in a non-human context. Human vs Non-Human Identity is especially relevant here because the risk sits at the boundary where a person approves access but software receives and uses it.

Risk and Threat Considerations

Device code flows are attractive to attackers because they can separate approval from possession. If the terminal, script, or host is compromised, the attacker may only need the resulting token or refresh token, not the browser session itself. That creates a clean path from legitimate human approval to unauthorized non-human use.

Failure mechanism: the browser completes the human authentication step, but the CLI or terminal remains the bearer of the issued token and may persist it beyond the session. If that token is exposed through logs, process memory, shell history, screen capture, or local storage, the attacker can reuse it without reauthenticating the human.

Impact: stolen or reused tokens can enable API abuse, data access, privilege escalation, or lateral movement from a trusted workstation or automation host. The compromise may look like normal authenticated activity because the access token was legitimately issued, which makes detection and response harder.

Practitioner Guidance

What to verify: confirm where the token lands after browser approval, whether the CLI writes it to disk, and whether refresh capability is enabled by default. Treat any tool that exposes tokens in plaintext output, debug logs, or command history as a higher-risk implementation.

Decision rule: if the CLI runs in an environment you would not trust with a reusable bearer token, do not rely on the device code flow alone. Use tighter token lifetime, constrained scopes, stronger device controls, or an authentication pattern that keeps the credential handling inside a more governed runtime.

Common mistake: assuming that browser-based approval means the flow is “human-only.” In reality, the browser authenticates the person, but the terminal becomes the operational credential holder, so the real security test is whether that terminal path can be observed, bounded, and revoked cleanly.

Practitioner takeaway: device code flow risk is created by the post-browser credential path, so the security review should focus on token custody, scope, and persistence in the CLI environment, not just on whether the human login step was successful.

Related resources from NHI Mgmt Group

• Why do AI platforms create NHI risk even when user sessions are short?
• Why does insecure device posture create risk even when user credentials are valid?
• Why do SaaS integrations create NHI risk even when access is short lived?
• Why do APIs create identity risk even when the application code is secure?