Why do SMS OTPs and push-based MFA often fall short in finance, healthcare, and government?

Why This Matters for Security Teams

SMS OTP and push approval still appear in many regulated environments because they are easy to deploy and easy for users to understand. The problem is that convenience is not the same as assurance. Finance, healthcare, and government systems need authentication that holds up under fraud pressure, phishing, SIM swap attacks, device compromise, and social engineering. Current guidance from NIST SP 800-63 Digital Identity Guidelines treats restricted authenticators and phishing resistance as material differences, not implementation details.

For NHI Management Group, this is also an identity governance issue, not just a user login issue. The same organisational pattern that leaves secrets, API keys, and service accounts weakly governed often leaves human MFA assumptions unchallenged. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility is a warning sign for identity control maturity across the board. That is why the Ultimate Guide to NHIs — Regulatory and Audit Perspectives matters here: auditors increasingly care whether the control actually resists account takeover, not whether it exists on paper.

In practice, many security teams encounter MFA weakness only after a fraudulent login has already been accepted, rather than through intentional testing of the attack path.

How It Works in Practice

In high-risk sectors, stronger authentication should be treated as a layered control, not a single challenge step. SMS OTP depends on the phone network, so it can fail when an attacker redirects messages or takes over a number. Push-based MFA adds a second channel, but if approval is too easy, attackers can exploit fatigue, prompt bombing, or routine user behaviour. The better pattern is to move toward phishing-resistant methods and contextual decisioning, aligned to NIST Cybersecurity Framework 2.0 and identity guidance that emphasises stronger proof at authentication time.

Practically, teams should look for methods that bind the login to a device or cryptographic key, not just a one-time code. That means preferring passkeys, hardware-backed authenticators, certificate-based device trust, or federation flows that reduce replay risk. It also means checking whether the authentication event is tied to location, device posture, risk signals, and session context before access is granted. NHIMG’s Top 10 NHI Issues consistently shows that weak credential handling is usually part of a broader governance problem, not an isolated login flaw. For regulated organisations, the real objective is to prove that the account holder is authentic, the device is trustworthy, and the session is not being hijacked in real time.

• Use phishing-resistant MFA for privileged and regulated workflows first.
• Reduce reliance on SMS to recovery only, not primary access.
• Require step-up verification for high-value transactions and sensitive records.
• Review risk signals continuously during the session, not only at login.

These controls tend to break down when legacy applications cannot support modern authenticators and the organisation leaves fallback paths wide open.

Common Variations and Edge Cases

Tighter authentication often increases user friction and deployment cost, requiring organisations to balance fraud reduction against operational continuity. There is no universal standard for every workflow yet, especially in environments that mix citizen-facing services, clinicians on shared devices, and field staff with poor connectivity. In those cases, current guidance suggests using stronger MFA for privileged actions and sensitive data access while keeping carefully governed fallback methods for exceptional recovery events.

Healthcare and government often face another edge case: shared workstations, managed tablets, and emergency access scenarios. Here, the issue is not simply whether MFA is “strong,” but whether it remains usable when staff cannot receive an SMS or approve a push promptly. That is where authentication design must account for device identity, session duration, and break-glass procedures. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant because the same lifecycle discipline needed for secrets and service accounts also applies to fallback credentials and recovery paths. If recovery is easier than primary access, attackers will aim for recovery.

In regulated environments with high fraud exposure, SMS OTP and push MFA should be treated as transitional controls, not the end state.

Related resources from NHI Mgmt Group

• Why does basic MFA often fall short for CMMC compliance?
• Why do push-based MFA and SMS codes fail against social engineering campaigns?
• Why do proxy-based CASBs often fall short in modern SaaS and GenAI environments?
• Why do attackers often check model availability before trying to generate content?