What happens when users enter a malicious device code on a trusted login page?

What a Malicious Device Code Abuses on a Trusted Login Page

A device code flow is vulnerable when the user trusts the page but does not independently verify who originated the code. The page can be genuine, yet the code can still bind the victim’s approval to an attacker-controlled session. That means the attacker is not breaking the login page itself; they are abusing the approval step to obtain a token the victim authorises.

This matters because the security boundary shifts from password entry to consent and code verification. If users are trained to approve prompts quickly, or if the code is presented in a context that looks routine, the attacker can convert user trust into authenticated access without needing credentials or MFA bypass. The result is often harder to detect than a password theft because the sign-in looks legitimate at the point of issuance.

In practice, many security teams discover the abuse only after a valid token has already been minted and used from an unfamiliar device or network.

How the Attack Works in Practice

The attacker first obtains or creates a device code for a target service, then gets the victim to enter that code on a legitimate login page. Once the page accepts the code, the page asks the user to approve the device or session. If the user complies, the service issues an access token or refresh token tied to the attacker’s pending request, not to the victim’s physical device. The trusted page is therefore not proof that the code is safe.

The practical failure is a trust mismatch: the user sees an official domain and assumes the request is legitimate, while the attacker controls the underlying authorization context. Good defenses reduce the chance that a code can be reused across sessions, limit its lifetime, and make the approval step clearly tied to a specific application, device, or origin. Where possible, organisations should also separate user-facing verification from silent token issuance so that an unexpected request is easier to spot.

• Short-lived codes reduce the time available for social engineering and relay abuse.
• Strong session binding makes it harder for a code captured in one context to be redeemed in another.
• Clear device and application naming improves the chance that users notice a mismatch before approving.
• Token revocation and sign-in monitoring are critical because the attacker may already hold a valid token after approval.

The NHI Management Group notes that 80% of identity breaches involve compromised non-human identities such as service accounts and API keys, which is a reminder that token-centric abuse is often the real control failure rather than the login page itself. The OWASP Non-Human Identity Top 10 is also a useful companion reference because it frames how machine-authenticated access can be abused when trust, lifecycle, and verification are weak.

These controls tend to break down when approval happens on a mobile device or in a rushed support workflow, because users rely on the legitimacy of the page instead of checking whether the code and request context actually belong together.

When the Usual Guidance Breaks Down

Tighter verification often increases user friction, so organisations have to balance convenience against the risk of consent-based token theft. This is especially true in environments that use device codes for headless devices, shared workstations, or emergency access, where the user experience already pushes people toward quick approval.

Best practice is evolving on how much context should be shown at approval time, but current guidance suggests that visible request details, strong logging, and narrow token scope do more than trying to treat every code as equally suspicious. If the workflow cannot show who initiated the request, what application will receive access, and whether the code is still fresh, the process is too easy to abuse.

Practitioner Guidance: Verify whether the approval step exposes enough request context for a human to make a meaningful decision; if it does not, treat the flow as high-risk and redesign it before expanding use. What practitioners underestimate is that the trusted page often creates false confidence, while the real control question is whether the code can be bound to the right session, the right origin, and the right token lifetime.

Practitioner takeaway: The important judgement is not whether the login page is trusted, but whether the code redemption path is defensibly bound to the request the user intended to approve.

Related resources from NHI Mgmt Group

• What happens when users enter credentials into a fake login page that proxies a real identity provider session?
• What happens when users can still interact with a cloned login page before detection kicks in?
• What happens when users open a malicious HTML page from a package mirror?
• What is the difference between device bound passkeys and traditional login methods?