“We have MFA” gets treated as a single answer, checked once and forgotten. It shouldn’t be. SMS codes, authenticator app codes, and hardware security keys are all called MFA, and they stop very different attacks. A firm running SMS-based codes on every account has technically satisfied “MFA required.” A real, determined attacker still has a way through. Here’s what each tier actually defends against.
Key takeaways
- SMS-based MFA can be defeated through SIM swapping, without the attacker ever touching the account holder’s actual phone.
- A real-time phishing attack can defeat both SMS codes and authenticator app codes by relaying them to the real site within seconds.
- Hardware security keys and passkeys are the only widely available MFA type built to resist that real-time relay attack specifically.
- Cyber insurers increasingly ask which specific type of MFA a firm has deployed, going well beyond a yes or no.
- MFA needs to be enforced everywhere client data lives, including accounts that don’t have it turned on yet.
Table of Contents
Why “we have MFA” doesn’t answer the real question
MFA means a second proof of identity beyond a password. It doesn’t specify what that second proof actually is. The gap between the options is larger than the shared label suggests.
A text message code, a code from an authenticator app, and a physical security key all satisfy a checkbox that says “MFA enabled.” None of them satisfy the same threat model. Treating them as interchangeable is how a firm ends up technically compliant while still exposed to the exact attack MFA was supposed to stop.
The three tiers, and what each one actually stops
SMS codes stop a stolen password used on its own. Authenticator app codes stop most automated credential-stuffing attacks. Hardware security keys and passkeys stop those attacks plus the real-time phishing relay that gets past the first two.
| MFA type | What it actually stops | Where it falls short |
|---|---|---|
| SMS code | A stolen password used on its own | Defeated by SIM swapping, no phishing resistance |
| Authenticator app code | Stolen password, SIM swapping | Defeated by real-time phishing relay |
| Hardware key or passkey | All of the above, plus real-time relay | Requires a physical device or platform support |
SIM swapping means an attacker convinces a mobile carrier to move a phone number onto a device they control. The attacker then receives SMS codes meant for someone else, without ever touching that person’s actual phone. An authenticator app closes that specific gap, since its code generates locally on the device rather than traveling over the phone network.
The attack that gets past SMS and authenticator apps alike
A real-time phishing relay works differently than a normal phishing email. It presents a fake login page, captures the password and MFA code as the victim types them, and passes both to the real site within seconds.
Neither SMS nor a standard authenticator app was built to resist this specific attack. Both produce a code that works for anyone who enters it in time, including an attacker relaying it live. Hardware security keys and passkeys close this gap through a different mechanism. The device itself verifies it’s talking to the real site before it responds. A relayed request from a fake page gets rejected automatically instead of passed through.
Why insurers and auditors are starting to ask which kind
Cyber insurance applications increasingly ask which specific type of MFA a firm has deployed. SMS-based codes are treated as a weaker answer than authenticator apps or hardware keys, and some carriers ask about phishing-resistant MFA by name.
That mirrors what a WISP built to IRS Publication 4557 and the FTC Safeguards Rule already expects. MFA belongs on every account that touches client data, enforced consistently rather than turned on for some accounts and skipped for others. VeritSpace enforces MFA on every user login by default. VeritGuard extends that same enforcement across Microsoft 365, Google Workspace, and VPN connections. The answer to which type of MFA a firm uses shouldn’t depend on which account someone happened to set up first.
Talk to us about closing the gaps in your firm’s MFA coverage →
