Step-by-step guide to enforcing multi-factor authentication for every user in your organisation, including the edge cases most guides ignore, like service accounts, shared mailboxes, and break-glass accounts.
Microsoft's own data is unambiguous: 99.9% of compromised Microsoft accounts did not have MFA enabled. One figure. Everything else follows from it. A leaked password (whether through phishing, a data breach on a third-party site, or credential stuffing), is completely neutralised by MFA. Without it, a username and password is all an attacker needs to own your email, your files, and everything connected to your Microsoft 365 account.
Phishing is the number one attack vector against UK businesses. It is cheap to execute, difficult to detect before the click, and extraordinarily effective when there is no second factor protecting accounts. You can train your staff to spot phishing emails, and you should. But people make mistakes, particularly under time pressure. MFA is the control that stops a mistake from becoming a breach.
The good news is that enabling MFA across your entire tenant takes less time than the average team meeting. There are two ways to do it. We will walk through both.
Microsoft gives you two paths to tenant-wide MFA. The right one depends on how much control you need and what licences you have.
You cannot use both at the same time. Security Defaults and Conditional Access are mutually exclusive. If you enable Conditional Access policies, you must disable Security Defaults first, and take on the responsibility of covering everything Security Defaults was handling for you.
Security Defaults is Microsoft's "sensible baseline" switch. When enabled, it does three things: requires all users to register for MFA within 14 days, enforces MFA at sign-in (with a grace period during registration), and blocks legacy authentication protocols outright. For most firms without complex access policies, this is the right starting point.
entra.microsoft.com with a Global Administrator account.Heads-up for administrators: Tell your team what is coming before you flip the switch. A sudden MFA prompt with no context generates a wave of support tickets and, worse, suspicious users who think their account has been compromised. A quick email explaining that MFA is being rolled out, what to expect, and which app to download takes five minutes and saves you a lot of noise.
Conditional Access gives you policy-level control over who gets prompted for MFA, under what conditions, and what happens when they cannot satisfy the requirement. It is more work to configure, but it is the right tool once you need to handle exceptions, guest users, service accounts, specific devices, or location-based rules.
The first policy you should create is a simple "require MFA for all users" baseline. From there, you layer additional policies for specific scenarios.
entra.microsoft.com. Navigate to Protection > Conditional Access.Require MFA, All Users, All Apps.Do not switch straight to On. Report-only mode exists for a reason. Conditional Access policies that are misconfigured can lock users, including administrators, out of the tenant. Always test in report-only and review the Entra sign-in logs before enforcing.
This is where most guides stop, and where most real-world problems start. These four scenarios need deliberate decisions before you enable MFA.
Service accounts are non-human identities used by applications and automated processes to authenticate to Microsoft 365, think a legacy line-of-business app that connects to Exchange or SharePoint. They often cannot complete an interactive MFA prompt because there is no human sitting in front of them.
The right approach is to use Conditional Access exclusions to exempt service accounts from MFA, then compensate with these controls: assign a 25-character randomly generated password that is stored in a secrets vault, disable interactive sign-in for the account where possible, restrict the account to only the permissions it actually needs (principle of least privilege), and monitor sign-in activity with an alert for any unusual access pattern.
Do not use shared passwords for service accounts, and do not give them Global Administrator roles. Ever.
Shared mailboxes in Microsoft 365 do not have interactive sign-in enabled by default, users access them via delegation from their own licensed account, not by signing in as the mailbox. This means MFA does not apply directly to the shared mailbox itself.
What you should do: audit which user accounts have Send As or Full Access permissions to your shared mailboxes. Those user accounts should all have MFA enforced, they are the accounts that matter here. Confirm that the shared mailbox accounts themselves have sign-in blocked in Entra ID, which is the default but worth verifying explicitly.
A break-glass account is an emergency Global Administrator account that is excluded from all Conditional Access policies. Its purpose is to give you a way back into your tenant if something goes wrong, a misconfigured policy, an identity provider outage, or an administrator account being compromised and locked.
Create two break-glass accounts. Use long, randomly generated passwords (not stored in a password manager, stored physically, in a sealed envelope, in a physical safe). Exclude both accounts from all Conditional Access policies. Enable alerting so that any sign-in by either account triggers an immediate notification. Test them periodically to confirm they still work. And make sure at least two people in the organisation know where those credentials are.
Without break-glass accounts, a bad Conditional Access policy can lock your entire organisation, including every administrator, out of Microsoft 365. This is not a theoretical risk. It happens.
Legacy authentication protocols (things like basic authentication used by older versions of Outlook, IMAP, POP3, and some line-of-business applications), do not support MFA. An account with legacy authentication enabled can be accessed with just a username and password even if MFA is enforced everywhere else. This is a complete bypass.
You need to block legacy authentication. In Conditional Access, create a separate policy: target All users, set the condition Client apps to Exchange ActiveSync clients and Other clients, and set the Grant to Block access. Enable this in report-only first, some older applications will break. Identify what is using legacy auth from the sign-in logs, update or replace those applications, then enforce the block.
If you are using Security Defaults, this is handled for you automatically. It is one of the reasons Security Defaults is the right choice for most firms.
Not all MFA methods are equally secure. Here is how they rank, from most to least recommended:
Free, easy to set up, works on iOS and Android. With number matching enabled (now on by default), users must type a number shown on screen into the app, which defeats MFA fatigue attacks where an attacker spams push notifications hoping the user approves one by mistake. This is the recommended default for every user.
The highest-assurance option. A physical key that plugs into USB or taps via NFC. Cannot be phished, the key is cryptographically bound to the site it is authenticating against. Recommended for privileged accounts: administrators, finance, executive team. Has a cost (roughly £25–£50 per key) but the protection for high-value accounts justifies it.
The six-digit code that refreshes every 30 seconds. Works with any TOTP-compatible app. More secure than SMS but slightly weaker than push notifications because the code can be intercepted by a convincing phishing page in real time (real-time phishing proxies exist and are in active use). Still a significant improvement over no MFA at all.
The weakest option. SMS codes are vulnerable to SIM-swap attacks, where an attacker convinces your mobile carrier to transfer your number to a SIM they control, at which point they receive all your one-time codes. SIM-swaps are increasingly common in the UK and are particularly targeted at business owners and executives. Use SMS as a fallback only, never as a primary MFA method.
Turning on MFA stops almost every password-based attack. Attackers know it, so some now go after the login flow itself instead of the password. Device code phishing is one such method: it gets a user to approve the attacker's sign-in on a real Microsoft page, so the password and the MFA prompt both work as normal.
Enabling MFA is the start, not the end. Once it is live, build a habit of reviewing these regularly:
Client app: Other clients to confirm nothing is still using legacy auth after you block it.