Device Code Phishing: The M365 Attack That Skips Your Password

A dental office manager in Nashua forwarded us an email last week and asked a simple question: “Is this real?”

It looked like a shared-folder notification. A vendor she worked with wanted her to review a document. The email pointed to a page that asked her to open the real Microsoft sign-in and type in a short code to “connect the shared workspace.” No fake password page. No misspelled domain. The Microsoft login it sent her to was the genuine one.

She had done half the steps before something felt off and she stopped.

Good instinct, because that email was a device code phishing attempt, and the reason it felt legitimate is that most of it was legitimate. The attacker never needed her password. He needed her to approve a login he had already started. If she had finished, he would have walked into her Microsoft 365 account with a valid session, MFA and all, and she would have gotten nothing but a document that never showed up.

This attack has been picking up all summer. Security researchers have been tracking a phishing-as-a-service platform behind a wave of it running from late June into July, and the pattern is worth understanding, because it defeats exactly the defense most small businesses think has them covered. If your whole security answer is “we have MFA,” this is the attack that walks around it while you watch.

What device code phishing actually is

To understand the attack, you have to understand a normal, boring Microsoft feature it abuses.

Some devices can’t show you a real login screen. Think of a smart TV, a conference room display, a printer, or a command-line tool. Microsoft built a way for those devices to sign you in anyway. The device shows you a short code. You go to a Microsoft page on your phone or laptop, type in that code, and approve the login. The device is now signed in as you. It’s called the device code flow, and it exists for good reasons.

The attack hijacks that handshake.

Here’s the move, stripped down. The attacker starts a device code login himself, on his own machine, pretending to be a device that needs to sign in to your Microsoft 365. Microsoft hands him a real code. He then emails you and gets you to type that code into the real Microsoft page and approve it. You think you’re connecting to a shared folder, a Teams workspace, a new app. What you’re actually doing is approving his login. Microsoft sees a legitimate approval from the real account owner, completes the sign-in, and hands the attacker a valid session token.

He’s now signed in as you. He never saw your password. He never had to defeat your MFA, because you passed it for him.

That’s the whole trick, and its ugliness is that every individual step is real. Real Microsoft page. Real login. Real MFA prompt. Real approval. The only lie is what you were told the code was for.

Why “we have MFA” doesn’t stop this

We spend a lot of time telling small businesses to turn on multi-factor authentication, and we stand by every word of it. MFA blocks the overwhelming majority of credential attacks. If you don’t have it on every account yet, that’s still the first thing to fix.

But MFA checks one thing: are you the person who owns this account? In a device code attack, the answer is yes. You really are that person. You really did approve the login. MFA did its job perfectly and let the right person in. The problem is that the right person was tricked into opening the door for someone standing behind them.

We wrote recently about how hackers aren’t breaking in anymore, they’re logging in. Device code phishing is the cleanest example of that shift we’ve seen. There’s no exploit, no malware, no vulnerability. There’s a person, a code, and a moment of misplaced trust. The attacker doesn’t fight your security. He borrows your credentials by asking you to use them on his behalf.

This is why treating MFA as the finish line is dangerous. MFA is the floor, not the ceiling. The attacks that matter in 2026 are built specifically to get around ordinary MFA, and this is one of them.

How the email gets to you

The delivery is deliberately low-drama, which is part of why it works.

The lures researchers are seeing lean on collaboration themes: a shared document, a payment or invoice you need to review, a Teams message, a folder someone wants you to access. Nothing screams emergency. Nothing asks for your password. The email just wants you to click through and “connect” or “verify.”

In the campaign tracked this summer, the link often led to a legitimate but compromised website, a real business’s site that had been quietly taken over to host the attacker’s device code prompt. So even a careful person checking where the link goes might see a real company’s domain, not some sketchy string of characters. From there, the page walks you through entering the code on the genuine Microsoft site.

The whole experience is designed to feel like setup, not like an attack. You’re “linking an app.” You’re “connecting a workspace.” That framing is doing a lot of work, because approving a login feels routine when you think you’re the one setting something up.

Notice what’s missing from all of this: a fake login page. Traditional phishing had to build a convincing counterfeit of the Microsoft sign-in and hope you didn’t notice the URL was wrong. Device code phishing skips that entirely. It sends you to the real Microsoft. That’s harder to catch, because the usual advice, “check that it’s really the Microsoft login,” passes with flying colors. It is really the Microsoft login.

What happens after you approve

If someone completes the flow, the attacker gets a session token, and a session token is a set of keys.

With it, he’s inside the Microsoft 365 account as that user. He can read email, including everything in the archive. He can search for the words that matter to him, invoice, payment, wire, bank, routing, and learn exactly how your business handles money. He can set up a quiet inbox rule to hide his tracks or intercept vendor replies. He can send email as the compromised user, which is where business email compromise and fraudulent wire requests come from. And depending on how the account is set up, he can move toward other systems and other users from there.

