The Control You Already Rolled Out
Most Luxembourg businesses of any size finished this project years ago. Multi-factor authentication went on Microsoft 365, the insurer asked about it and was satisfied, the auditor ticked it, and identity quietly moved off the risk register. For a while that was a reasonable place to leave it.
Then someone in finance received a message about a compliance review, signed in through a page that looked exactly like the company login, approved the prompt on their phone because they were the one signing in, and nothing appeared to go wrong. Two weeks later a supplier payment went to the wrong account, or a mailbox started sending internal spear-phishing, and the investigation found that the account had been accessed continuously since that afternoon without a single further authentication prompt.
The MFA worked exactly as designed. That is the problem worth understanding.
Attackers Stopped Guessing and Started Relaying
The technique is adversary-in-the-middle phishing, and it is mundane rather than exotic. The victim lands on a page controlled by the attacker, but instead of collecting a password into a database, that page acts as a transparent proxy to the genuine Microsoft login. Every keystroke is relayed to the real service and every response is relayed back. The user sees the authentic sign-in screen, because it is the authentic sign-in screen. They type their password, which is forwarded. They are challenged for MFA, which is a genuine challenge. They approve it on their phone, or type the six digits, and Microsoft — correctly, having verified everything it was asked to verify — issues a session token.
The attacker takes that token. From that point the second factor is irrelevant, because the token is proof that authentication already happened. Mail, files, Teams and any application behind the same sign-on are available without a further prompt, often for as long as the token remains valid and sometimes considerably longer if the attacker registers their own authentication method while they are inside.
Microsoft's threat intelligence team published a detailed write-up of one such campaign in May. Between 14 and 16 April 2026 it reached more than 35,000 users across over 13,000 organisations in 26 countries, using a fake internal "code of conduct review" as the lure. The chain ran through a PDF attachment, an attacker-controlled domain, a Cloudflare CAPTCHA presented as session validation, a second image-selection check, and finally a "Sign in with Microsoft" button that proxied the authentication session and captured the tokens. Professional services accounted for eleven per cent of those targeted, alongside healthcare, financial services and technology.
Read that chain again and notice what is not in it. There is no malware, no exploit, no vulnerability in the customer's environment. Two CAPTCHAs are there to filter out automated analysis and, incidentally, to reassure the human. It is a well-built web application and a plausible pretext, and there is a functioning market renting this capability to people who could not build it themselves.
Why the Prompt on Your Phone Does Not Help
Push approvals and one-time codes share a design assumption: that the person being asked to approve knows which site they are approving for. They do not carry that information. A six-digit code is equally valid to the real service and to a proxy standing in front of it, and a push notification asks "are you signing in?" — to which the honest answer, in this scenario, is yes.
Number matching helps against a different attack, the one where an attacker with a stolen password spams prompts at three in the morning until someone taps accept. It does not help here, because the user is actively signing in and will happily read the number off the attacker's page.
This Is Not an Argument for Turning MFA Off
It is worth keeping the scale straight, because the security industry has an unfortunate habit of announcing that a control is dead the moment someone finds a way past it. Microsoft's Digital Defense Report 2025 records ninety-seven per cent of identity attacks as password spray — bulk, unsophisticated credential guessing against exposed usernames — from a base of some 38 million identity risk detections analysed on an average day. Ordinary MFA stops essentially all of that, and an organisation without it is not facing a sophisticated adversary-in-the-middle problem. It is facing a much simpler and more likely one.
What has changed is the top end. AI has made the pretext cheap and the writing good: Microsoft reports AI-enabled phishing campaigns achieving click-through rates as high as fifty-four per cent, against roughly twelve per cent for traditional campaigns. Grammar and formatting are no longer the tell, which means the advice we have all been giving users for a decade — look for the mistakes — has quietly stopped working. We wrote about how this plays out locally in the attack patterns we see across the Greater Region, and about what the evidence says about awareness training. The short version: training raises the floor and will not save you here. This one has to be fixed in the authentication layer.
The distinction that matters: a phishable factor proves that someone completed a challenge. A phishing-resistant factor proves that they completed it on the real domain. Everything else is detail.
Microsoft Has Set the Deadline For You
If you run Microsoft 365, this decision has largely been taken out of your hands, on a published timetable. In July, Microsoft confirmed that passkeys become the default authentication method in Entra ID, with these dates:
- 1 September 2026 — passkey auto-enablement and registration nudges begin for users currently on SMS or voice.
- 18 September 2026 — pricing, commercial terms and supported telecom provider lists are published for organisations that need to keep SMS.
- 30 October 2026 — administrators can select and configure a third-party telecom provider.
- 1 February 2027 — Microsoft stops delivering SMS and voice authentication itself, and passkey registration prompts become mandatory. Microsoft's wording is unambiguous: "There will be no opt-out option."
Two clarifications, because both get misread. First, this is retirement of Microsoft-provided SMS and voice delivery, not a ban on SMS: organisations that genuinely need it can contract a telecom partner through the Microsoft Security Store and pay that partner directly. Second, these dates apply to Entra ID in the public cloud only; other cloud environments follow a separate timeline.
The practical consequence is that doing nothing is now a choice with a date attached. Your users will start being prompted to register a passkey in a few days, whether or not you have decided what your passkey strategy is, briefed your service desk, or worked out what happens to the warehouse supervisor who does not have a work phone.
A Migration That Does Not Fall Over in Week Two
Passkeys and FIDO2 security keys work because the credential is cryptographically bound to the domain that issued it. Presented with a lookalike page, the authenticator does not warn the user — it simply refuses, because the domain does not match. There is no decision for a human to get wrong, which is the entire point.
Getting there in an organisation of fifty to five hundred people is not technically difficult. It fails on the things nobody planned for.
1. Find out what your users actually use today
Pull the registered authentication methods per user before you change anything. In most tenants the result is uncomfortable: a long tail on SMS, a handful of accounts with no second factor at all through some historical exclusion, and service accounts nobody can name an owner for. This inventory is the migration plan; everything else follows from it.
2. Decide device-bound or synced before you enrol anyone
Synced passkeys live in a credential manager and follow the user across their devices, which is far easier to deploy and to recover. Device-bound passkeys — a hardware security key, or Windows Hello for Business tied to a specific machine — give you a stronger assurance about where the credential physically is. Most organisations should use both: hardware keys for administrators and anyone who can move money, synced passkeys for everyone else. Decide this first, because reversing it means re-enrolling people.
3. Start with the accounts an attacker actually wants
Global administrators, finance and payments, the executive assistants with delegated mailbox access, HR, and anyone who can change bank details in a supplier record. That list is short enough to complete in a fortnight and covers most of the realistic loss scenarios.
4. Solve the awkward fifteen per cent first, not last
Shared workstations on a production floor. Staff with no company phone and an understandable objection to using their own. Contractors. Field engineers on borrowed devices. Every migration stalls here, and it stalls at the worst moment — after you have enforced the policy and the exceptions become urgent tickets. Cost the hardware keys for these people at the start; they are inexpensive next to a week of service desk firefighting.
5. Fix the service desk before you fix the login
When the front door becomes unpickable, the attack moves to the person who can reset it. A phone call from a plausible colleague who has "lost their phone on the way to a client" is now the shortest path into your tenant, and it is being used. Write down what proof of identity a reset requires, make it something an outsider cannot obtain — a callback to the number in the HR record, or verification by the requester's line manager — and make it non-negotiable regardless of how senior or how stressed the caller sounds. A service desk that has rehearsed this once behaves very differently from one that has only read a policy; this is exactly the kind of thing our security training work exists to drill.
6. Enforce it with Conditional Access, not with encouragement
Registration campaigns get you adoption. They do not get you assurance, because a user with both a passkey and an SMS fallback will use whichever is convenient, and so will anyone phishing them. Use a Conditional Access policy requiring phishing-resistant authentication strength, scoped to your priority group first and widened as coverage grows. Until a population is fully enrolled, tighten sign-in frequency for it so a stolen token has a shorter useful life.
7. Close the back doors
Legacy authentication protocols, app passwords, unmanaged service principals, and the break-glass accounts you set up in 2019 and have not looked at since. An attacker will find the one authentication path you left phishable, and it is usually the one that predates whoever is running IT now. Break-glass accounts still need to exist — give them hardware keys, store them properly, and alert on any use.
What to Watch While You Are Halfway Through
The migration window is the risky part, because you will have a mixed population and a lot of legitimate authentication changes generating noise. A small number of alerts are worth having in place before you start: registration of a new authentication method on an account that already had one, sign-ins from an unfamiliar location shortly after a successful MFA, new inbox forwarding or hiding rules, and OAuth consent grants to applications nobody has approved. Those four cover the standard post-token-theft playbook, and they are the difference between finding out in an hour and finding out when the invoice does not arrive. If nobody is watching that telemetry outside office hours, that is a gap worth closing on its own terms — it is the core of what our security operations work is for.
The Compliance Angle, Briefly
For entities in scope of Luxembourg's NIS2 law, the risk-management measures in Article 21 name multi-factor authentication explicitly. The text does not currently distinguish between phishable and phishing-resistant methods — but supervisory expectations follow the threat landscape, and an organisation that can demonstrate phishing-resistant authentication on its privileged accounts is in a materially better position than one explaining why a session-token theft counted as adequate security. If you are still working out where you stand, our NIS2 compliance support covers the scoping question first.
Where to Start
If you want one action out of this article: pull the list of who in your organisation is still relying on SMS or a push prompt, and look at how many of those accounts can approve a payment or reset a password. That number is your actual exposure, and it takes an afternoon to produce.
If the list is longer than you expected, or the awkward cases are the ones you keep deferring, we are happy to walk through it with you — inventory, a realistic sequence, and the two or three Conditional Access policies that do most of the work. Get in touch and we will tell you plainly how big the job is before you commit to it.
