Just a few years ago an SMS code at sign-in was considered a good security step, and many companies adopted it in exactly that form: a password plus a six-digit code on the phone. Today banks, Microsoft and cybersecurity authorities regard SMS as the weakest form of multi-factor authentication (MFA) and recommend moving away from it.
The reason is simple: attackers have learned to bypass the SMS code in two ways that require neither large resources nor deep technical knowledge. At the same time, methods have appeared that hold up even when an employee enters the code into a fake page themselves.
In this article we explain why SMS is no longer enough, how the other MFA methods differ, how Microsoft Entra ID lets you require stronger methods only where needed, and how to switch without a chaotic Monday morning.
Two ways the SMS code is bypassed
SIM swapping
The attacker contacts the mobile operator pretending to be your employee. They have a name, a national ID number (often leaked from other websites) and a convincing story about a lost phone. The operator issues a new SIM card with the same number. From that moment every SMS code goes to the attacker, while the employee’s phone simply loses its connection, which is often noticed only after several hours. Operators have tightened this procedure, but the risk remains, especially when the employee uses a personal number that the company does not control.
Phishing proxy
An even more common method. An employee receives an e-mail with a link to a page that looks exactly like the Microsoft 365 sign-in. It is not a copy but an intermediary (a proxy): everything the employee enters, the page passes to the real Microsoft server in real time and returns the responses. The employee enters the password, and it is relayed. They receive the SMS code and enter it, and it is relayed. Microsoft issues a session token, and the attacker takes it. The employee sees that the sign-in succeeded and suspects nothing.
It is important to understand that the second method bypasses not only SMS but also app codes and simple push approval. Any method that can be relayed to an intermediary is vulnerable.
Methods from weakest to strongest
- SMS code. Vulnerable to both methods. Its only advantage is that no app is needed.
- App code (TOTP, for example Microsoft Authenticator). Protects against SIM swapping, but not against a phishing proxy, because the employee can enter the code into a fake page.
- Push with number matching. The app shows two digits on the screen where you are signing in and asks you to enter them on the phone. It protects against accidental approval, when an attacker sends dozens of requests hoping the employee will tap one, but in the proxy scenario the number is still relayed.
- FIDO2 and passkeys. A physical USB or NFC key, or a passkey stored on the phone. The cryptographic response is bound to the real address of the page, so for a fake domain the key simply will not respond. This is the only method resistant to a phishing proxy, and Microsoft calls it phishing-resistant.
In practice the realistic goal for a company is Authenticator with number matching for everyone, and FIDO2 or passkeys for those whose accounts are most valuable: administrators, executives and finance staff.
A common question is whether employees will agree to install Authenticator on a personal phone. In our experience almost everyone does, if it is explained that the app cannot see other data on the phone and that the company does not manage the phone through it. For those who refuse, a physical FIDO2 key remains: it has no battery and no software to update, and it costs less than one day of downtime.
Entra ID conditional access: strictness where it is needed
Requiring a FIDO2 key every time someone opens a Teams chat is impractical, and employees will soon start looking for ways around it. Microsoft Entra ID conditional access lets you set rules for when each method is required.
Typical rules we implement for clients:
- from a company-managed, policy-compliant computer: MFA once every few days;
- from an unknown device or another country: MFA every time, and only a phishing-resistant method;
- for administrator roles: always FIDO2 or a passkey;
- blocking legacy protocols (POP, IMAP, SMTP with a password), because they do not support MFA at all;
- blocking a risky sign-in (for example, from two countries within an hour) with a mandatory password change.
The rules are set centrally and apply to Microsoft 365, Azure and any application connected through Entra ID. We describe this on the Microsoft Entra ID service page, and the broader protection of mail and accounts in the Microsoft 365 security description.
How to roll it out without chaos
The biggest risk in an MFA rollout is not the technology but the Monday morning when 80 employees cannot sign in and all call at once. In our practice the transition goes like this:
- Inventory. Who uses SMS, who uses Authenticator, who uses nothing. Entra ID reports show this within minutes.
- Pilot. The IT team and 5 to 10 employees from different departments switch first. This is where it becomes clear which applications are incompatible.
- Registration campaign. Entra ID can show the employee a reminder at sign-in to set up Authenticator, with the option to postpone for a few days. A week is enough for most people.
- A one-page instruction, and agreed times when the helpdesk has extra staff on duty. Every employee must know whom to call when they lose their phone.
- Switching department by department, not the whole company at once. Finance goes first, because its risk is highest.
- Temporary Access Pass for new employees and for those who lost their phone, so that you do not have to bring SMS back “temporarily”.
The last step is often skipped, and “temporary” SMS stays for a year.
What to do with legacy systems
Not all systems support MFA: an old accounting application, a VPN appliance without modern protocols, a production system with a local account. The options:
- Move access behind Entra ID. Many applications can be connected through SAML or OIDC even if they have no MFA of their own, and then Entra ID performs the MFA before letting the user in.
- Put a VPN with MFA in front of the system. If the system itself is reachable only from the internal network, and the network is entered only through a VPN with a second factor, the result is practically the same. This is exactly how our ERP hosting works: the accounting system is reached through a VPN with 2FA, which is included in the service.
- Isolate. If the system fits neither option, restrict access to specific devices and log sign-ins until the system is replaced.
- Add it to the risk register. In the context of NIS2 and DORA it matters not only to implement but also to document why one system is temporarily an exception and when it will be removed.
Which of these ways out is suitable, we decide by how many people use the system and what data it holds. For an accounting system with every employee’s salary, isolation is not enough; for an internal time-tracking spreadsheet, it is enough until it is replaced.
Where to start
- In the Entra ID report, check how many accounts still use SMS as the only second factor.
- Turn off legacy protocols. It is a single change that closes a large share of attacks.
- Order FIDO2 keys for administrators and finance staff; it is a small investment compared with one successful attack.
- Create conditional access rules for a pilot group and watch for a week to see what breaks.
- If you have nobody to administer this, we carry out the transition and the ongoing maintenance as part of managed IT services, including the helpdesk when an employee has lost their phone.
