MFA Was On. The Account Got Taken Anyway.

It Is a Tuesday Afternoon

One of your accounts payable employees forwards you an email and asks if it looks right.

Earlier that morning she signed in to what looked like the normal Microsoft login page. She typed her password. Her phone buzzed with a notification and she approved it, the same way she does every day.

Nothing felt wrong. MFA was on. The sign-in succeeded.

By the afternoon, the banking details on an outgoing vendor payment have been changed. The sign-in logs show a successful login from a location nobody recognizes.

You are the one who has to explain how this happened with multi-factor enabled.

The Assumption Most Teams Are Still Running On

The belief is simple, and it used to be true: "We have MFA, so we are covered."

For years that held up. MFA shut down the attacks that relied on stolen or guessed passwords alone. It was one of the highest-value security moves a manufacturing IT team could make.

The problem is that the attackers moved. The defense has not kept up.

Why OTP and Push Stopped Being Enough

The common forms of MFA still ask a person to do something: read a code, type a code, or approve a prompt. Anything a person can hand over, an attacker can collect.

Here is how it plays out today:

1. The fake page sits in the middle. Attackers stand up a login page that looks exactly like Microsoft's and position themselves between your employee and the real service. When she types the password and the code, everything passes through to the real site. The attacker captures it all in transit.
2. The push prompt gets approved. A notification that just says "approve" trains people to tap yes. Time one to a real login attempt, or send enough of them, and someone will approve it.
3. The session gets stolen, not the password. Once the employee authenticates, the service issues a session token — the digital wristband that says "this person is already logged in." The attacker takes that token and walks in without needing the password or the code again.

That last point is the one that surprises people most. The attacker does not need to beat your MFA twice. They need to beat it once and take the session.

Relying on a team member to notice a convincing fake page is not a control. It is hope. And hope is not a control.

Why a Passkey Works

A passkey is not a stronger password. It is not a better code. It removes the thing the attacker was after entirely.

When an employee sets up a passkey, her device creates a pair of keys. The private key never leaves the device. There is nothing to type, nothing to read off a screen, and nothing to approve on a page that turns out to be fake.

• Nothing to phish. No code is entered. No secret travels across the session.
• Bound to the real site. The login is cryptographically tied to the real Microsoft domain. A lookalike page in the middle gets nothing it can use.
• Nothing to hand over by mistake. The employee cannot be tricked into giving away a secret, because there is no secret to give.

That is the idea in one line: there is no secret to steal.

What This Protects in a Microsoft Environment

If your identity runs on Entra, this is closer than most IT teams assume. Microsoft Authenticator, the app many of your employees already have on their phones, can hold a passkey today. The tool is likely already in the building.

A passkey tied to your Entra identity protects the sign-in to:

• Windows on the devices your team uses every day
• Microsoft 365, where the email and files that fraud targets actually live
• Entra itself, the front door to your environment
• Any SSO application connected to that same Entra identity, which for most manufacturers is a long list

One identity. Protected by a login that cannot be handed to the wrong person.

How InsITe Approaches It

We do not rip out what works on day one. We start by moving the highest-risk accounts first: finance, leadership, and admin logins. From there we phase the rest of the organization in and tighten the policies that govern what a sign-in is allowed to do. Practical, phased, and built around the way your people already work.

The Gap Is Already Open

The account takeover that opens this story does not look like a security event. It looks like a changed vendor payment. A quiet rule forwarding invoices somewhere else. A login from a country you do not operate in.

By the time it surfaces, it has already cost something.

"We had MFA enabled" is no longer the answer that ends the conversation with leadership. It is the start of a harder one.

Two questions worth sitting with:

If someone on your team approved a login on a convincing fake page this afternoon, is there anything in your current setup that would stop the attacker from getting in?

And how much of your security today still depends on a person noticing that something is wrong?

Strong authentication no longer means a harder secret. It means no secret at all. Move the protection out of your team's judgment and into the design of the login itself.

There is no secret to steal.