Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk Who should own the decision to replace SMS…
Governance, Ownership & Risk

Who should own the decision to replace SMS OTP in an enterprise?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated July 10, 2026 Domain: Governance, Ownership & Risk

Ownership should sit across identity, fraud, product, and risk or compliance teams because the change affects assurance, customer experience, operational cost, and regulatory exposure. When the decision is isolated inside authentication engineering, teams usually underweight business impact and over-rely on technical completion.

Why This Matters for Security Teams

Replacing SMS OTP is not just an authentication change. It shifts assurance level, user friction, fraud exposure, support burden, and sometimes regulatory posture. Ownership therefore belongs with the teams that can weigh all of those effects together, not only with engineers implementing a new factor. NIST guidance on control ownership and authorization boundaries in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames identity controls as governance decisions, not just technical settings.

The business risk is easy to underestimate because SMS OTP looks familiar and low cost. In practice, it is often retained until a phishing, SIM-swap, account takeover, or recovery-flow abuse incident forces a review. NHIMG research shows why broad ownership matters: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 79% of organisations have experienced secrets leaks with tangible damage. The same governance mistake shows up in customer identity decisions when authentication is treated as a narrow implementation detail instead of a cross-functional risk decision, as seen in the Ultimate Guide to NHIs — Why NHI Security Matters Now. In practice, many security teams encounter the need to replace SMS OTP only after fraud losses or recovery abuse have already exposed the business case.

How It Works in Practice

The most effective decision model is a shared one with clear accountability. Identity security should own the authentication architecture and assurance model, fraud should own abuse scenarios and attack economics, product should own customer experience and conversion impact, and risk or compliance should own policy, regulatory exposure, and exception handling. That structure turns the question from “what factor should we deploy” into “what assurance outcome does the enterprise need for each use case?”

Practically, the team that proposes the replacement should define:

  • Which journeys are high-risk enough to require stronger phishing-resistant authentication
  • Which user populations can support passkeys, authenticator apps, or device-bound credentials
  • Which fallback and recovery paths need separate controls so SMS does not quietly remain the weakest link
  • How success will be measured across fraud rate, login success, support tickets, and abandonment

That approach aligns with the control mindset in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access control, identification, and authentication decisions are part of the broader security program. It also fits the NHIMG view of identity risk as a lifecycle problem, not a point fix. The Schneider Electric credentials breach illustrates how credential-related failures can ripple beyond a single login flow into broader operational and trust impact. Best practice is evolving, but current guidance suggests the replacement decision should be made in a governance forum with documented risk acceptance, not by a lone implementation team. These controls tend to break down when product teams override security requirements during launch pressure because fallback and recovery flows remain under-specified.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance speed against assurance. That tradeoff becomes most visible in customer support-heavy environments, regulated industries, and businesses with mixed user populations, where one replacement pattern will not fit all.

Some enterprises can remove SMS OTP for workforce users quickly but must keep it temporarily for certain customer segments, legacy devices, or jurisdictions where adoption of stronger factors is uneven. In those cases, current guidance suggests phasing the change by risk tier instead of forcing a single global deadline. Risk and compliance should document any interim exception, while fraud monitors whether the fallback path becomes the new attack target.

There is no universal standard for who must sign off on the final decision, but the decision should not sit solely in authentication engineering. Product leaders can help prevent conversion damage, security leaders can define assurance thresholds, and risk leaders can decide when residual SMS exposure is acceptable. The important edge case is account recovery: many organisations replace SMS at sign-in but leave it in recovery flows, where attackers often find the weakest path. That split ownership is where failures persist longest, especially when legacy identity stacks and customer service scripts are not updated together.

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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA-01Authentication decisions must be governed as an enterprise risk, not a single engineering task.
NIST SP 800-63AAL2SMS OTP replacement is driven by assurance level and authenticator strength requirements.
OWASP Non-Human Identity Top 10NHI-01Credential governance lessons from NHI management apply to OTP and recovery-path controls.
CSA MAESTROShared ownership mirrors cross-functional governance for identity and access decisions.
NIST AI RMFRisk governance principles support structured decision-making for authentication changes.

Set enterprise authentication assurance targets and require cross-functional approval before replacing SMS OTP.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org