Disclaimer

The information in this article is provided for general awareness and informational purposes only. It does not constitute professional consulting advice, legal guidance, or a technical recommendation tailored to any specific organization. Readers are encouraged to consult qualified security professionals before making security-related decisions. The author assumes no liability for actions taken based on the content of this article.

Why SMS Authentication Is No Longer Secure

The Teams invite had no subject line. Just: "Can you jump on now?"

I joined to find forty people already on the call — executives, IT leads, security staff, department heads, coordinators. The kind of crowd that only assembles when something has already gone wrong. Two or three conversations were happening at once. Someone was talking over someone else. Questions were stacking up before the last one got answered.

I stayed quiet and listened.

Within a few minutes, the picture came into focus. One user account had been compromised. That part was almost routine. What wasn't routine was what happened next.

The attacker had used that account to send a mass internal email — looked like it came from a trusted colleague, reasonable subject line, nothing obviously suspicious. In the time it took the security team to catch it, hundreds of accounts were compromised. From there, the blast radius extended outward: partner organizations, supply chain vendors, downstream systems that trusted anything coming from a known internal address.

What followed was weeks of incident response, system lockdowns, and a forensic scope review that grew every day. The real damage came later: emergency security spending, a multi-year remediation roadmap, and a work environment that got measurably harder to operate while the fixes rolled out.

I've seen variations of this incident across industries and geographies. And almost every time, the root cause is the same: an authentication method that was convenient, familiar, and completely inadequate. SMS.

What NIST Actually Says

NIST SP 800-63B classifies SMS OTP as a restricted authenticator. Not banned outright — but any organization that keeps using it must formally acknowledge the risk and offer stronger alternatives.

CISA goes further. Its 2024 Mobile Communications Best Practice Guidance recommends that high-risk users — anyone with privileged access, anyone in sensitive roles — move away from SMS and voice-call MFA entirely.

When I share this in security briefings, the reaction is usually the same: quiet surprise. "We use this as our standard." That's the problem. Standard doesn't mean safe.

How the Attacks Work

The AiTM Proxy: Real-Time Credential Relay

Tycoon 2FA — a phishing-as-a-service platform — accounted for 62% of the phishing traffic Microsoft blocked in the first half of 2025. You don't need hacking skills to use it. You need a subscription.

Here's the mechanism: the attacker stands up a reverse proxy. When the victim connects to the fake site, the proxy simultaneously connects to the real site and relays everything in real time.

