Microsoft 365 MFA Setup: Security Defaults or Conditional Access

There are three ways to turn on MFA in Microsoft 365, and choosing the wrong one is the most common mistake we see. Security Defaults is the simplest and suits very small businesses with no unusual requirements. Conditional Access gives you control over when people are prompted and is the right answer for most businesses with more than a handful of staff. Per-user MFA is the legacy method and should not be used for new deployments. Microsoft's own MFA mandate for admin access is now fully enforced, and the postponement window closed in July 2026, so this is no longer optional for anyone holding an admin role.

Key facts

• Microsoft enforces MFA on admin portal sign-ins. Enforcement began in October 2024 for the Azure portal, Entra admin center and Intune admin center, and reached full enforcement for the Microsoft 365 admin center on 9 February 2026.
• A second phase from 1 October 2025 extended enforcement to Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure as code tools and REST API endpoints for create, update and delete operations.
• Postponements were available but expired in July 2026. There are no further extensions.
• The mandate covers interactive admin sign-ins. It does not by itself require MFA for your ordinary staff accounts, so leaving those uncovered is a decision you are making, not a default Microsoft has handled.
• Service principals and managed identities are excluded from the mandate. User accounts being used as service accounts are not, and should be migrated to workload identities.
• Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium and most enterprise plans.
• Microsoft-provided SMS and voice authentication retires in Entra ID on 1 February 2027, so any method policy that still permits them needs revisiting now.

Security Defaults, Conditional Access or per-user MFA?

Security Defaults is a single switch that enables MFA for everyone, blocks legacy authentication and requires MFA for administrators. It is free, it takes minutes, and for a business of five people with no complications it is a reasonable place to be. Its limitation is that it is all or nothing: you cannot exclude a break-glass account, you cannot vary the rules by location or device, and you cannot exempt a system that will break.

Conditional Access is the mechanism to use once you have staff, devices and edge cases. It lets you require MFA based on circumstances, so a sign-in from a managed device on a known network passes quietly while an unfamiliar location or an unmanaged device triggers a prompt. That distinction is what keeps a rollout from being reversed after a fortnight of complaints. It needs Entra ID P1, which most SMEs already own through Business Premium without realising it.

Per-user MFA is the original per-account toggle. It still exists, it does not understand context, it prompts constantly, and it interacts badly with Conditional Access if both are configured. Do not build on it. If you inherited a tenant using it, migrating to Conditional Access is worth doing properly rather than leaving both running.

What order should you do this in?

Administrators first, and get them fully working before touching anyone else. That is where Microsoft's mandate bites, and it is where a lockout does the most damage. While you are there, create a dedicated emergency access account, exclude it from your Conditional Access policies, protect it with a long unique credential held securely, and record who can reach it. Every guide recommends this and most small businesses skip it, then discover the problem when a policy misfires.

Then check what will break before you enforce anything. Legacy authentication protocols allow sign-ins that bypass MFA entirely, so they need to be closed, but closing them can break old mail clients, multifunction printers that scan to email, and line of business applications with hard-coded credentials. Find those first. The other category is user accounts being used as service accounts, which should move to workload identities rather than being permanently exempted.

Then roll out to staff in groups rather than all at once, using report-only mode on your Conditional Access policies to see what would have happened before it happens. Register a second authentication method per person during enrolment, because a single method means a lost phone becomes an administrator problem and the shortcut people reach for is disabling the control.

Which authentication methods should you allow?

Push approval through the Microsoft Authenticator app with number matching is the sensible baseline. It is resistant to the accidental approval problem, where a user taps yes to a prompt they did not trigger, because they have to enter a number shown on the sign-in screen.

Turn off SMS, and note that Microsoft is making this decision for you. Microsoft-provided SMS and voice authentication retires in Microsoft Entra ID on 1 February 2027, and from 1 September 2026 users on those methods are automatically enabled for passkeys and prompted to register one at sign-in. Text message codes were already the weakest common method, vulnerable to SIM swapping and trivially relayed by a phishing kit that captures the code and uses it inside its validity window. Anyone still on SMS or voice needs moving now rather than in January 2027. See the SMS and voice MFA retirement for the dates and what to move people to.

For administrators and anyone handling payments, consider phishing-resistant methods. Passkeys and hardware security keys remove the code from the process entirely, so there is nothing for a fake login page to capture. Coverage is good in Microsoft 365 and worth enabling for high-value accounts even if you do not extend it to everyone. See passkeys versus passwords for how that works.

What gets missed?

Three things, consistently. Legacy authentication left open, which makes the whole policy bypassable. Systems outside Microsoft 365 with their own separate MFA settings, including banking portals, accounting software and payroll, none of which are covered by anything you configure in Entra. And exceptions that were meant to be temporary and became permanent because nobody scheduled a review.

The fourth is evidence. Once MFA is deployed, you will be asked about it, by an insurer at renewal or by a larger customer running a security questionnaire. What they want is specifics: which accounts are covered, which methods are permitted, how exceptions are handled and who reviews them. Producing that after the fact is harder than recording it as you go. See multi-factor authentication for how we run this as a managed control, and what is multi-factor authentication for the underlying explanation.

Frequently asked questions

Is Security Defaults good enough for a small business?

For a very small team with no legacy systems, no need for exceptions and no emergency access account to protect, it is a defensible starting point and far better than nothing. It becomes limiting quickly. You cannot exclude a break-glass account, cannot vary requirements by device or location, and cannot exempt a system that will break, so any complication forces you off it. If you hold Microsoft 365 Business Premium you already have Entra ID P1 and therefore Conditional Access, so there is usually no cost reason to stay on Security Defaults.

Is MFA now mandatory for all Microsoft 365 users?

Not for all users. Microsoft's mandate applies to interactive sign-ins to admin portals and tooling, which means anyone holding an admin role, including a business owner who only handles billing. Ordinary staff accounts are not covered by the mandate itself. That said, staff mailboxes are exactly what credential-stuffing and phishing target, so leaving them without MFA is a choice rather than a gap Microsoft has closed for you. Most insurers now ask about staff coverage specifically.

What do we do about service accounts and shared mailboxes?

Move user accounts being used as service accounts to workload identities, which are service principals or managed identities, since those are excluded from the MFA mandate by design and are the supported way to run automation. Shared mailboxes do not need their own sign-in when accessed correctly through delegated permissions, so staff reach them with their own MFA-protected account. A shared mailbox with its own password that several people know is a problem worth fixing regardless of MFA.

Should we still be using per-user MFA?

No, not for a new deployment. Per-user MFA is the legacy per-account toggle. It has no awareness of context so it prompts people constantly, which drives approval fatigue, and it conflicts with Conditional Access if both are configured at once. If you have inherited a tenant running per-user MFA, plan a migration to Conditional Access rather than layering one on top of the other, and confirm the per-user settings are cleared afterwards.

If you are not sure whether your tenant is on Security Defaults, per-user MFA or Conditional Access, or whether legacy authentication is still open, that is worth establishing before an insurer asks. We can audit where you stand and get it configured properly. Request a callback and we will take a look.