Enable Microsoft 365 2FA across your team (2026 admin guide)

The numbers are unambiguous. According to Microsoft Security, 99.9% of attacks on compromised accounts would have been blocked by 2FA. In 2025, the #1 attack vector against SMBs remains password phishing — a fraudulent email that looks like a Microsoft notification and redirects to a fake login page. Without 2FA, as soon as the employee enters their password, the attacker has access to the mailbox, Drive, Teams, and potentially other connected SSO services.

Some concrete data on the impact:

• Average cost of a BEC (Business Email Compromise): $125,000 in 2024 according to IC3 (FBI Internet Crime Complaint Center). African SMBs are actively targeted due to frequent transactions with international partners.
• Average detection delay: 72 to 200 hours. A silent attacker reads your emails, creates invisible forwarding rules, and waits for the right moment (an important transaction, a wire transfer request).
• Time to implement 2FA: 5 to 10 minutes per user with Microsoft Authenticator. For a 20-person team, that is 2 hours of admin work + 20 × 5 min of user enrolment.
• Cost of 2FA: €0 on Microsoft 365 Standard and Premium — included in the plan. Authenticator apps are free on iOS and Android.

The effort-to-protection ratio is unbeatable. There is no reasonable justification for not enabling 2FA on all M365 accounts in your organisation — including service accounts and shared accounts (which are often the most vulnerable because their passwords never change).

Note on service accounts: contact@, info@, accounting@ mailboxes used by multiple people are a preferred attack vector. Either enable 2FA with a dedicated shared device, or convert them to M365 "shared mailboxes" (no licence and no direct login — only authorised users access them via their own 2FA-protected account).

Microsoft 365 offers several strong authentication methods. Here is an honest comparison.

Microsoft Authenticator (recommended)

Mobile application (iOS and Android) that generates a 6-digit TOTP code valid for 30 seconds, or displays a push notification ("Approve this sign-in?"). This is the method recommended by Microsoft and AfricWebHosting for several reasons:

• The push notification is faster than entering an SMS code (1 click vs 6 digits)
• Works offline (TOTP mode) if the user has no connection at login time
• Resistant to SIM swapping (see below why SMS should be avoided)
• Free, available on both major mobile platforms
• Supports multiple accounts (one app for M365, Google, AWS, etc.)

Drawback: requires a smartphone. If a user doesn't have a smartphone, you'll need to use another method.

SMS / phone call (not recommended)

Microsoft sends a 6-digit code by SMS. Simple to set up, but significantly less secure:

• SIM swapping: a common attack where the attacker convinces the telecom operator to transfer the victim's phone number to a new SIM. Result: the attacker receives all 2FA SMS. This attack is documented in West and East Africa.
• Unreliable mobile network: in areas with unstable network coverage, 2FA SMS can arrive 5 to 10 minutes late — frustrating for users.
• SS7 attack: telephone SS7 protocols have known vulnerabilities that allow SMS interception. Less likely for an SMB but real for high-value targets.

Use SMS only as a backup method, never as the primary method.

FIDO2 hardware token (recommended for high-sensitivity accounts)

Physical USB/NFC key (YubiKey, Feitian) inserted in the computer or tapped against the phone. Advantages:

• Phishing-resistant (the key verifies the page URL before responding — impossible to be fooled by a fake login page)
• Works without battery, without network
• Ideal for Super Admin accounts, executive accounts, financial accounts

Drawbacks: cost (€25 to €80 per key) and risk of loss. Plan for 2 keys per user (one primary, one backup in a safe). Available on Amazon or directly from Yubico.

This procedure applies when you want to test on 1 or 2 users before deploying to the whole team, or when a user needs help configuring their Authenticator.

Step 1 — From the M365 Admin Center (default method)

1. Sign in to admin.microsoft.com with your Super Admin account.
2. Left menu → Users → Active users.
3. Click on the target user.
4. In the side panel, "Account" tab → "Multi-factor authentication".
5. Click "Manage multi-factor authentication" — this opens the legacy MFA portal (multi-factor.microsoft.com).
6. Tick the user → "Enable" → "Enable multi-factor auth".

