Prioritising Where to Enable MFA First

You cannot protect everything at once — and you do not need to. The most effective MFA rollouts start with the accounts and systems that would cause the greatest damage if compromised. Trying to deploy MFA across every system simultaneously creates operational chaos, user resistance, and delays that leave your most critical assets unprotected for longer than necessary.

This lesson gives you a practical framework for deciding where to enable MFA first, second, and third — based on risk, not convenience.

The Risk-Based Prioritisation Principle

Not all accounts carry equal risk. An attacker who compromises a domain administrator account can take control of your entire IT environment. An attacker who compromises a standard user account can access that person’s email and files — serious, but contained. An attacker who compromises a shared social media account can post embarrassing content — reputational damage, but not an existential threat.

Your MFA rollout should follow the gradient of risk. Protect the accounts whose compromise would cause the most damage, then work outward.

Tier 1: Administrator and Privileged Accounts (Deploy Immediately)

These are the accounts that, if compromised, give an attacker the broadest and deepest access to your environment. They include:

• Global administrators in Microsoft 365 or Google Workspace — these accounts can read anyone’s email, reset any password, disable security controls, and export all data
• Domain administrators in Active Directory — these accounts control your on-premises network, group policies, and server access
• Cloud infrastructure administrators — accounts with root or admin access to AWS, Azure, or GCP environments
• Security tool administrators — accounts that manage your firewall, endpoint protection, or SIEM
• Backup system administrators — attackers specifically target backup accounts during ransomware attacks to prevent recovery

These accounts should have MFA enabled before any other accounts. Ideally, they should use phishing-resistant MFA (hardware keys or passkeys) rather than just an authenticator app. The cost of hardware keys for 5–10 admin accounts is trivial compared to the impact of a compromised admin account.

In the 2023 MGM Resorts breach, attackers gained access through a social engineering attack that ultimately led to domain administrator access. The resulting disruption cost the company over $100 million. Protecting privileged accounts is not optional.

Tier 2: High-Value Target Accounts (Deploy Within Weeks)

These are the accounts most frequently targeted by attackers because of the data they access or the authority they hold:

• C-suite executives — targeted for business email compromise (BEC), whaling, and invoice fraud. CEO and CFO accounts are particularly valuable to attackers.
• Finance team — anyone who can initiate or approve payments, access banking portals, or process invoices
• HR and people team — access to personal data, payroll information, and often the ability to create or modify employee records
• Legal and compliance — access to sensitive contracts, regulatory filings, and privileged communications
• IT helpdesk staff — often have password reset capabilities and elevated access, making them a stepping stone for attackers

These users should have MFA enabled as the next priority after administrators. An authenticator app is the minimum acceptable standard; hardware keys should be considered for the CFO and CEO.

Tier 3: All Remaining Staff (Deploy Within One Month)

Every employee with a login account represents a potential entry point for an attacker. Even a “standard” account compromise gives attackers access to internal emails, shared files, contact lists, and the ability to send convincing phishing emails from a trusted internal address.

Once Tier 1 and Tier 2 accounts are protected, extend MFA to all remaining staff. This is typically the largest group and requires the most change management effort, but it should not be delayed indefinitely.

Tier 4: External, Guest, and Service Accounts (Plan and Schedule)

Many organisations forget about accounts that sit outside the normal employee lifecycle:

• Guest and external collaborator accounts — contractors, partners, and vendors who access your systems
• Service accounts — automated accounts used for integrations, backups, and scheduled tasks
• Shared or generic accounts — accounts like “reception@” or “info@” used by multiple people

These accounts are often overlooked but frequently exploited. Service accounts are particularly dangerous because they often have elevated permissions and no MFA. Plan to address these in your rollout, but do not let them delay Tiers 1–3.

Beyond Accounts: Which Systems First?

In addition to prioritising by account type, consider which systems to enforce MFA on first:

• Email — the single most important system to protect. Email is the gateway to password resets, sensitive communications, and business email compromise. Protect email first.
• Cloud identity provider (Azure AD / Google Workspace admin) — the system that controls all other access
• VPN and remote access — any system that provides access to your internal network from outside
• Financial systems — banking portals, accounting software, payment platforms
• Customer data systems — CRM platforms, databases with personal information

Why This Matters

Organisations that try to enforce MFA everywhere at once often face pushback, exceptions pile up, and the project stalls — leaving critical accounts unprotected while leadership debates the rollout plan. A tiered approach means your highest-risk accounts are protected within days, not months.

Attackers are rational — they target the easiest path to the most valuable data. Your priority sequence should mirror the attacker’s priority sequence. If your domain admin accounts and CEO inbox are protected with phishing-resistant MFA, you have eliminated the most damaging attack paths regardless of whether every single account is protected yet.

What to Do Now

• Create a list of all administrator and privileged accounts across your environment (Microsoft 365, Google Workspace, cloud infrastructure, network devices)
• Enable MFA on those accounts this week — do not wait for a broader rollout plan
• Identify your Tier 2 accounts (executives, finance, HR) and schedule MFA enablement within two weeks
• Plan a communication and support programme for the all-staff rollout (Tier 3)
• Document any accounts that cannot have MFA enabled immediately and record the reason and risk acceptance

Evidence to Collect

• A prioritised list of accounts and systems for MFA rollout with target dates
• Confirmation that all Tier 1 (administrator) accounts have MFA enabled, with the method documented
• A register of any MFA exceptions, including who approved them and when they will be reviewed
• A rollout timeline showing planned completion dates for each tier

Common Mistakes

• Protecting standard users before administrators. This is backwards. Admin accounts should be protected first because they carry the greatest risk if compromised, regardless of how few of them exist.
• Waiting for a “complete plan” before starting. Enable MFA on admin accounts immediately. You do not need a board-approved strategy to protect your most privileged accounts — you need to do it now.
• Forgetting about service accounts and shared accounts. These are frequently exploited because they often have elevated permissions and no MFA. Include them in your planning even if they are addressed later.
• Treating email as just another application. Email is the most critical system to protect with MFA. It is the gateway to password resets for other systems, sensitive business communications, and business email compromise attacks. Prioritise it above all other applications.

---

Knowledge Check

---