Most organizations rolled out MFA years ago, declared victory, and never looked at it again. That’s a problem, because not all MFA is equal, and the kind most companies still rely on is the kind that gets phished.
In a talk at Cyphercon, I walked through how adversary-in-the-middle phishing kits defeat SMS codes, authenticator-app one-time passcodes, and even push notifications in real time. If you want to see it happen rather than take my word for it, the recording is also embedded on our payment fraud prevention page.
Why SMS and TOTP aren’t enough anymore
The mechanism is simple, and that’s what makes it effective. A phishing kit sits between your employee and the real login page, relaying everything back and forth in real time. Your employee types their password and their MFA code into what looks exactly like the real Microsoft or Google sign-in page, because functionally, it is; the kit is just proxying the request. The real site accepts the login, issues a session, and the kit steals that session token before your employee ever notices anything wrong.
The second factor didn’t fail. It did exactly what it was designed to do: it just authenticated the attacker’s proxy instead of stopping it. SMS, TOTP, and push-based MFA are all vulnerable to this because none of them are bound to where the login is actually happening.
Phishing-resistant authenticators and FIDO2
Phishing-resistant MFA fixes the actual weakness. FIDO2 security keys and passkeys use public-key cryptography that’s bound to the origin of the real site, so the browser or device won’t complete the authentication exchange with a fake domain, no matter how convincing it looks. There’s no code to relay, because there’s no code; the cryptographic proof simply doesn’t work against an impostor site.
Microsoft Authenticator’s number-matching feature is a reasonable interim step if FIDO2 isn’t rolled out yet (it makes push-notification fatigue attacks harder), but it doesn’t stop an adversary-in-the-middle kit the way FIDO2 does. Treat it as a stopgap, not the destination.
SSO is a licensing decision, not just a convenience
Single sign-on often gets sold as a productivity feature: fewer passwords, one login for everything. It’s also a security decision. Without SSO, MFA enforcement is only as strong as the weakest app that doesn’t go through it. With SSO, every one of those apps inherits whatever authentication policy you set at the identity provider, including the conditional access rules below. Include SSO coverage when you’re evaluating license tiers: it’s what makes everything else actually apply everywhere.
Conditional access and IP restrictions, built around risk
MFA answers “is this really them?” Conditional access answers “should this login be allowed at all, given the circumstances?” That’s a different question, and most organizations haven’t set policy around it: access works the same way for every user, every device, and every location.
A conditional access policy set worth having usually includes:
- Blocking legacy authentication protocols, which don’t support modern MFA and are a favorite target for password-spray attacks
- Requiring a compliant or managed device for access to sensitive data, not just any device with the right password
- IP and geo restrictions scoped to your known office locations or VPN ranges, with a defined process for legitimate exceptions
- Risk-based sign-in policies that flag impossible travel, leaked credentials, or unfamiliar sign-in patterns and require step-up verification
- Step-up authentication for sensitive actions, such as payment changes, admin access, or bulk data export, even for an already-authenticated session
None of this should be copied from a template. The right policy set depends on how your business actually works: a fully remote team needs different rules than one that’s always on a corporate network.
The license tier trap
Here’s where it gets expensive to get wrong in either direction. In Microsoft 365, conditional access requires Entra ID P1, which is bundled into Business Premium and E3. If you’re on a lower tier, you don’t have it, full stop. Risk-based conditional access (the “flag impossible travel” tier of policy) requires Entra ID P2, which comes with E5 or as an add-on. A lot of organizations assume they have this because they have some form of conditional access, and they don’t.
Google Workspace has the same trap under a different name. Context-aware access, Google’s version of conditional access, requires Enterprise Standard, Enterprise Plus, or a Cloud Identity Premium add-on. It’s not included in the Business tiers at all, regardless of how many seats you’re paying for.
The fix isn’t automatically “buy the more expensive tier.” Sometimes it is: you’re missing a control you assumed you had. Just as often, organizations are already paying for E5 or Enterprise-level features that were never turned on. Either way, you want to find that out from an assessment, not from a renewal invoice or an incident.
Where to start
- Audit current MFA methods across every account, especially privileged and finance-facing ones. Anything still phishable is a priority.
- Inventory license entitlements against features actually enabled. Don’t assume your tier includes conditional access. Confirm it.
- Design the conditional access policy set around your real risk and how your team actually works, not a generic baseline.
- Plan the rollout communication. Access changes generate help desk tickets if people don’t know they’re coming. A short heads-up avoids most of them.
If you’d rather have someone else run that process end to end, including the phishing-resistant MFA rollout and the license mapping, that’s exactly what our SaaS Security & Access Assessment service covers.
And if your exposure isn’t limited to your own Microsoft 365 or Google Workspace tenant, if it extends to the third-party SaaS vendors your business depends on, pair it with a vendor risk assessment to cover that side too.