The user will receive a message at their next sign-in asking them to set up their 2FA method. They will be guided to download Microsoft Authenticator and scan a QR code.

Step 2 — The user configures Microsoft Authenticator

1. The user downloads "Microsoft Authenticator" from the App Store or Google Play.
2. On their computer, they go to aka.ms/mfasetup and follow the steps.
3. In the app, they choose "Add account" → "Work or school account" → "Scan QR code".
4. They scan the QR code displayed on their computer.
5. They approve a test notification to validate.

Total time: 5 to 8 minutes for a user without technical difficulties.

Verification from admin

Return to the MFA portal (multi-factor.microsoft.com) → the user should now show the status "Enabled" then "Enforced" after their first successful 2FA sign-in. A status of "Enabled" but not yet "Enforced" means the user has not yet completed enrolment.

To deploy 2FA across an entire organisation, two approaches depending on your M365 plan.

Option A — Security Defaults (free, all M365 plans)

Security Defaults is a Microsoft policy that enables mandatory 2FA for all users. It is the simplest option and the one recommended for SMBs without exclusion needs.

1. M365 Admin Center → Identity (Azure AD) → Properties → Manage security defaults.
2. Enable "Enable security defaults".
3. Save.

Effect: all users have 14 days to configure their 2FA method. After 14 days, they can no longer sign in without having completed enrolment. Prepare your team in advance (see "User resistance" section).

Important limitation: Security Defaults does not allow exclusions. If you have a service account that authenticates via API without 2FA, it will be blocked. In that case, use Conditional Access (available on M365 Premium / Azure AD P1).

Option B — Conditional Access Policy (M365 Premium or Azure AD P1)

Conditional Access allows targeting 2FA at specific groups, excluding service accounts, and defining conditions (e.g. 2FA required outside the corporate network, optional internally).

1. Azure AD Admin Center → Security → Conditional Access → New policy.
2. Name: "2FA required all users".
3. Users: "All users" (exclude service accounts in the exclusion group).
4. Cloud apps: "All cloud apps".
5. Access controls → Grant → "Require multi-factor authentication".
6. Enable policy → "On".

Option C — PowerShell (bulk activation, M365 Business Standard)

If you don't have Azure AD P1 and Security Defaults is too restrictive (service accounts), you can enable 2FA in bulk via PowerShell:

# Install MSOnline module if needed
Install-Module MSOnline
Connect-MsolService

# Enable MFA for all users
$users = Get-MsolUser -All
$auth = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$auth.RelyingParty = "*"
$auth.State = "Enabled"
$auth.RememberDevicesNotIssuedBefore = (Get-Date)

foreach ($user in $users) {
  Set-MsolUser -UserPrincipalName $user.UserPrincipalName -StrongAuthenticationRequirements @($auth)
}

Replace State = "Enabled" with State = "Enforced" if you want to enforce immediately without a 14-day grace period.

The question all admins ask before enabling 2FA: "what happens if a user loses their phone?" The answer is simple: as an admin, you can reset a user's 2FA method in under 2 minutes.

Admin reset procedure (phone loss scenario)

1. Sign in to admin.microsoft.com with your Super Admin account.
2. Users → Active users → select the affected user.
3. "Account" tab → "Manage multi-factor authentication".
4. On the legacy MFA portal → tick the user → "Manage user settings".
5. Tick "Restore multi-factor authentication on all remembered devices" + "Require selected users to provide contact methods again".
6. Save. The user will need to reconfigure their Authenticator at their next sign-in.

Total time: 2 to 3 minutes. No need for a temporary password or a Microsoft support ticket.

Emergency recovery codes

Microsoft does not generate old-style 8-digit recovery codes (unlike Google). However, during Authenticator enrolment, the user can add multiple methods: for example, Authenticator as primary method + a backup phone number. Recommendation:

• During enrolment, each user configures TWO methods: Microsoft Authenticator (primary) + a phone number (backup).
• For Super Admin accounts and financial accounts, additionally configure a YubiKey as a tertiary method.

Temporary Access (Temporary Access Pass)

