Not necessarily, but they should restrict it wherever the business does not genuinely need it. Device authorization is useful for constrained devices, yet it becomes a phishing path when broadly available in standard workforce environments. The practical decision is to reduce exposure to the flows that users are least able to validate safely.
When device authorization flow should be allowed, and when it should not
Device authorization flow is designed for input-constrained or browser-poor environments, such as TVs, kiosks, terminals, and some command-line tools. In those settings, the user can complete sign-in on a separate device, which makes the flow practical rather than insecure by default. The control question is not whether the flow exists, but whether the application context actually needs that UX trade-off.
In a normal workforce application, broad availability usually creates more exposure than value. If users already have a browser, keyboard, and managed endpoint, a stronger interactive flow is usually available, and the device flow becomes one more way to request trust from users who cannot easily inspect what they are approving.
A useful policy split is to treat the flow as an exception for constrained scenarios, not a default authentication option. That keeps the control tied to the business case and avoids normalising a pattern that is easy for users to complete and hard for them to validate safely.
Why broad device code availability increases abuse potential
Device authorization is attractive to attackers because it can move the approval step to a separate channel and rely on user behaviour rather than direct compromise. When the flow is available everywhere, phishers can present a legitimate-looking device prompt, then socially engineer the victim into entering the code on a real login page.
The problem is not only phishing in the classic sense. A widely exposed device flow also expands the number of applications that can be used as an entry point for token issuance, especially when users are trained to comply quickly with pairing or activation prompts. That makes the flow a trust boundary that deserves tighter governance than a standard sign-in button.
For identity teams, the right mental model is that device authorization is a controlled exception path, not a universal convenience feature. The more an application serves general office users, the less defensible it is to leave this flow open without a clear device or client constraint.
When you need deeper context on how authorisation choices should be scoped, the Authorisation Models Guide helps frame how policy should follow use case rather than default availability. For workforce access design more generally, IAM and IGA Basics is a useful companion because it connects access decisions to governance and least privilege.
How to decide whether to block it by default
The practical decision is to ask whether the application truly runs on constrained devices or in environments where an alternative flow is not realistic. If not, blocking device authorization is usually the safer default. If yes, allow it narrowly and document why the normal interactive path is insufficient.
For most organisations, the deciding factors are application audience, device class, and user ability to validate the login request. If the user base is standard staff on managed laptops or desktops, device authorization rarely adds enough value to justify the extra attack surface. If the app targets TVs, shared terminals, thin clients, or command-line usage, the case for allowing it is much stronger.
Operationally, this is also a policy enforcement question. A secure rollout should define which clients may use the flow, which users may see it, and whether the app is allowed to present pairing or code entry prompts at all. That prevents the control from becoming an accidental fallback for every new integration.
The OAuth flow itself is documented in RFC 6749: The OAuth 2.0 Authorization Framework, while the current implementation guidance in OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful for understanding how grant types, client classes, and token handling should shape the decision. For app-security verification, OWASP ASVS provides a broader control lens for authentication and access design.
Practical governance for a safer exception model
The strongest governance pattern is to approve device authorization only for explicit use cases and review it as part of application onboarding. If a team cannot clearly explain why the flow is needed, it should not be enabled. That makes the decision auditable and stops convenience from outranking risk.
What to verify: confirm that the application genuinely serves a constrained-device scenario, that the client type is appropriate, and that the sign-in experience does not encourage users to approve prompts they cannot inspect carefully. If the business use case is ordinary workforce access, verify whether a standard browser-based flow can replace it.
Decision rule: allow the flow only when the device constraint is real and documented; otherwise block it by policy and remove it from the application’s supported sign-in paths. Where the flow remains necessary, pair it with tighter client registration, audience restriction, and user guidance so it is not treated as a general-purpose login option.
Practitioner takeaway: device authorization flow is a useful niche capability, but in standard employee environments it should be treated as a controlled exception because the user experience that makes it convenient also makes it easier to abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Controls workforce sign-in paths for standard employee applications. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Applies when external or constrained users need a distinct login path. | |
| Recommendation — Restrict device flow by enforcing approved authentication methods for organizational users. Allow device flow only for user populations that genuinely need the exception. | ||
| OWASP ASVS | V6 — Authentication | Device authorization is an authentication choice with phishing and validation implications. |
| V10 — OAuth and OIDC | Device authorization is an OAuth grant type and should be governed through OAuth design. | |
| Recommendation — Verify that authentication flows are appropriate for the application’s user context. Review OAuth grant selection and disable flows that are unnecessary for the app. | ||
| CIS Controls v8 | CIS-5 — Account Management | Restricting login pathways is part of managing which access paths are permitted. |
| Recommendation — Limit account access methods to those required by the business use case. | ||
Related resources from NHI Mgmt Group
- How can organisations decide whether device flow is appropriate for a CLI application?
- When should organisations block device code flow entirely?
- Should organisations block merges for every non cryptographically secure random use in application code?
- Should organisations require device posture checks for every login?