Multi-Factor Authentication for Everyone, Administrators First

Published October 23, 2026 · Last reviewed October 23, 2026

Not all MFA is equal

CISA’s fact sheet on phishing-resistant MFA lists the common methods from strongest to weakest. Using that ranking:

• Strongest: phishing-resistant methods, namely FIDO/WebAuthn (security keys and passkeys) and public-key certificate based sign-in. They tie the sign-in to the real website, so a look-alike page cannot capture a usable credential.
• Middle: app-based prompts that ask you to match a number shown on the screen, which blunts “push bombing” where an attacker spams approval requests.
• Weaker: one-time codes typed from an app, and codes sent by text message or voice call. These can be relayed through a fake sign-in page, or intercepted through SIM swapping. They are still far better than a password alone.

Who goes first, and how

Roll out in this order: administrators, then people who approve payments or change bank details, then people with access to customer or employee records, then everyone. Enforce it by policy rather than asking people to opt in.

Action

Enforce MFA for all administrator roles first. Profile A In the Microsoft Entra admin center, use Conditional Access (available on plans that include it) to require MFA for administrator roles. On small tenants without it, switch on security defaults, which require MFA registration for all users. Profile B In the Google Admin console, open Security › Authentication › 2-step verification and enforce it for the administrator organisational unit. Menu names vary by plan and release.

Why it helps

An administrator login is the most valuable thing an attacker can steal: it can read all mail, change payment details and delete backups.

Verification

Try signing in to the admin portal from a private browser window as an administrator. You should be asked for a second factor on every new sign-in.

Fallback if delayed

If policy tools are not available, have each administrator set up a security key or authenticator app and check the registration list weekly.

Action

Offer the strongest method you can support, and remove the weakest as you go. Enable passkeys or security keys in the authentication methods settings of your identity provider, require them for administrators and finance, and phase out text-message codes where you can. Microsoft calls the policy tool “authentication strengths”; Google lets you require security keys for a group.

Why it helps

A phishing page can relay a typed code or an approval, but it cannot use a passkey on the wrong website.

Verification

In the authentication methods report, confirm how many admins and finance users have registered a phishing-resistant method.

Fallback if delayed

Enable number-matching prompts in the authenticator app so approvals need a deliberate action.

Action

Block legacy authentication. Older protocols, such as basic-auth mail connections used by old apps and scanners, cannot ask for MFA. Block them with a Conditional Access policy or, on smaller plans, through security defaults. Identify what still uses them before you switch them off. Profile B In Google Workspace, review which third-party and older apps can reach Google data in the Admin console’s app-access and API controls, and remove those you do not recognise. Menu names vary by edition.

Why it helps

An attacker will use whichever door does not ask for a second factor.

Verification

Review the sign-in logs for legacy protocol sign-ins before and after. After the change there should be none.

Fallback if delayed

Where an old device must keep working, restrict it to a single known IP address and a dedicated low-privilege account.

Action

Create two emergency access accounts and protect registration. Microsoft’s guidance is to keep two or more cloud-only emergency administrator accounts, protected by a phishing-resistant method such as a passkey (FIDO2) security key stored safely, excluded from Conditional Access policies that could block them, and monitored with an alert on every sign-in. Also require MFA registration to happen from a trusted place, so an attacker with a stolen password cannot enrol their own device.

Why it helps

Without an emergency route you can lock yourselves out when the MFA service has a fault. Without protected registration, a stolen password can be turned into a trusted second factor.

Verification

Sign in once to each emergency account per quarter, using its key, and write the date down; confirm that an alert fires whenever it is used.

Fallback if delayed

Keep a second administrator with a hardware key stored in the safe, and follow the current Microsoft Learn page for the exact setup, which changes.

Common failure mode

MFA is usually “turned on” but not enforced: users can skip it, executives are exempted, shared mailboxes and service accounts are left outside the policy, legacy sign-ins stay open, and text-message codes remain as a fallback for everyone. An attacker needs only the weakest remaining path, so audit the exceptions as carefully as the rule.

How it works

MFA works by requiring two or more different kinds of proof: something you know, something you have, something you are. If a password leaks, the attacker still lacks the second proof. Phishing-resistant methods go one step further by binding the proof to the true website address, so a copy of the sign-in page gets nothing it can reuse.

Enforcement works through the identity provider’s policy engine. The policy decides who must satisfy which method for which application. Exceptions are the weak point, which is why the verification step is to look at the report of who is not covered. A session that is already signed in can still be stolen, which the session and token control guide addresses.

Worked example

This is a hypothetical example with invented figures. A 30-person property management firm has MFA “available” in Microsoft 365, and an administrator reviews the registration report. Several users never registered, two executives were exempted years ago and an old scanner still sends mail over a legacy connection.

The administrator enforces MFA for admin roles and finance, requires registration from the office network, moves the executives into policy, replaces the scanner’s connection with a modern one and blocks legacy authentication. Two emergency accounts are created, each with its own security key stored in the safe. The coverage report now shows no one outside the policy except the emergency accounts.