Subscribe to the Non-Human & AI Identity Journal

What should IAM teams do if regulators reject SMS OTP for authentication?

Treat the mandate as a control redesign trigger, not a channel swap. Replace SMS OTP with phishing-resistant authentication, revisit recovery workflows, and update policy to distinguish between routine access and sensitive actions. The real work is aligning authentication strength with transaction risk and proving that weaker factors are no longer in the critical path.

Why This Matters for Security Teams

When regulators reject SMS OTP, the issue is not the text message itself. It is that SMS is a weak, interceptable factor that often cannot meet current expectations for phishing resistance and transaction assurance. Security teams need to treat the ruling as a signal to redesign authentication around risk, recovery, and step-up controls, not as a narrow channel replacement.

This matters because authentication failures tend to appear in the same places as identity abuse: account recovery, help desk reset flows, and high-risk transactions. NHI Management Group research shows how weak identity hygiene compounds these failures, with 79% of organisations reporting secrets leaks and 80% of identity breaches involving compromised non-human identities in the broader identity stack, which is why control quality matters beyond the login screen. See the Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the NIST Cybersecurity Framework 2.0 for the broader governance lens.

In practice, many security teams encounter fraud, takeover attempts, or regulatory findings only after weak recovery paths have already become the easiest way around stronger authentication.

How It Works in Practice

The practical response is to separate ordinary sign-in from sensitive action approval. Routine access can be supported with phishing-resistant methods such as passkeys, FIDO2 security keys, or certificate-backed authenticators, while higher-risk actions should require step-up checks tied to device posture, session risk, and transaction context. That is consistent with current guidance from NIST SP 800-53 Rev. 5 Security and Privacy Controls, which emphasises strong authentication and risk-based enforcement.

Teams should also rebuild recovery workflows. If SMS was the default recovery channel, it often becomes the soft underbelly of the whole program. Better designs use help desk verification, verified device binding, out-of-band approval, or supervised recovery for privileged accounts. Recovery should be logged, reviewed, and governed as a high-risk control path rather than treated as administrative convenience.

For non-human identities and agentic workloads, the same lesson applies in a different form. A static secret or standing credential is easy to abuse once a workflow is compromised, which is why NHI guidance increasingly favours ephemeral credentials and explicit lifecycle controls. The 2024 Non-Human Identity Security Report found that 59.8% of organisations value dynamic ephemeral credentials, which supports a broader move away from long-lived access artefacts.

  • Use phishing-resistant authentication for primary login where possible.
  • Require step-up verification for password reset, payout, admin, or data export actions.
  • Remove SMS from recovery unless there is a documented compensating control.
  • Bind authentication decisions to device, user, and transaction risk.

These controls tend to break down when legacy apps, shared accounts, or outsourced service desks force manual exceptions that bypass the policy engine.

Common Variations and Edge Cases

Tighter authentication often increases friction and support cost, so organisations must balance user experience against fraud loss, regulatory exposure, and help desk complexity. There is no universal standard for replacement timing, but current guidance suggests prioritising high-risk populations first, especially administrators, finance users, and privileged operators.

One common edge case is customers or employees who cannot use modern authenticators because of device constraints, accessibility needs, or constrained environments. In those cases, teams should prefer verified recovery alternatives over reverting to SMS as the default. Another edge case is service accounts and automation: human MFA policy does not solve workload identity risk, so those flows should use strong workload credentials, short-lived tokens, and lifecycle governance instead of interactive authentication assumptions.

NHI Management Group’s research shows why this matters operationally: only 5.7% of organisations have full visibility into their service accounts, and 71% of NHIs are not rotated within recommended time frames, which means weak recovery or exception handling can spread beyond human login controls. See Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs for lifecycle and audit implications.

In regulated environments, the hardest part is not replacing SMS, but proving that every exception is bounded, reviewed, and no longer the weakest link in the authentication chain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AA-01 Covers stronger authentication and identity assurance after SMS is removed.
NIST SP 800-63 AAL2 Defines authenticated access strength expectations beyond weak OTP channels.
NIST Zero Trust (SP 800-207) ID Identity-driven access decisions are needed when authentication must be risk-aware.
OWASP Non-Human Identity Top 10 NHI-03 Weak secrets and recovery paths often undermine both human and non-human authentication.
NIST AI RMF Risk-based authentication aligns with governance, mapping, and monitoring functions.

Map each login and recovery path to the required assurance level and use phishing-resistant factors where needed.