MFA Isn't a Checkbox: Why Most Small Businesses Are Doing It Wrong

Multi-factor authentication is one of the most widely recommended security controls in existence. Microsoft's own data shows that MFA blocks over 99.9% of account compromise attacks. The FBI, CISA, and virtually every cybersecurity framework in use today lists MFA as a foundational requirement.

And yet, in 2026, a significant share of small business breaches still involve accounts where MFA was either not enforced or implemented in a way that an attacker bypassed without much effort.

The problem isn't that businesses haven't heard of MFA. Most have turned something on. The problem is that "something" and "effective MFA" are not the same thing. There's a meaningful spectrum between checking the box and actually closing the door—and knowing where your business falls on that spectrum is the difference between protected and exposed.

What MFA Actually Does (and Doesn't Do)

Multi-factor authentication requires a user to present two or more verification factors before gaining access to an account. The classic factors are:

Something you know — a password
Something you have — a phone, a hardware key
Something you are — a fingerprint, face scan

The logic is straightforward: even if an attacker steals your password, they can't access your account without the second factor. That's the 99.9% statistic—most credential-based attacks rely entirely on compromised passwords, and MFA stops them cold.

What MFA does not do is protect against every attack method equally. The protection is only as strong as the second factor being used. And some second factors are dramatically weaker than others.

The MFA Hierarchy: From Weakest to Strongest

Not all MFA is created equal. Here's how the common methods stack up against real-world attacks:

SMS Text Codes (Weakest)

A six-digit code sent to your phone via text message is better than nothing—but it has two significant vulnerabilities in 2026.

SIM swapping: An attacker calls your mobile carrier, impersonates you, and convinces a representative to transfer your phone number to a SIM card they control. Once they have your number, every SMS code you would receive goes to them. This attack is well-documented and actively used against business accounts. The carrier social engineering required to pull it off is not sophisticated—it's been executed against accounts with standard carrier security settings.

Interception: SS7 protocol vulnerabilities (the underlying infrastructure of the global phone network) allow sophisticated attackers to intercept SMS messages in transit. This is a more advanced attack, but it exists and has been used.

For personal accounts and low-risk systems, SMS MFA is an acceptable baseline. For Microsoft 365, banking, payroll, or any system with financial or sensitive data access—it is not sufficient.

Authenticator App Push Notifications (Better, but Vulnerable to Bombing)

Authenticator apps like Microsoft Authenticator or Google Authenticator generate time-based one-time passwords (TOTP) or send push notifications to your phone requesting approval. This is a significant improvement over SMS—there's no phone number to SIM-swap, and the codes are generated locally rather than transmitted over a network.

The vulnerability here is MFA fatigue, also called push bombing.

How MFA fatigue works: An attacker who already has your password initiates a login attempt, which triggers an MFA push notification to your phone. They do this repeatedly—10, 20, 30 times—at odd hours, often while you're in a meeting, just waking up, or trying to focus on something else. Eventually, a user taps "Approve" just to make the notifications stop. The attacker is in.

This is not theoretical. Push bombing has been used successfully against major enterprises and is increasingly deployed against small business targets. Uber's 2022 breach began with an MFA fatigue attack. Scattered Spider, one of the most active ransomware groups of the past two years, uses it routinely.

Authenticator App with Number Matching (Strong)

Microsoft Authenticator's number matching feature defeats push bombing by requiring the user to type a two-digit number displayed on the login screen into the authenticator app to approve the request. A push notification alone no longer grants access—the user must see the screen, read the number, and type it in.

This breaks the push bombing attack. An attacker can still spam push notifications, but none of them will succeed because the user has to interact with the actual login screen to provide the matching number—something they won't see if they're not the one initiating the login.

Number matching should be the minimum standard for any Microsoft 365 environment in 2026. If you're using Microsoft Authenticator with standard push approvals and haven't enabled number matching, that is a gap worth closing today.

FIDO2 Hardware Security Keys (Strongest)

FIDO2 hardware keys—YubiKey, Google Titan, Feitian, and others—are physical devices that plug into a USB port or tap via NFC. They use public-key cryptography to authenticate to a specific website or application, which provides two properties that no other MFA method can match:

Phishing resistance: A FIDO2 key is cryptographically bound to the specific domain it was registered with. If an attacker tricks you into entering your credentials on a fake login page designed to look like your Microsoft 365 portal, your FIDO2 key will refuse to authenticate—because the domain doesn't match. This defeats phishing-based credential theft entirely, even against sophisticated lookalike sites.

No network transmission: There are no codes, no push notifications, no SMS messages—nothing that can be intercepted, forwarded, or fatigue-bombed. The key generates a cryptographic response that only works for the specific login request being made.

FIDO2 keys are the strongest MFA method available. They are appropriate for your highest-privilege accounts: Microsoft 365 global administrators, domain administrators, financial system administrators, and anyone with the ability to authorize large transactions or access sensitive client data.

For regular employee accounts, authenticator app with number matching is the practical standard. FIDO2 for everyone is cost-prohibitive and creates friction that reduces adoption—but for the accounts that matter most, it is worth the investment.

The Accounts That Matter Most

MFA is not equally important across every account. The risk profile varies significantly depending on what the compromised account can access. Here's how to think about prioritization:

Tier 1: Protect These First

Microsoft 365 Global Administrator — can access and modify every account in your organization, reset any user's password, disable MFA for any user, and exfiltrate everything in your tenant. This account should have FIDO2 keys, should never be used for daily work, and ideally should be a dedicated break-glass account used only for administrative tasks.
Domain Administrator (if running on-premise Active Directory) — same risk profile as M365 Global Admin for your local network.
Backup administrator — an account that can delete or modify your backups is as dangerous as one that can encrypt your production data.
Financial accounts — any account with access to banking, payroll (ADP, Gusto, Paychex), or wire transfer authorization.

Tier 2: Every Business Account

Every Microsoft 365 user, every employee email account, and every SaaS application account should have MFA enforced—not optional. An attacker who compromises a regular employee account can use it to pivot to other systems, monitor email for BEC opportunities, or launch internal phishing attacks against your own staff.

Tier 3: Don't Forget These

VPN access — credentials stolen for a VPN without MFA give an attacker direct network access
Remote desktop or remote access tools — RDP exposed without MFA is one of the most common ransomware entry points
Line-of-business software — your practice management system, your CRM, your accounting platform
Personal email accounts used for business — these fall outside your control but represent a meaningful risk if employees forward business communications to personal accounts

Microsoft Entra Conditional Access: Enforcing MFA the Right Way

Turning MFA on in Microsoft 365 is not the same as enforcing it. The difference matters.

When MFA is enabled but not enforced through Conditional Access policies, users can bypass or disable it under certain conditions—including simply not completing enrollment. Conditional Access is the policy layer that says: no access to business resources without completing MFA, period.

A properly configured Conditional Access policy in Microsoft Entra ID (formerly Azure AD) can:

Require MFA for every login, regardless of network location or device
Block legacy authentication protocols (SMTP, IMAP, POP3) that don't support MFA and are frequently exploited
Require compliant devices — only managed, enrolled devices can access business data
Block access from high-risk countries or flag logins from impossible travel scenarios (a user logging in from Charlotte and then from Eastern Europe 30 minutes later)
Require MFA re-enrollment after a defined period so that former employees' MFA registrations expire

The most important Conditional Access policies to implement for a small business Microsoft 365 environment:

Require MFA for all users — no exceptions, no excluded accounts
Block legacy authentication — this single policy eliminates a category of attacks that bypass MFA entirely
Require MFA for admin roles — apply the highest friction specifically to privileged accounts
Sign-in risk policy — Microsoft's AI evaluates sign-in signals and can automatically require step-up authentication when a login looks anomalous

If your Microsoft 365 environment doesn't have Conditional Access policies configured, your MFA deployment has gaps regardless of how many users have the authenticator app installed.

Common MFA Implementation Mistakes

After helping businesses throughout the Charlotte area audit and improve their MFA posture, these are the gaps we find most often:

Excluded accounts. A blanket MFA policy with a list of excluded accounts—"because it was too complicated to set up for them"—is a list of viable attack targets. Every exclusion is a potential breach point.

No block on legacy authentication. Older protocols like SMTP AUTH and basic authentication don't support MFA. If they're enabled in your tenant, an attacker with a compromised password can authenticate through those protocols without ever triggering an MFA prompt. This is one of the most common ways MFA is bypassed.

MFA only on Microsoft 365, nothing else. Microsoft 365 is covered but VPN, RDP, and SaaS applications are not. An attacker blocked from email will try the next entry point.

Standard push notifications without number matching. As described above, this leaves you open to push bombing. Enabling number matching in Microsoft Authenticator is a configuration change, not a new deployment.

No MFA for shared or service accounts. Shared email accounts (info@, billing@, support@) and service accounts used for integrations are often excluded from MFA because "nobody logs in interactively." Attackers do.

Enrollment without enforcement. MFA is available and some users have enrolled, but it's not required. Users who haven't enrolled can still log in. The policy has no teeth.

How eSmith IT Implements MFA for Charlotte Small Businesses

At eSmith IT, MFA deployment is a structured process—not a setting we toggle and walk away from. For Microsoft 365 environments, our approach includes:

Conditional Access policy design — documented policies covering all users, all devices, legacy authentication blocking, and risk-based step-up authentication
Number matching enforcement in Microsoft Authenticator for all standard users
FIDO2 hardware key deployment for administrator accounts and high-privilege users
Legacy authentication audit and block — identifying and disabling all legacy protocol access in the tenant
MFA enrollment campaign — working with your team to complete enrollment for every user before enforcement is activated, with clear communication so there are no login disruptions on enforcement day
Ongoing monitoring — reviewing sign-in logs for MFA bypass attempts, failed authentications, and anomalous login patterns

We serve small and mid-sized businesses throughout Charlotte, Huntersville, Mooresville, Cornelius, Concord, and Gastonia. If your current MFA deployment is based on SMS codes, standard push notifications without number matching, or an incomplete Conditional Access policy—or if you're not certain what's actually configured in your tenant—contact eSmith IT for a free Microsoft 365 security assessment.

We'll review your current identity and access configuration, identify the specific gaps between what you have and what you need, and give you a clear picture of your actual exposure.

Turning MFA on is a start. Making it work is a different project.