Why do device-code approvals create risk when the requester is untrusted?

Why This Matters for Security Teams

Device-code approval feels user-friendly because it removes password entry, but that convenience changes the trust model. The requester does not need to prove it is legitimate at the moment of approval, so a malicious app can place the burden on the human to validate something they cannot inspect. That is why device-code abuse often becomes consent laundering rather than credential theft, and why logs can show a seemingly valid user action even when the original requester was hostile.

Security teams should treat this as an authorisation problem, not a login problem. A device-code grant can produce tokens with real mailbox, graph, or SaaS reach, which means the blast radius depends on the scopes approved and the downstream APIs available. NHI governance becomes relevant here because the issued token behaves like a non-human identity with delegated authority. The operational risk is amplified when approvals happen under time pressure, on unmanaged endpoints, or during helpdesk-assisted workflows. Current guidance from Ultimate Guide to NHIs — Why NHI Security Matters Now and the NIST Cybersecurity Framework 2.0 both point toward tighter identity assurance and continuous access control, not blind reliance on a user click. In practice, many security teams discover the abuse only after a token has already been used to enumerate mailboxes or extract data, rather than during the approval itself.

How It Works in Practice

In a normal device-code flow, the requester generates a code, the user enters it on a trusted login page, and the identity provider issues tokens after approval. The control gap appears because the human authenticates themselves, but they are not necessarily validating the requester’s intent, endpoint posture, or requested scopes. If the requester is malicious, it can present a plausible prompt while quietly asking for broad delegated access.

That is why the safer framing is runtime authorisation. For high-risk workflows, organisations should prefer context-aware checks that evaluate who is requesting, what scopes are being asked for, whether the device is managed, and whether the user should be allowed to consent at all. Where possible, move toward policy-as-code and conditional access rather than static allow lists. Device-code can still be acceptable for constrained devices, but the approval step should be treated as a privilege grant, not a routine authentication event.

• Restrict device-code flows to known application patterns and managed user groups.
• Disable end-user consent where the tenant model allows it, or tightly scope which apps may request consent.
• Require admin approval for sensitive scopes such as mailbox, directory, or file access.
• Monitor for unusual token issuance, first-time app consent, and post-approval API activity.
• Shorten token lifetimes where feasible and revoke refresh tokens quickly after suspicious approvals.

This is consistent with the risk framing in Top 10 NHI Issues and with identity-centric control thinking in the NIST Zero Trust Architecture guidance. These controls tend to break down in organisations that allow broad self-service consent across legacy SaaS tenants because the approval event is then detached from meaningful policy enforcement.

Common Variations and Edge Cases

Tighter consent controls often increase support burden, requiring organisations to balance user friction against the risk of delegated access abuse. That tradeoff is most visible in research labs, contractor-heavy environments, and bring-your-own-device deployments where device-code was introduced to solve usability problems. Current guidance suggests treating these cases differently, but there is no universal standard for this yet.

Some environments also confuse device-code approval with phishing-resistant authentication. They are not the same. A phishing-resistant factor can prove the user, but it does not prove the requester is trustworthy or the requested scopes are appropriate. Similarly, a managed device does not make a malicious app safe if the app can still solicit approval and inherit powerful delegated permissions. The strongest pattern is to pair approval restrictions with scope governance, token monitoring, and rapid revocation.

For organisations adopting stronger identity governance, the practical lesson is to map device-code approvals into the broader NHI control plane. That means reviewing consent grants as part of access governance, not just sign-in hygiene, and using Ultimate Guide to NHIs - Key Challenges and Risks as a reminder that long-lived delegated access is often more damaging than the initial approval event. Edge cases become especially dangerous when high-privilege users approve unfamiliar apps during incident response, because urgency lowers scrutiny and the attacker benefits from legitimate-looking audit trails.

Related resources from NHI Mgmt Group

• 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?
• Why do workflow automation platforms create such high lateral movement risk?
• Why do dormant packages create supply-chain risk in developer environments?