Device flow separates the browser session from the CLI session, so the user code can be reused across devices. That portability is useful, but it also enables phishing attacks where the victim approves a real IdP prompt for an attacker-controlled polling session. PKCE avoids that specific gap by keeping the code bound to the originating machine.
Why This Matters for Security Teams
Device flow is not inherently broken, but it shifts the trust boundary in a way that security teams must treat as higher risk than PKCE. The user authenticates in a browser while a separate CLI or device polls for the result, so the approval step is detached from the originating process. That separation creates a phishing path that is much easier to industrialise than a traditional code interception attack. It also means the identity event can be approved on a different screen, on a different device, and sometimes under different contextual cues than the session that will consume it.
For practitioners, the key issue is not just usability, but control of session intent. PKCE binds the authorization code to the originating client, which narrows the opportunity for reuse. Device flow is often justified for limited-input devices and CLI tooling, yet it increases the chance that a legitimate IdP approval is applied to an attacker-controlled polling session. That is why current guidance on OWASP NHI Top 10 and the NIST Cybersecurity Framework 2.0 both favour tighter binding, stronger verification, and clear ownership of the authentication event. In practice, many security teams discover this gap only after a user has approved a real prompt for the wrong session, rather than through intentional testing.
How It Works in Practice
Device flow works by splitting authentication into two parts: the user proves identity in a browser, while the device or CLI keeps polling until the authorization server returns tokens. That model is useful when the client cannot safely handle a browser-based login, but the same portability makes the user code and approval process easier to redirect. If an attacker can capture the code, trick a user into entering it, or race a victim to the approval page, the attacker may receive valid tokens for their own session.
PKCE reduces a different class of risk by binding the authorization response to the original client through a cryptographic verifier. It does not eliminate phishing in general, but it prevents the authorization code from being redeemed by a different client that did not start the flow. For teams comparing the two, the practical distinction is:
- PKCE keeps the authorization response tied to the originating machine.
- Device flow allows the human approval step to occur separately from the consuming session.
- Device flow is often better than embedding passwords in a CLI, but weaker than PKCE for client binding.
- Session intent is harder to validate when the approval and execution contexts are disconnected.
That is why practitioners should layer device flow with short-lived tokens, phishing-resistant MFA where available, and explicit user prompts that identify the client, tenant, and requested scope. These expectations align with the identity and zero-trust emphasis in the Ultimate Guide to NHIs — Key Challenges and Risks and the NIST Cybersecurity Framework 2.0, both of which stress reducing implicit trust and validating access at the point of use. These controls tend to break down in high-volume developer environments because users normalize approval prompts and stop verifying which session is actually waiting for tokens.
Common Variations and Edge Cases
Tighter authentication control often increases friction, requiring organisations to balance user convenience against phishing resistance. That tradeoff is especially visible in CLI tooling, shared workstations, and legacy devices that cannot run a browser reliably. In those environments, device flow may still be the least-bad option, but best practice is evolving rather than settled, and there is no universal standard for how much user confirmation is enough.
A useful operational rule is to reserve device flow for true constrained-device scenarios, not as a default login pattern for modern applications. Where the client can support a browser redirect, PKCE is usually the safer choice because it preserves client binding. Where device flow is unavoidable, teams should shorten token lifetimes, limit scopes aggressively, and add approval messaging that is specific enough for the user to spot a malicious prompt. The broader NHI risk picture in the Ultimate Guide to NHIs — Why NHI Security Matters Now reinforces this point: once identities and secrets become easy to reuse across contexts, compromise becomes much easier to scale. For governance, that maps cleanly to NIST Cybersecurity Framework 2.0 principles for least privilege and continuous verification. The pattern breaks down when approval prompts are generic and users cannot tell which application, tenant, or scope they are actually authorising.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Device flow increases auth-code and token abuse risk through weak client binding. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control are central to stopping approval-session abuse. |
| NIST AI RMF | Risk management applies to authentication flows with phishing-prone human approval steps. |
Assess authentication workflows for misuse paths and document compensating controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