Victim → [Attacker's reverse proxy] → Real site
                  ↓
      Password + SMS OTP forwarded instantly
      Authenticated session cookie copied

The user checks their phone, types in the six-digit code, and thinks they've logged in. The attacker already has an authenticated session. The password didn't even matter.

This is called an AiTM (Adversary-in-the-Middle) attack. In 2024, this category of attack grew 146%.

Source: Microsoft Digital Defense Report 2024

MFA Fatigue: Exploiting Approval

Once an attacker has your password, push-notification MFA is just an inconvenience — not a barrier. The attacker triggers approval requests back to back, dozens of them. Eventually the user, tired of the alerts, taps Approve to make it stop.

Microsoft Authenticator's number matching requirement largely neutralizes this. The user has to type the number shown on screen into the app — and the number the attacker sees is different. The transaction fails. This is one configuration change that actually matters.

SIM Swap: No Technical Skill Required

The attacker calls your carrier and asks to transfer your number to a new SIM. All they need is enough personal information to get through verification — data that's frequently available from prior breaches or social media.

Once the transfer completes, every SMS sent to your number goes to the attacker. SMS-based fraud increased 40% between 2024 and 2025.

Source: FTC Consumer Sentinel Network Data Book 2024

AI Voice Cloning: The Social Engineering Upgrade

AI-generated voice now convincingly mimics bank and enterprise voice lines. The script is simple: "We've detected suspicious activity on your account. Can you read me the verification code we just sent?" The attacker triggered that SMS themselves, moments before calling. When the user reads the code, the login completes on the attacker's end.

What's Actually Blocking Organizations

The technical attacks are serious. But in my experience, the harder problems are organizational.

Without executive sponsorship, this migration doesn't happen. IT and security teams may know exactly what needs to change — but without the organizational authority to enforce it, the project stalls or never starts. I've seen the right technical plan sit in a slide deck for two years because no one above the IT director was willing to make it a priority.

End-user resistance is real too. "I have MFA, I use a strong password" is a surprisingly common response from employees. Abstract statistics don't change that attitude. What does? A case study from a company in the same industry, followed by a live demo. When someone sees phishing-resistant login in action — one tap, no code, done — the conversation shifts.

And then there's the capacity problem. IT and security teams are running operations. Learning new products requires time they don't have. This isn't ignorance; it's prioritization pressure. The gap between "we know we should upgrade" and "we've upgraded" stays open.

The VIP Paradox

Here's something I see consistently: the users who need the most protection are often running the weakest authentication.

C-level executives. Nobody pushes back on them. If a VP says "I'm not changing how I log in," the conversation ends there. The security team knows it's a risk. They document it. The risk stays open.

The counterintuitive thing is that passwordless authentication is actually easier to use than SMS. Windows Hello for Business or a passkey means one quick biometric scan — faster than unlocking a phone, finding the authenticator app, and waiting for a six-digit code to arrive. When I demo this for skeptical executives, the reaction is almost always the same: "That's it? That's more secure?"

The demo closes more deals than the threat briefing does.

In successful rollouts, the pilot group is usually IT staff or a handful of VIP users. Once they've experienced it, organizational momentum builds naturally.

Authentication Security Tiers

Resistance to attacks varies dramatically across authentication methods. "We have MFA" covers everything from barely-protected to genuinely strong — and most organizations don't know which one they have.

Tier 1: Password Only

Strength: Very Weak

Exposed to credential stuffing, brute force, and data breach replays. In 2024, compromised passwords were a factor in over 80% of analyzed data breaches.

Attack resistance: Phishing vulnerable / AiTM vulnerable / No device binding

Source: Verizon DBIR 2024

Tier 2: Password + SMS OTP

Strength: Weak

The most common MFA deployment — and vulnerable to AiTM proxy, SIM swap, and voice phishing. NIST SP 800-63B classifies this as restricted.

Attack resistance: AiTM vulnerable / SIM swap vulnerable / Phishing vulnerable / No device binding

Tier 3: Password + Push Notification (No Number Matching)

Strength: Medium-Low

Better than SMS — SIM swap doesn't apply. But without number matching enabled, MFA fatigue attacks still work. The session cookie is still exposed in an AiTM scenario.

Attack resistance: AiTM partial / SIM swap resistant / MFA fatigue vulnerable / No device binding

Tier 4: Password + Push Notification (Number Matching Enabled)

Strength: Medium-Strong

The user must confirm a number shown on screen inside the app. The number the attacker sees is different, breaking the fatigue attack. AiTM risk isn't fully eliminated because the password is still in the equation.

Attack resistance: AiTM partial / MFA fatigue resistant / SIM swap resistant / No device binding

Tier 5: Passwordless, Microsoft Authenticator

Strength: Strong

No password means no credential stuffing, no brute force. More resistant to AiTM — but without full cryptographic server binding, it doesn't reach FIDO2-level protection.

Attack resistance: AiTM resistant (not fully) / SIM swap resistant / Phishing resistant / MFA fatigue resistant

Tier 6: Windows Hello for Business

Strength: Very Strong

Authentication is tied to an asymmetric key pair. Biometrics (face, fingerprint) or a PIN unlock the private key stored in the device's TPM chip — that key never leaves the hardware. There's no way to replay these credentials from another machine.

Attack resistance: AiTM resistant / Phishing resistant / SIM swap resistant / Device-bound: YES / TPM-protected: YES

Source: Microsoft Windows Hello for Business

Tier 7: Passkey (Platform) and FIDO2 Physical Security Key

Strength: Strongest

The top of the phishing-resistant stack. Domain binding means a fake site cannot complete authentication — the cryptographic check fails before any credentials are exchanged. Built on FIDO Alliance's WebAuthn standard.

Attack resistance: AiTM resistant / Phishing resistant / SIM swap resistant / MFA fatigue: N/A / Device-bound: YES / TPM-protected: YES

Source: FIDO Alliance Passkeys / Google Passkeys / Microsoft Passkey Support

Why It's Actually Different: The Technical Foundation

The TPM Chip

The TPM (Trusted Platform Module) is a dedicated security microcontroller embedded in the motherboard. It generates cryptographic keys, stores them, and performs operations — but it never exports the key itself.

Windows 11's TPM 2.0 requirement isn't arbitrary. Windows Hello for Business and passkeys deliver their strongest security guarantees only with hardware-level protection. Even if an attacker completely owns the OS or the disk, they cannot extract the private key from the TPM. Which means they cannot log in as you from another device.

Public/Private Key Pairs

Passwords and SMS codes share a fundamental design problem: they're shared secrets. Both sides know the same thing. If an attacker gets the secret, they're in.

FIDO2 and passkeys use asymmetric cryptography instead:

Registration:
  Device         →  Generates key pair (private + public)
  Private key    →  Stored in TPM/Secure Enclave, NEVER LEAVES
  Public key     →  Registered with the server

Sign-in:
  1. Server  →  Sends a random nonce (one-time challenge)
  2. Device  →  Biometric/PIN activates the private key
  3. Device  →  Signs the nonce, sends the signature
  4. Server  →  Verifies signature against the registered public key

The server never holds a secret. Even if the server's database is breached, only the public key is exposed — and you can't log in with a public key. An attacker intercepting the exchange sees a one-time signed value that can't be replayed or forged.

Domain Binding

During registration, the credential is cryptographically bound to a specific domain. At sign-in, the device checks: "Am I actually talking to accounts.microsoft.com?"

Real site:  accounts.microsoft.com  →  Authentication succeeds
Fake site:  accounts-microsoft.com  →  Device rejects, transaction aborted

No matter how convincing the proxy, it cannot pass this check.

A Note on TOTP

TOTP (time-based OTP) — the kind used by Google Authenticator and Microsoft Authenticator in code mode — generates a time-stamped code in 30-second windows. The fundamental issue: the server holds the same shared secret. A server-side breach exposes all future codes. And in an AiTM scenario, 30 seconds is more than enough time to relay a valid code in real time.

Passwordless Transition: Recovery and Lost Device Scenarios

Why a PIN Is More Secure Than You Think

On the surface, a four-digit PIN sounds weaker than a twelve-character password. It isn't.

A password is sent over the network to a server — it can be intercepted or brute-forced remotely. A PIN only ever exists on the device. It never leaves. It's verified locally against hardware. Too many wrong attempts and the device locks or wipes. There's no remote attack surface.

The PIN is a local authenticator protected by hardware lockout. It does its job.

Lost Device Recovery

Register multiple devices: Users can register passkeys or Windows Hello on more than one device. Lose one, log in with the other.

Temporary Access Pass (TAP): Microsoft Entra ID's Temporary Access Pass lets an IT admin issue time-limited access while the user re-enrolls their primary authenticator. It's the bridge between losing a device and getting back to full passwordless.

FIDO2 key redundancy: For critical accounts, register two physical security keys and store the backup somewhere secure.

Cross-Device Sign-In: QR + Bluetooth

On a desktop that doesn't have a passkey registered, a phone can broker authentication:

1. Desktop browser displays a QR code
2. Phone scans the QR code
3. Bluetooth verifies physical proximity
4. Phone authenticates with biometric/PIN
5. Desktop session opens

The Bluetooth proximity check is a real security control. An attacker who intercepts the QR code still can't complete the handshake unless the phone is physically nearby.

From Classic Defense-in-Depth to Modern Zero Trust

Stronger authentication is necessary — but not sufficient on its own. Even a phishing-resistant login method leaves gaps if the context around it isn't evaluated.

Zero Trust flips the old assumption. "You're on the network, therefore you're trusted" is out. Every access request is evaluated individually: who you are, what device you're on, where you're coming from, what you're trying to reach.

In Microsoft Entra ID, this plays out through Conditional Access policies.

Conditional Access: Login With Context

Classic access control was binary: credentials correct → access granted. Conditional Access makes the decision dynamic. At the moment of a login attempt, the policy evaluates a set of signals simultaneously and decides what to do.

The signals: identity (user, group, role), device compliance state, location and IP, the application being accessed, session risk score, sign-in risk score. Based on the combination, the policy allows, blocks, or challenges.

Concrete example: an employee tries to access a high-sensitivity internal app from a personal laptop, outside the office, on an unmanaged device. The policy evaluates: device noncompliant, location unknown, app sensitivity high. Result: access denied, or limited to a read-only browser session.

That decision happens before any work happens on the attacker's side.

Intune Compliance: The Device as a Security Control

Device compliance can be a condition for access. Intune compliance policies define what "healthy" looks like: BitLocker encryption active, OS patched, antivirus running, screen lock enforced, no jailbreak or root detected.

Devices that meet the criteria are marked compliant. Conditional Access policies can require compliance for access to critical applications. Even with valid credentials, an attacker coming from a noncompliant environment — which is almost every attacker — gets blocked.

Hybrid Entra Join: The Bridge for Legacy Environments

Not every organization can cut over to cloud identity in one move. For organizations with years of Active Directory infrastructure, the transition has to be phased. Hybrid Entra Join lets devices be enrolled in both on-premises Active Directory and Entra ID simultaneously.

This means Conditional Access and Intune compliance policies can apply to those devices today, without waiting for a complete migration. It's the path that lets organizations get modern security controls into place without breaking what's already working.

Layered Combinations

The power of Conditional Access isn't any single rule — it's the combinations:

For standard enterprise access, pairing an Intune-compliant device with Windows Hello for Business gives you a strong, user-friendly baseline.

For high-sensitivity systems or privileged accounts, layering known-network IP ranges with a FIDO2 physical key locks access down to both location and hardware.

Unmanaged devices from unknown locations are blocked regardless of how correct the credentials are.

PAW: A Separate Tier for Privileged Accounts

Global Admins, Domain Admins, and equivalent privileged accounts are the highest-value targets in any organization. Compromising one of these doesn't just breach a user — it can undo every security control in the environment.

The recommended approach is a PAW (Privileged Access Workstation): a hardened, isolated machine used exclusively for administrative work. It doesn't handle email, browsing, or documents — that stays on a separate device. Internet access is restricted or absent. It operates under a separate Entra ID identity, requires a FIDO2 physical key for authentication, and runs under maximally restrictive Conditional Access policies.

The investment is real. So is the cost of having one of these accounts taken over.

Critical Warning: Don't Leave the Back Door Open

Adding a passkey to an account doesn't make it phishing-resistant if the password reset flow still routes through SMS. An attacker won't bother trying to bypass the passkey — they'll just hit "Forgot password," complete SMS verification, reset the credentials, and walk in.

The weakest link in the chain determines the actual security level. When deploying strong authentication, audit every recovery and reset path with the same scrutiny you apply to the primary login. Every one.

The Real Work Isn't Technical

"How long does the technical setup take?" That's usually the first question I get.

The answer surprises people. Windows Hello for Business with cloud trust can be staged incrementally. Entra ID policy configuration, passkey enrollment, Conditional Access integration — technically, it's manageable. Organizations with decent IT capacity can get a pilot running in weeks.

The hard part is everything else.

Changing how people authenticate requires changing behavior at scale. That means executive sponsorship, change management, user training, and often a communications strategy. It also means dealing with the legacy tail: old applications still using basic auth, NTLM, or pre-OAuth protocols. You can roll out passkeys on all new apps while an old internal tool stays accessible via basic authentication — and that old tool becomes the attack surface.

Migration on paper doesn't close the exposure. Every legacy authentication path that stays open is a gap.

I tell teams: this is a change management project with a technical component. Not the other way around.

Why SMS Authentication Is No Longer Secure: A Phishing-Resistant Authentication Guide