Your Employee Sees a Familiar Microsoft Login. It's a Trap.
An employee is working when a Microsoft 365 pop-up appears, asking them to authorize a login. It provides a short code and a URL: microsoft.com/deviceauth. It looks official. They enter the code, approve the multi-factor authentication (MFA) push on their phone, and get back to work. They just handed an attacker long-term access to their account.
This isn't a theoretical threat. This specific attack, known as device code phishing, has surged by more than 3,700% in the past year. Attackers are exploiting a legitimate feature to bypass standard security and walk right into your network.
How Convenience Became a Weapon
The feature being abused is the "OAuth 2.0 Device Authorization Grant." That's a mouthful, so let's translate. It was designed to let you log into devices that don't have keyboards, like a smart TV or a conference room console. You go to a URL on your phone or computer, enter a code from the TV screen, and you're logged in. Simple and convenient.
Attackers have turned this convenience into a weapon. Here’s the sequence:
- An attacker initiates a login to your M365 tenant using the employee's email address on their own machine. They select the "sign in on another device" option.
- Microsoft generates a one-time code.
- The attacker sends a phishing email or Teams message to your employee, perhaps disguised as an IT alert or a document link, which triggers the official Microsoft login prompt with the code.
- Your employee, seeing a legitimate Microsoft prompt, enters the code and approves the MFA notification. They believe they are authorizing their own session.
The result? The attacker’s machine is now authorized. They receive an access token that can give them persistent access to the employee's email, SharePoint, Teams, and OneDrive for up to 90 days, even if the employee changes their password.
MFA Didn't Stop It. Why?
This is the most critical part to understand: your standard MFA protections don't stop this attack. The employee is the one approving the login. The MFA system sees a legitimate user approving a legitimate request from a legitimate Microsoft service. It has no way of knowing the request was initiated by a criminal on the other side of the world.
This isn't a failure of MFA; it's a social engineering attack that cleverly uses your own security protocols against you.
The Uncomfortable Truth About Access
Let's be blunt. Your team's desire for streamlined, frictionless access is in direct conflict with robust security. Every feature designed to make logging in easier from anywhere also creates a potential new entry point for an attacker to exploit. This device code flow is a prime example.
Waiting for an employee to spot a sophisticated phishing attempt is not a strategy. The login prompts are genuine, the URLs are legitimate, and the process feels familiar. You cannot rely on user vigilance alone to defend against this.
Our Recommendation: A Necessary Trade-Off
The only effective way to mitigate this threat is to control the feature that enables it. Our clear stance is this: You should block the device code authentication flow for the vast majority of your users.
This is done through targeted Conditional Access policies within Azure Active Directory. We can configure a policy that prevents this type of sign-in unless it originates from a trusted network location (like your main office) or is performed by a user who explicitly requires it (like an IT administrator setting up a conference room).
Now, for the trade-off. This introduces friction. If your team relies on this feature for specific workflows, those will need to be re-evaluated. Implementing this control is a deliberate choice to sacrifice a small amount of convenience for a massive gain in security. It closes a backdoor that is proving dangerously effective.
As part of our ongoing security management, we are actively auditing all client environments for suspicious device code authentications. If you haven't already discussed implementing a restrictive Conditional Access policy with us, please reach out. We need to ensure your M365 tenant isn't leaving this door wide open.
