Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk Who is accountable when regulators require stronger authentication…
Governance, Ownership & Risk

Who is accountable when regulators require stronger authentication than SMS OTP?

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

IAM, fraud, digital product, and risk leaders share accountability because the control spans customer experience and financial loss prevention. In regulated environments, the organisation must show that weaker channels were reduced, monitored, or retired in line with policy and supervisory expectations.

Why This Matters for Security Teams

When regulators require stronger authentication than SMS OTP, the question is not only which control to deploy. It is who owns the decision to remove a weaker channel, accept the customer impact, and prove the change was enforced across products, fraud tooling, and support operations. The accountability problem is usually organisational, not technical, because SMS replacement cuts across risk appetite, legal obligations, and user journey design.

Security teams often discover that “good enough” authentication was tolerated for convenience until a supervisory exam, incident, or fraud spike made the gap visible. NIST’s Cybersecurity Framework 2.0 treats governance and risk ownership as core responsibilities, while NHIMG’s Regulatory and Audit Perspectives show that weak identity controls become audit findings when lifecycle evidence is missing. In practice, many security teams encounter the accountability debate only after a regulator has already asked why SMS was still acceptable.

How It Works in Practice

Accountability for stronger authentication should be assigned by control ownership, not by who has the most technical expertise. IAM typically owns the authentication standard and implementation pattern, fraud teams own step-up and abuse monitoring, digital product owns customer impact and rollout sequencing, and risk or compliance owns policy interpretation and evidence. That shared model is necessary because regulators usually care about both the control itself and the decision trail behind it.

Operationally, the organisation needs three things. First, a policy that states when SMS OTP is disallowed, deprecated, or only allowed as a fallback. Second, a migration plan that ties each channel to a date, exception owner, and compensating control. Third, audit-ready evidence showing the weaker channel was reduced, monitored, or retired. NIST SP 800-53 Rev. 5 supports this kind of control assignment through explicit governance and access control expectations, while NHIMG’s Lifecycle Processes for Managing NHIs is useful because the same lifecycle discipline applies to authentication methods and secrets that support them.

  • Define one accountable executive for the policy decision.
  • Assign one technical owner for implementation and rollback.
  • Assign one control owner for exceptions, metrics, and audit evidence.
  • Track adoption, failure rates, and exception expiry in a single register.

This becomes concrete when fraud and support systems still depend on legacy SMS flows, because partial retirement creates residual risk that is hard to measure and harder to defend.

Common Variations and Edge Cases

Tighter authentication often increases friction, so organisations have to balance fraud reduction against conversion loss, support volume, and accessibility obligations. That tradeoff is especially important where regulators permit risk-based exceptions or phased rollout rather than immediate removal.

There is no universal standard for this yet, but current guidance suggests that exceptions should be time-bound, approved, and reviewed at the same level as the policy that created them. A regulated business may keep SMS OTP only for recovery, low-risk access, or transitional cohorts if stronger factors are unavailable, but it should not leave the channel in place by default. NHIMG’s Top 10 NHI Issues highlights how excessive privilege and weak lifecycle control create recurring risk, and the same pattern appears when weak authentication lingers after a policy change.

Edge cases include shared customer journeys across business units, outsourced contact centres, and markets with inconsistent telecom reliability. In those environments, accountability usually fails when one team owns the policy, another owns the code, and a third owns the exception. Organisations that cannot show who approved the residual SMS exposure will struggle most during supervisory review.

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 SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.OV-01Governance ownership is central when multiple teams share auth accountability.
NIST SP 800-63SP 800-63BCovers authenticator assurance and discourages weak MFA factors like SMS OTP.
NIST SP 800-53 Rev 5IA-2Authentication control requirements support stronger factor enforcement and evidence.
NIST AI RMFGOVERNClarifies accountability for policy, risk decisions, and oversight of control changes.
OWASP Non-Human Identity Top 10NHI-01Weak auth often coexists with poor lifecycle control over secrets and tokens.

Assign one control owner and document governance decisions for every weaker-authentication exception.

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