For urgent cases (user travelling without their phone, temporary replacement), M365 Premium offers the Temporary Access Pass (TAP): a single-use code valid for 1 to 8 hours. Configured from Azure AD → Users → the user → Authentication methods → Add a temporary access pass. The code is communicated in person or via a secure secondary channel (not by email, which may be compromised).

Resistance to change is the main obstacle to 2FA deployment in SMBs — not technical complexity. Here are four approaches that work in practice.

1. Preventive communication 2 weeks before activation

Send a clear internal email 2 weeks before forced activation. The message should answer three questions: why we're doing this (BEC compromise statistics are compelling), what it means for them concretely (5 min setup + 2 seconds per sign-in), and when it takes effect (specific date). Avoid technical jargon. Effective example wording: "From 15 May, your Microsoft 365 sign-in will require a confirmation on your phone. 5-minute setup. If you need help, contact [admin name]."

2. 15-minute group training session

A Teams or in-person meeting where you live-demonstrate installing Microsoft Authenticator and the first 2FA sign-in. Do it on a real account in front of everyone — it demystifies the process. Allow 15 minutes for Q&A. Users who would have resisted out of fear of the unknown often become positive relays after this session.

3. Explicit grace period with a clear end date

If using Security Defaults, the 14-day grace period is automatic. If using PowerShell with State = "Enabled" (not "Enforced"), users can choose to skip the setup at startup. Set a clear deadline and communicate it. Clarity on the date prevents the "I was waiting for it to go away" phenomenon. However, don't extend the period beyond 3 weeks — each extra week is a week of exposure.

4. Active support during the first week

During the first week after activation, increase admin availability: a dedicated Teams channel "MFA help" with 30-min response, a one-page internal PDF tutorial with screenshots, and if possible a 1-hour phone support session on the morning of activation day. The majority of incidents occur within the first 48 hours. After that, 2FA becomes transparent in the daily routine and calls stop almost entirely.

Enabling 2FA is not the end of security — it is the beginning of continuous monitoring. 2FA blocks 99.9% of credential stuffing attacks, but not advanced phishing (AiTM — Adversary in the Middle) where the attacker intercepts the session token after a legitimate 2FA authentication. Here is how to detect residual compromise attempts.

Microsoft Defender for Identity alerts (M365 Premium)

On Microsoft 365 Premium (formerly E3/E5), the Defender portal (security.microsoft.com) includes automatic alerts for:

• Sign-in from an unusual country: if your team is in Senegal and a sign-in comes from Romania at 3am — immediate alert.
• Multiple failed authentication attempts (brute force): 10+ sign-in attempts in 5 minutes on the same account.
• Impossible travel: sign-in from Paris at 9am and from Lagos at 10am — physically impossible.
• Token theft detection: detects some AiTM attacks via anomalies in session tokens.

Sign-in audit logs (all M365 plans)

Even without Defender Premium, sign-in audit logs are available on all M365 plans:

1. M365 Admin Center → Security → Sign-ins (or Azure AD portal → Sign-ins).
2. Filter by "Authentication failure" and "Result: Blocked".
3. Export to CSV weekly for review.

Look for suspicious patterns: a user accumulating 2FA failures on their own sign-in (someone is trying their credentials), sign-ins from IPs in unusual ranges, or sign-ins at unusual times for the user's profile.

Email alert on admin sign-in (simple and effective)

Set up an email alert on every sign-in to the Super Admin account:

1. M365 Admin Center → Security → Alert policies.
2. Create an alert "Activity: User sign-in" → Filter on admin accounts → Email notification to yourself.

If you receive an admin sign-in alert you didn't perform, it is a compromise. Immediate action: revoke all active sessions from Azure AD → the user → "Revoke sessions", then change the password and reset 2FA.

Recommended monthly review

Once a month, 15 minutes:

• Verify all active users have MFA status "Enforced" (not just "Enabled")
• Verify no deactivated account has remaining active sessions
• Review new users added in the previous month — ensure their 2FA is configured
• Review sign-in logs from unrecognised IPs

For organisations looking to go further in M365 security (CASB, Microsoft Defender for Cloud Apps, advanced DLP policies), contact AfricWebHosting — we perform M365 configuration audits on request.