Imagine someone sends you a message saying:
“Hi, this is IT. We need you to complete a quick Microsoft verification. Go to microsoft.com/devicelogin and enter this code: ABCD-1234.”
You check the link.
It’s a real Microsoft website.
You enter the code.
Microsoft asks you to sign in.
You complete MFA.
Everything looks normal.
Except you’ve just helped an attacker sign in to your Microsoft 365 account.
That’s the danger of device code phishing.
It doesn’t rely on a fake Microsoft login page. It doesn’t necessarily need your password. And in some cases, your MFA approval can actually help the attacker complete their login.
Let’s break down what’s happening.
What exactly is device code phishing?
Microsoft has a legitimate feature called device code authentication.
It’s designed for situations where signing in directly isn’t convenient. For example, a device might display a short code and ask you to visit Microsoft’s login page on another device to complete the sign-in.
That’s completely legitimate.
The problem is that an attacker can start the process themselves.
The attacker gets a genuine Microsoft device code and then tries to convince you to enter it.
And that’s where things go wrong.
The important part: the code belongs to the attacker
This is the bit many people don’t realise.
When you receive a code from an attacker, that code isn’t asking you to sign in to your own computer.
It’s completing a login that the attacker already started.
Think of it like this:
- The attacker starts a Microsoft 365 login on their computer.
- Microsoft gives them a temporary code.
- The attacker sends that code to you.
- You enter the code on Microsoft’s real website.
- Microsoft asks you to authenticate.
- You complete MFA.
- Microsoft finishes the attacker’s login.
The attacker is now authenticated as you.
You never gave them your password.
You didn’t visit a fake website.
You may even have done everything Microsoft told you to do.
That’s what makes this attack so nasty.
Why does MFA not necessarily save you?
This is where people often misunderstand the attack.
You might think:
“I’ve got MFA enabled, so I’m protected.”
Not necessarily.
The attacker isn’t trying to guess your MFA code or break Microsoft’s MFA system.
They’re trying to trick you into approving their login.
From Microsoft’s perspective, the authentication can look perfectly legitimate.
The attacker started a genuine Microsoft sign-in.
You provided the authentication.
You completed MFA.
Microsoft therefore has evidence that the account owner authenticated.
The problem is that you authenticated the attacker’s session rather than your own.
That’s why calling this an “MFA bypass” isn’t quite accurate.
MFA wasn’t technically broken.
The attacker abused the authentication process and your trust.
Why Teams makes this attack even more convincing
Now imagine the message arrives in Microsoft Teams.
It says:
“Hi Salman, this is IT. We’re making a security change to your account. Can you quickly enter this code at microsoft.com/devicelogin?”
You might think:
“Well, it’s Teams. It’s probably legitimate.”
That’s exactly what the attacker wants you to think.
They can create urgency:
“Please do this now.”
They can pretend to be IT:
“We’re checking your Microsoft account.”
They can pretend to be your manager:
“I need you to complete this quickly.”
And the most dangerous part?
They can send you to the real Microsoft website.
So telling users to “check the URL” isn’t enough anymore.
The website can be completely genuine.
The problem is what you’re being asked to do on it.
A simple way to remember it
Here’s the rule I’d give every Microsoft 365 user:
Never enter a Microsoft authentication code that someone else sends you.
If you didn’t start the sign-in yourself, don’t complete it.
It doesn’t matter whether the request comes from:
- IT
- Your manager
- A colleague
- Microsoft
- A Teams message
- An email
- Someone claiming to be technical support
If you’re unsure, contact IT using a known contact method, not by replying to the message.
Why changing the password may not be enough
Here’s another important point for administrators.
Suppose a user falls for the attack.
They immediately change their password.
Problem solved?
Not necessarily.
A password reset changes the password, but an attacker may already have an authenticated session or refresh token.
That’s why a suspected device-code attack should be treated as a potential account compromise, not simply a password problem.
Your response should include:
- Reviewing Microsoft Entra sign-in logs
- Checking unfamiliar devices, IP addresses and locations
- Reviewing applications involved in the sign-in
- Revoking active sessions/tokens where appropriate
- Resetting credentials when required
- Checking Exchange mailbox activity
- Checking suspicious inbox rules
- Reviewing SharePoint and OneDrive activity
- Checking Teams activity
- Looking for other suspicious account changes
The key point is:
Don’t assume changing the password automatically kicks the attacker out of everything.
So how do you block device code phishing?
This is where Microsoft Entra Conditional Access comes in.
You can create a Conditional Access policy that blocks the device code authentication flow.
In the Microsoft Entra admin centre, go to:
Identity → Conditional Access → Policies
Create a new policy with settings along these lines:
Users
All users
Exclude your properly protected emergency or break-glass accounts.
Target resources
All resources
Conditions
Go to Authentication flows.
Select:
Device code flow
Access controls
Select:
Block access
Give the policy an obvious name, for example:
CA – Block Device Code Flow
The name matters more than people think.
Six months from now, another administrator should be able to look at your Conditional Access policies and immediately understand what the policy is doing.
Don’t just switch it on immediately
This is where administrators sometimes get themselves into trouble.
Don’t blindly create the policy and turn it on.
Start with:
Report-only
This allows you to see what would happen without immediately blocking users.
Why?
Because you might have a legitimate application, device or workflow somewhere in the tenant that relies on device code authentication.
You don’t want to discover that after you’ve broken something.
Review the Entra logs.
Look at:
- Who is using device code authentication
- Which applications are involved
- Where the sign-ins are coming from
- Whether the activity is legitimate
- Whether anything needs to be migrated to another authentication method
Once you’re confident, move the policy from Report-only to On.
Then test it.
What about break-glass accounts?
You should normally have emergency access accounts that are excluded from Conditional Access policies.
But don’t misunderstand what that means.
A break-glass account isn’t a convenient way around security controls.
It should be:
- Highly protected
- Used only for emergencies
- Closely monitored
- Excluded only where genuinely necessary
- Tested regularly
And every use should trigger an investigation.
If your “break-glass” account is being used every Friday because someone forgot their normal admin credentials, you’ve got an administration problem, not a break-glass strategy.
Blocking device code isn’t your entire security strategy
Blocking device code flow is a useful defence, but don’t make the mistake of thinking:
“We’ve blocked it, so we’re protected.”
You still need strong identity security.
Consider combining it with:
- Phishing-resistant MFA
- Conditional Access
- Risk-based sign-in policies
- User risk policies
- Least-privilege access
- Microsoft Defender
- Sign-in monitoring and alerting
- Regular user awareness training
And most importantly, teach users what the attack actually looks like.
Generic security training saying “don’t click suspicious links” isn’t enough anymore.
Users need to understand that:
A real Microsoft website can still be part of a phishing attack.
That’s the lesson.
What should a user do if they already entered a suspicious code?
Don’t panic, but don’t ignore it either.
Tell your IT/security team immediately.
Explain exactly what happened.
Then the security team should investigate the account, review Entra sign-ins and audit logs, revoke sessions/tokens where appropriate, and check Microsoft 365 activity for anything suspicious.
The faster you investigate, the better.
Don’t wait until someone notices emails being sent, files being downloaded or mailbox rules being changed.
The one rule every Microsoft 365 user should remember
Here’s the simplest way to explain device code phishing to your users:
If you didn’t start the login, don’t finish the login.
Someone sends you a Microsoft code?
Don’t enter it.
Someone from “IT” asks you to enter a code?
Verify them through a known channel.
Someone sends you to Microsoft’s genuine login page?
That still doesn’t automatically make the request safe.
Because with device code phishing, the attacker doesn’t need to fake Microsoft’s website.
They just need you to complete their login for them.
And that’s what makes this attack so effective.Imagine someone sends you a message saying:
“Hi, this is IT. We need you to complete a quick Microsoft verification. Go to microsoft.com/devicelogin and enter this code: ABCD-1234.”
You check the link.
It’s a real Microsoft website.
You enter the code.
Microsoft asks you to sign in.
You complete MFA.
Everything looks normal.
Except you’ve just helped an attacker sign in to your Microsoft 365 account.
That’s the danger of device code phishing.
It doesn’t rely on a fake Microsoft login page. It doesn’t necessarily need your password. And in some cases, your MFA approval can actually help the attacker complete their login.
Let’s break down what’s happening.
What exactly is device code phishing?
Microsoft has a legitimate feature called device code authentication.
It’s designed for situations where signing in directly isn’t convenient. For example, a device might display a short code and ask you to visit Microsoft’s login page on another device to complete the sign-in.
That’s completely legitimate.
The problem is that an attacker can start the process themselves.
The attacker gets a genuine Microsoft device code and then tries to convince you to enter it.
And that’s where things go wrong.
The important part: the code belongs to the attacker
This is the bit many people don’t realise.
When you receive a code from an attacker, that code isn’t asking you to sign in to your own computer.
It’s completing a login that the attacker already started.
Think of it like this:
- The attacker starts a Microsoft 365 login on their computer.
- Microsoft gives them a temporary code.
- The attacker sends that code to you.
- You enter the code on Microsoft’s real website.
- Microsoft asks you to authenticate.
- You complete MFA.
- Microsoft finishes the attacker’s login.
The attacker is now authenticated as you.
You never gave them your password.
You didn’t visit a fake website.
You may even have done everything Microsoft told you to do.
That’s what makes this attack so nasty.
Why does MFA not necessarily save you?
This is where people often misunderstand the attack.
You might think:
“I’ve got MFA enabled, so I’m protected.”
Not necessarily.
The attacker isn’t trying to guess your MFA code or break Microsoft’s MFA system.
They’re trying to trick you into approving their login.
From Microsoft’s perspective, the authentication can look perfectly legitimate.
The attacker started a genuine Microsoft sign-in.
You provided the authentication.
You completed MFA.
Microsoft therefore has evidence that the account owner authenticated.
The problem is that you authenticated the attacker’s session rather than your own.
That’s why calling this an “MFA bypass” isn’t quite accurate.
MFA wasn’t technically broken.
The attacker abused the authentication process and your trust.
Why Teams makes this attack even more convincing
Now imagine the message arrives in Microsoft Teams.
It says:
“Hi Salman, this is IT. We’re making a security change to your account. Can you quickly enter this code at microsoft.com/devicelogin?”
You might think:
“Well, it’s Teams. It’s probably legitimate.”
That’s exactly what the attacker wants you to think.
They can create urgency:
“Please do this now.”
They can pretend to be IT:
“We’re checking your Microsoft account.”
They can pretend to be your manager:
“I need you to complete this quickly.”
And the most dangerous part?
They can send you to the real Microsoft website.
So telling users to “check the URL” isn’t enough anymore.
The website can be completely genuine.
The problem is what you’re being asked to do on it.
A simple way to remember it
Here’s the rule I’d give every Microsoft 365 user:
Never enter a Microsoft authentication code that someone else sends you.
If you didn’t start the sign-in yourself, don’t complete it.
It doesn’t matter whether the request comes from:
- IT
- Your manager
- A colleague
- Microsoft
- A Teams message
- An email
- Someone claiming to be technical support
If you’re unsure, contact IT using a known contact method, not by replying to the message.
Why changing the password may not be enough
Here’s another important point for administrators.
Suppose a user falls for the attack.
They immediately change their password.
Problem solved?
Not necessarily.
A password reset changes the password, but an attacker may already have an authenticated session or refresh token.
That’s why a suspected device-code attack should be treated as a potential account compromise, not simply a password problem.
Your response should include:
- Reviewing Microsoft Entra sign-in logs
- Checking unfamiliar devices, IP addresses and locations
- Reviewing applications involved in the sign-in
- Revoking active sessions/tokens where appropriate
- Resetting credentials when required
- Checking Exchange mailbox activity
- Checking suspicious inbox rules
- Reviewing SharePoint and OneDrive activity
- Checking Teams activity
- Looking for other suspicious account changes
The key point is:
Don’t assume changing the password automatically kicks the attacker out of everything.
So how do you block device code phishing?
This is where Microsoft Entra Conditional Access comes in.
You can create a Conditional Access policy that blocks the device code authentication flow.
In the Microsoft Entra admin centre, go to:
Identity → Conditional Access → Policies
Create a new policy with settings along these lines:
Users
All users
Exclude your properly protected emergency or break-glass accounts.
Target resources
All resources
Conditions
Go to Authentication flows.
Select:
Device code flow
Access controls
Select:
Block access
Give the policy an obvious name, for example:
CA – Block Device Code Flow
The name matters more than people think.
Six months from now, another administrator should be able to look at your Conditional Access policies and immediately understand what the policy is doing.
Don’t just switch it on immediately
This is where administrators sometimes get themselves into trouble.
Don’t blindly create the policy and turn it on.
Start with:
Report-only
This allows you to see what would happen without immediately blocking users.
Why?
Because you might have a legitimate application, device or workflow somewhere in the tenant that relies on device code authentication.
You don’t want to discover that after you’ve broken something.
Review the Entra logs.
Look at:
- Who is using device code authentication
- Which applications are involved
- Where the sign-ins are coming from
- Whether the activity is legitimate
- Whether anything needs to be migrated to another authentication method
Once you’re confident, move the policy from Report-only to On.
Then test it.
What about break-glass accounts?
You should normally have emergency access accounts that are excluded from Conditional Access policies.
But don’t misunderstand what that means.
A break-glass account isn’t a convenient way around security controls.
It should be:
- Highly protected
- Used only for emergencies
- Closely monitored
- Excluded only where genuinely necessary
- Tested regularly
And every use should trigger an investigation.
If your “break-glass” account is being used every Friday because someone forgot their normal admin credentials, you’ve got an administration problem, not a break-glass strategy.
Blocking device code isn’t your entire security strategy
Blocking device code flow is a useful defence, but don’t make the mistake of thinking:
“We’ve blocked it, so we’re protected.”
You still need strong identity security.
Consider combining it with:
- Phishing-resistant MFA
- Conditional Access
- Risk-based sign-in policies
- User risk policies
- Least-privilege access
- Microsoft Defender
- Sign-in monitoring and alerting
- Regular user awareness training
And most importantly, teach users what the attack actually looks like.
Generic security training saying “don’t click suspicious links” isn’t enough anymore.
Users need to understand that:
A real Microsoft website can still be part of a phishing attack.
That’s the lesson.
What should a user do if they already entered a suspicious code?
Don’t panic, but don’t ignore it either.
Tell your IT/security team immediately.
Explain exactly what happened.
Then the security team should investigate the account, review Entra sign-ins and audit logs, revoke sessions/tokens where appropriate, and check Microsoft 365 activity for anything suspicious.
The faster you investigate, the better.
Don’t wait until someone notices emails being sent, files being downloaded or mailbox rules being changed.
The one rule every Microsoft 365 user should remember
Here’s the simplest way to explain device code phishing to your users:
If you didn’t start the login, don’t finish the login.
Someone sends you a Microsoft code?
Don’t enter it.
Someone from “IT” asks you to enter a code?
Verify them through a known channel.
Someone sends you to Microsoft’s genuine login page?
That still doesn’t automatically make the request safe.
Because with device code phishing, the attacker doesn’t need to fake Microsoft’s website.
They just need you to complete their login for them.
And that’s what makes this attack so effective.
Salman Tariq
SalmanTechBlogs 
Leave a comment