# MFA is on, and the account was still breached > Modern phishing bypasses app-based MFA. What phishing-resistant authentication requires in practice, what it costs and where to start. - Author: Jami Susijärvi, Oy Wolflake Consulting Ab - Published: 2026-09-22 - Web page: https://wolflake.fi/en/blog/why-mfa-is-not-enough "We have MFA enabled for everyone." That is the most common answer when I ask a client how security has been handled. It was a good answer in 2019. In 2026 it tells you very little about whether someone can get into your accounts. In 2025 the Finnish National Cyber Security Centre received [over 330 reports of compromised Microsoft 365 accounts](https://www.kyberturvallisuuskeskus.fi/en/varoitus_1/2025) in Finnish organisations. In October alone there were 121 of them, close to four every single day. Their own message in the warning was that neither a password change nor multi-factor authentication alone prevents a breach. That does not mean MFA is useless. It means attackers have moved past it. The problem has two sides, and they often appear in the same environment. The authentication method can be too weak to withstand current phishing. Or the method can be the right one, but it does not cover every account. The outcome is the same either way. ## How current phishing bypasses MFA Two techniques explain the majority of the cases I see. **AiTM phishing, or adversary-in-the-middle.** The user clicks a link and lands on a page that looks like the Microsoft sign-in page. It is not an imitation but a [proxy](https://learn.microsoft.com/entra/identity/devices/protecting-tokens-microsoft-entra-id): it shows the real page and relays everything through. The user enters their password, gets an MFA prompt on their own phone and approves it, because everything looks completely normal. The sign-in genuinely succeeds. Because all traffic passes through the attacker, they capture both the username and the password. The most valuable prize, however, is the session cookie created after a successful sign-in. With it the attacker reaches the account from their own machine without being asked for MFA again. Changing the password afterwards does not close that session; it has to be revoked separately. **Device code phishing.** This one is sneakier, because there is no fake page at all. The attacker starts a device code sign-in themselves and receives a code. They then send the victim a message asking them to enter the code on the Microsoft site, using a fabricated meeting invitation or document as the pretext. The user goes to the genuine address, signs in with their own credentials and approves MFA. Everything is authentic, but the session is created on the attacker's device. The Finnish National Cyber Security Centre warned about a wave of this in spring 2026. The common denominator: from the user's point of view they did everything right, and MFA was completed successfully. Training helps to a degree, but it is not the solution. In AiTM phishing the only reliable sign is an address bar that is not Microsoft's, and spotting that in a hurry is unreliable. In device code phishing there is not even that, because the address is genuine. ## What actually helps Phishing-resistant authentication means two things at once. First, the credential is bound to the site being signed in to. It simply does not work at the wrong address, so an attacker sitting in the middle gets nothing usable. Second, the user has nothing they could pass on. No code to read out over the phone, no approval that someone could ask them to accept. This matters just as much as the first point, because some cases begin with a call from someone posing as IT support. The user does not have to recognise the scam, because the scam does not get anywhere. In a Microsoft 365 environment there are three options. **Passkeys.** The most common and easiest in practice. A passkey is a credential based on the FIDO2 standard, and in Microsoft's settings the method is called "Passkey (FIDO2)". A passkey can live in Microsoft Authenticator, in the phone's own keychain, in the Windows Hello container or on a separate USB key. Signing in happens with a fingerprint, a face or a PIN. The key is cryptographically bound to Microsoft's address, so a proxy gets nothing out of it. **Windows Hello for Business.** If workstations are Entra joined and managed with Intune, this often already exists. Users sign in to the machine with a fingerprint or a PIN, and the same authentication counts as phishing-resistant for cloud services. **Certificate-based authentication.** Smart cards and certificates also qualify as phishing-resistant. This is clearly rarer and heavier to set up, because it needs a working certificate infrastructure behind it. It is still worth knowing as an option, especially if the organisation already has a PKI and cards in use for some other reason, as in healthcare or the public sector. On top of these, two things are needed in Conditional Access. First, a requirement that authentication must be phishing-resistant, not just any MFA. Microsoft provides this ready-made under the name "Phishing-resistant MFA strength". Second, blocking device code sign-in, which is now its own condition in Conditional Access. Microsoft's [own recommendation](https://learn.microsoft.com/entra/identity/conditional-access/policy-block-authentication-flows) is to block it everywhere it is not specifically needed. A third and very effective addition is to require a managed or compliant device. A stolen session then does not help the attacker, because their own machine does not meet the condition. ## This is not a licensing question One common objection is that all this requires more expensive licences. It does not. Passkeys are included in [every edition of Entra ID, including the free one](https://learn.microsoft.com/entra/identity/authentication/how-to-authentication-passkeys-fido2). Microsoft's documentation says it outright: no additional licences are required. You can enable passkeys and let users register them without anything costing extra. A licence is only needed for enforcement. Conditional Access requires Entra ID P1, and that is what lets you say "for this group, only phishing-resistant authentication will do". P1 is included in Microsoft 365 Business Premium, which is a very common licence in exactly the size of organisation I work with. Many are already paying for it and using a fraction of it. It is also worth noting that if Conditional Access has been enabled in an environment, security defaults have been switched off at the same time. The two are mutually exclusive. Microsoft blocks device code sign-in by default in new tenants through security defaults, for example, but that protection disappears the moment you move to Conditional Access. At that point you have to do it yourself. This is a typical situation where an environment is technically more advanced but, in one specific place, less protected than before. ## Five mistakes that leave gaps So far this has been about the authentication method being too weak. An equally common problem is that the right method is in use but does not cover everyone. These five are the ones I see most often. **Conditional Access policies targeted at individual accounts.** The policy was built at some point by adding users one at a time. It works on the day it is made. Six months later there are ten new people in the company, none of whom are covered by any policy. Targeting belongs on groups or directly on roles. One detail is worth knowing: Conditional Access recognises Microsoft's [built-in roles](https://learn.microsoft.com/entra/identity/conditional-access/policy-admin-phish-resistant-mfa) but not ones you have created yourself. If permissions are granted through a custom role, the protection is handled through the group that grants those permissions. That works well, but you have to remember to do it separately. **Exclusion lists have grown over the years.** Every exclusion was made for a good reason at the time. One project, one consultant, one system that would not work. Nobody has removed them, because nobody remembers them. When I go through exclusion lists during a review, I almost always find accounts that should have been gone years ago, and often accounts that no longer exist at all. **Exclusions and changes are not monitored.** The previous point follows directly from this one. If nobody checks who was added to an exclusion list and when, history accumulates. An exclusion is an acceptable thing, but only if it is documented, has an owner and is reviewed at set intervals. **Device code sign-in is left open.** This follows straight on from the previous section. Few block it explicitly, because few know it is enabled. **Basic authentication is still open for email.** This surprises people, because many believe Microsoft shut it down years ago. Most of the old protocols have been closed over the years, but SMTP AUTH survived, and its final removal has slipped to [2027 or later](https://learn.microsoft.com/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online). Microsoft is disabling it by default in stages, but in existing tenants it can be switched back on, and many have done so because a printer or some old system sends email through it. There are two traps here. First, the [per-mailbox setting overrides the organisation-level setting](https://learn.microsoft.com/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission), so "off" at the organisation level does not mean it is off. Second, an account sending with basic authentication uses no multi-factor authentication at all. Everything described above is bypassed with a single password. ## Do not let perfect block good This is the most important thing in the whole piece, and it applies far beyond authentication. The most common objection I hear is that this cannot be rolled out because it will not work for everyone. Far too often I see a situation where the protection is not deployed at all for exactly that reason. Someone has an old phone. One system does not support it. There is a shop-floor workstation with no personal devices. For these reasons the whole project is left undone, and the result is zero protected users. That is the wrong conclusion. If phishing-resistant authentication reaches 90 per cent of users, the attack surface shrinks by 90 per cent. The remaining ten per cent are handled as exclusions that are documented, justified and reviewed again in six months. You then also know exactly who is less well protected, which is valuable information in itself. Ninety per cent protected is better than zero. Written down this sounds obvious, but in practice it is one of the most common reasons good plans never reach implementation. Basic authentication for email is the best example of this, because the same per-mailbox setting that was a trap above is the solution here. If a printer and one old system need it, that is not a reason to leave it open for everyone. It is closed for everyone else and left open only for the few service accounts that genuinely use it. Those are worth restricting further so that they can connect only from specific addresses and only for what they are needed for. The result is not perfect, but the difference compared with a hundred open mailboxes is enormous. ## Where to start If you have to pick one thing, it is clear: **phishing-resistant authentication for administrator accounts.** The reasoning is simple. There are few administrators, so the rollout is fast. They are more technically prepared than others, so there are hardly any exclusions. And if an administrator account is compromised, it is no longer about one mailbox but the whole environment. Microsoft has a [ready-made guide and policy template](https://learn.microsoft.com/entra/identity/conditional-access/policy-admin-phish-resistant-mfa) for this, and it is targeted at roles, not names. Once that is done, the next step is management and finance, because they are the targets of invoice fraud. After that, everyone else in stages. ## Checklist - **Check what kind of multi-factor authentication you actually have.** App approval and text messages are not phishing-resistant. The authentication methods report shows you this. - **Enable passkeys.** It costs nothing and requires no licence changes. - **Start with administrators.** A small group, the biggest impact, the fewest exclusions. - **Target policies at groups and roles, not individual accounts.** Remember that custom roles are not recognised by Conditional Access, so protect them through the group that grants the permissions. - **Go through the exclusion lists.** Every exclusion needs an owner, a justification and a date when it will be reviewed again. - **Block device code sign-in.** First in report-only mode, then on. - **Check whether anyone is still sending email with basic authentication.** Look at both the organisation-level and the per-mailbox SMTP AUTH settings. Block it first for everyone who does not need it, because that can be done immediately. Only then start the project of replacing the remaining printers and old systems with a modern method. - **Do not skip it because it will not work for everyone.** Do it for those it does work for. Multi-factor authentication was a big leap in its time, and it is still a necessary foundation. It just no longer means the same thing as being protected. The gap between those two is exactly what the [health check](https://wolflake.fi/en/health-check) looks at most closely, because it is usually where the distance between the plan and reality is greatest.