This is the same damage pattern we see after any account takeover, and we’ve walked through where it lands inside a tenant in our piece on why your Microsoft 365 tenant is probably misconfigured. The account is the front door to the whole company now. Email, files, chat, admin controls, password resets for other services, it all sits behind that one login. A stolen session doesn’t just cost you one mailbox. It can cost you the business’s money and its relationships with the vendors and clients who trust email from your domain.

And because the attacker came in through a valid session, nothing looks obviously broken. No alarm goes off saying “malware detected.” From most monitoring, it looks like the user is just working. That’s exactly why detection and a human watching for the odd sign-in matters so much, and we’ll get to that.

The controls that actually stop it

Here’s the reassuring part, and as usual with us, it’s not a pitch for a new product. The controls that shut down device code phishing are mostly settings you already own if you pay for Microsoft 365. The work is turning them on and configuring them for how your business actually operates.

Block the device code flow if you don’t need it

Most small businesses do not use the device code flow for anything. No conference room displays signing into your tenant, no command-line tools your team runs daily. If that’s you, Microsoft 365 lets you block the device code flow with a Conditional Access policy, and blocking something you never use is the cleanest fix there is. An attack that depends on a feature you’ve turned off simply doesn’t work.

If you do have a genuine need for it, on a handful of specific devices, that exception can be scoped narrowly and documented instead of left open for everyone. This is exactly the kind of tenant-wide decision that proper Microsoft 365 managed services exist to make: knowing which features you can safely close off without breaking anyone’s day.

Conditional Access, doing the work behind every login

Blocking device code is one policy. The broader control is Conditional Access, which lets you put rules around every sign-in, not just the password check.

If your company operates in New Hampshire and Massachusetts and nobody works overseas, a sign-in tied to another continent should be denied, not merely noticed. Access to sensitive data can require a known, company-managed device, which a random attacker machine won’t be. Legacy authentication, the old protocols that can’t do MFA at all, should be off entirely. Configured well, Conditional Access turns “the attacker got a valid session” into “the valid session still can’t get anywhere it shouldn’t.”

Conditional Access is the single most valuable Microsoft 365 control that small businesses already pay for and almost never switch on. It’s the difference between a login being enough and a login being just the first hurdle.

Phishing-resistant MFA for the accounts that matter

Ordinary MFA didn’t stop this attack because the user approved it. But phishing-resistant MFA, passkeys and hardware security keys, changes the math for other attacks in this family, and it’s the strongest identity upgrade available right now. Roll it out first to the people who touch money, hold admin rights, or own the company. It’s included in the licensing most small businesses already have.

Pair it with token protection and shorter session lifetimes for sensitive apps, so that a stolen session is worth less and expires sooner. Both are configuration, not new purchases.

Someone watching the logins who will actually react

The dental office almost got got, but the manager stopped and asked a human. That’s the pattern that saves businesses: a person in the loop.

On the technical side, the equivalent is real monitoring with someone who reads the alerts. A device code approval from an unusual place, a brand-new inbox rule quietly forwarding mail, a sign-in at 3 a.m. from a region you don’t operate in, these show up in the logs. The account takeovers that turn into disasters are almost always the ones where nobody was watching the logs for weeks. Solid remote monitoring and management with a human who acts the same day is the difference between catching this on day one and finding out when a vendor calls about a payment you never authorized.

Train people on this specific move

General “don’t click bad links” training won’t catch this, because the link goes to the real Microsoft. The training that helps is specific: never enter a code into a Microsoft sign-in page unless you personally started the process on the device asking for it. If an email, a document, or a “connect this workspace” prompt hands you a code and tells you to approve a login, stop. You didn’t start that login. Someone else did.

That one rule, taught plainly, would have stopped every version of this attack we’ve seen. It pairs with the broader habit we push at every business we work with: slow down and verify anything involving money, credentials, or a login you didn’t personally initiate.

A short checklist before you close this tab

Run these against your own Microsoft 365 setup. If any answer is “I’m not sure,” that’s the one to chase down.

• Is the device code flow blocked in your tenant, or scoped to only the devices that truly need it?
• Do you have Conditional Access policies on sign-ins, or is a valid login enough to go anywhere?
• Are logins from countries you don’t operate in blocked outright?
• Is legacy authentication turned off?
• Do the people who touch money and admin accounts have phishing-resistant MFA?
• Is someone, internal or your MSP, actually watching sign-in activity and able to react the same day?
• Does your team know not to approve a login or enter a code they didn’t personally start?

None of these are spending problems. They’re configuration-and-attention problems, which is genuinely good news, because those get fixed in weeks and usually without a bigger bill.

The honest takeaway

Device code phishing isn’t clever because it’s technically advanced. It’s clever because it’s honest about being Microsoft the whole way through, and it lets your own trust do the breaking-in. There’s no wall to smash, no lock to pick. There’s a code, a request, and a person who was told the wrong thing about what they were approving.

The defense is a mix of a few settings you already own and one clear habit for your team. Close the door you don’t use. Put rules behind the logins you do. And teach people that a login they didn’t start is not a login they should finish.

If you’re not sure whether your Microsoft 365 tenant is exposed to this, RNITS can check it with you. Start with a free cyber security audit or reach us through our contact page. We’ll show you what’s actually open, what already holds, and what to fix first.