MFA alone is not enough – Conditional Access for Microsoft 365 in small businesses

Why MFA alone falls short

MFA requires a second proof besides the password, for example an approval in the Microsoft Authenticator app. That stops many attacks, but not all:

• Real-time phishing: a fake sign-in page relays the password and MFA prompt to Microsoft in real time (adversary-in-the-middle). The user approves unsuspectingly, and the attacker takes over the session. In February 2026, Switzerland's National Cyber Security Centre (NCSC), a federal office since 2024, described such a phishing wave using SharePoint links that also hit Switzerland.
• Older protocols: so-called legacy authentication, such as POP, IMAP or SMTP with a username and password, does not support MFA. Anyone with the password can bypass the second factor this way. Exchange Online has already switched off basic authentication for most protocols; for SMTP sending, for example from scanners, the transition is still under way.
• Phishable methods: according to Microsoft, SMS, phone calls and app approvals remain vulnerable to real-time phishing and social engineering. Passkeys (FIDO2), Windows Hello for Business and certificate-based authentication count as phishing-resistant because the proof is bound to the genuine sign-in page and cannot be passed on.

Security defaults or Conditional Access

Security defaults are free and can only be switched on or off. They require everyone to register for MFA, ask administrators for MFA and everyone else when needed, block older protocols and protect Azure management.

Conditional Access works with if-then rules: if someone accesses Microsoft 365, then they must, for example, complete MFA or use a managed device. It requires Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium, E3 and E5. Risk-based rules that respond to suspicious sign-ins need Entra ID P2. P2 is included in E5, available on its own and, for Business Premium, part of the Microsoft Defender Suite for Business Premium add-on.

You cannot use both at once: introducing Conditional Access means switching off security defaults and replacing them straight away with your own policies. Microsoft itself says security defaults are probably not right for organisations with P1 or P2 licences.

A sensible baseline

Microsoft recommends a set of templates as the foundation for every organisation ('Secure foundation'). For a small business, this means roughly the following:

1. MFA for all users across all applications.
2. Block legacy authentication.
3. Phishing-resistant MFA for administrators using the 'Phishing-resistant MFA' authentication strength, for example passkeys on a security key or in Microsoft Authenticator, or Windows Hello for Business. Register the methods first, or you will lock yourself out.
4. Require compliant devices: allow access only from devices that Intune reports as compliant. A stolen password plus MFA is then no longer enough to sign in from someone else's device. 'Compliant device or MFA' can serve as an interim step; for personal smartphones, app protection policies are the lighter option.
5. Optionally block countries where your business never operates. This is an extra layer, not a wall: location is derived from the IP address, and attackers use VPN services too.

The templates are created in report-only mode and exclude only the person who creates them, so add exclusions for your emergency accounts. Our article on Windows Autopilot and Intune explains how devices are managed with Intune.

What Microsoft already enforces

In eligible tenants, meaning Microsoft 365 environments, Microsoft creates Microsoft-managed policies, initially in report-only mode. Depending on your licences, they include MFA for administrators accessing admin portals, MFA for all users, and blocks on legacy authentication and device code flow, a sign-in method for devices with limited input that attackers frequently abuse. If they stay in report-only mode, Microsoft switches them on no earlier than 30 days later and gives two weeks' notice. You can exclude people and switch them on or off, but not rename or delete them.

Separately, Microsoft requires MFA for administration: since October 2024, gradually, for the Azure portal, the Microsoft Entra admin center and the Intune admin center; since February 2025 for the Microsoft 365 admin center; and since October 2025 also for changes made through Azure CLI, Azure PowerShell and other tools. There is no opt-out, and emergency accounts are covered too. Both cover part of the baseline but do not replace your own planning.

Emergency access, report-only mode and logs

• Emergency accounts: following Microsoft's recommendations, set up at least two cloud-only accounts with the Global Administrator role that are not assigned to any individual. Protect them with a phishing-resistant method that differs from your normal admin accounts, such as a FIDO2 security key, exclude them from blocking policies, get notified of every sign-in and test them at least every 90 days.
• Report-only mode: every new policy runs in this mode first. It is evaluated but not enforced, and the sign-in logs show whom it would have blocked. Policies requiring compliant devices may trigger a certificate prompt on macOS, iOS and Android during this phase; exclude those platforms from the test.
• Sign-in logs: with Entra ID P1 or P2, Microsoft keeps them for 30 days, without a premium licence for seven. To look back further, forward them, for example to Azure Monitor. Before blocking anything, filter by 'Client app' to find older protocols still in use.

Tell your staff in good time

Announce changes early: what is changing, from when, what employees need to do and whom to contact if something goes wrong. Have everyone register their methods before a policy takes effect; Microsoft provides communication templates. Explain why, for instance with the SharePoint phishing wave mentioned above.

For example: a fiduciary firm with twelve employees announces the change two weeks ahead, has everyone register their methods and enables the policies for a small pilot group first. Once the logs look normal, everyone else follows.

How to get started

1. Check your starting point: licences, security defaults, existing and Microsoft-managed policies, and per-user MFA, which Microsoft no longer recommends.
2. Set up two emergency accounts with FIDO2 security keys.
3. Search the sign-in logs for older protocols and switch affected devices and services over.
4. Have all employees register their methods, and administrators additionally passkeys or Windows Hello for Business.
5. Create the baseline in report-only mode and monitor the effect for one to two weeks.
6. Inform your staff and switch the policies on step by step, starting with a pilot group.
7. Regularly review exclusions, sign-in logs and emergency accounts.

We plan and implement Conditional Access for SMEs, tailored to your licences, devices and processes. See our pages on IT security and the modern workplace. For an initial assessment of your situation, get in touch.