Ownership should sit with security, fraud, IAM, and product teams together, because the risk spans authentication design, customer experience, and incident response. Security sets the control standard, fraud teams watch attack patterns, and product teams manage user rollout. If ownership stays fragmented, the organisation will keep shifting blame to customers instead of reducing the real exposure.
Why This Ownership Question Matters for Banking and Digital Services
Moving beyond SMS OTP is not just a security upgrade. It changes how organisations approve access, recover accounts, handle fraud signals, and support customers who lose a device or cannot complete enrolment. If ownership is left to one function alone, teams usually optimise for their own metric and miss the system-wide failure mode: weaker assurance with more support friction.
The right ownership model is cross-functional because stronger authentication affects risk decisions, not just login screens. Security should define the assurance target, IAM should make the journey technically enforceable, fraud should shape step-up and anomaly handling, and product should make the rollout usable enough that customers do not route around it. NHIMG research on non-human identity exposure is a reminder that authentication failures often scale quietly: when credential handling is weak, impact spreads fast and visibility stays low. That same lesson applies here, even when the user is human.
In practice, many organisations discover the ownership gap only after customers, support, and fraud operations are already working around the process rather than through it.
How the Move from SMS OTPs to Stronger Authentication Should Work
Ownership should be structured around decision rights, not just project delivery. Security owns the assurance standard, including what counts as acceptable authentication strength for different journeys. IAM owns the identity platform and the policy mechanics that make the standard enforceable. Product owns the customer journey, channel sequencing, and rollout design. Fraud and financial crime teams own abuse patterns, because step-up controls and recovery flows need to reflect how attackers actually target banking accounts.
In practical terms, the first question is not “which tool replaces SMS,” but “which journeys need which level of proof.” High-risk actions such as beneficiary changes, device binding, payout approvals, and account recovery often need stronger controls than routine sign-in. That may mean passkeys, phishing-resistant MFA, device binding, risk-based step-up, or in some cases transaction-specific verification. Current guidance suggests organisations should treat authentication as part of an access policy, not as a one-time login choice.
A workable operating model usually includes:
- A shared policy for when SMS OTP is allowed, restricted, or retired.
- A fraud review path for unusual enrolment, SIM-swap indicators, and account takeover signals.
- A product rollout plan that measures completion, abandonment, and support contacts, not only adoption.
- A recovery design that prevents fallback channels from becoming the weakest path.
If the organisation serves multiple brands or channels, the weakest branch often becomes the de facto standard unless the policy is centrally owned and locally enforced.
For broader governance context, NIST’s Security and Privacy Controls is useful because it frames authentication as a control objective across access, monitoring, and incident handling. NHIMG’s Ultimate Guide to Non-Human Identities also helps teams think about credential lifecycle discipline, which matters here because poor authentication design often ends up creating long-lived recovery weaknesses. These controls tend to break down when legacy channels, call-centre exceptions, and inconsistent customer journeys are allowed to bypass the stronger standard.
Where Ownership Commonly Fractures and What to Do About It
Tighter authentication rollout often increases customer friction and support load, so organisations have to balance stronger assurance against enrolment drop-off and account recovery pain. The biggest ownership failure is treating the migration as a one-time channel swap instead of an operating model change. That creates gaps between policy, fraud detection, support scripts, and customer communication.
There is no universal standard for this yet, but a few edge cases consistently matter. Banking apps with high-value transaction flows need tighter ownership than low-risk digital services, while shared identity stacks across many products benefit from central policy and local product execution. Regulated firms also need a clearer decision on exception handling, because temporary SMS fallback can quietly become permanent if nobody owns its removal. The most common mistake is assigning migration responsibility to a technology team without giving fraud and product authority over the user journey and recovery rules.
Practitioner Guidance
What to prioritise: Define one accountable owner for the authentication standard, then give security, IAM, fraud, and product explicit decision rights for their parts of the rollout. Without that split, teams will preserve the old channel as a convenience escape hatch.
What to verify: Check that fallback and recovery paths are at least as controlled as primary sign-in, because attackers usually target the weakest route rather than the intended one.
Decision rule: If a journey can change money movement, account state, or contact details, treat it as a high-assurance path and do not let SMS remain the default verifier.
Practitioner takeaway: The right owner is not the team that can deploy fastest; it is the group that can keep authentication strong, usable, and removable as legacy risk is retired.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | Stronger authentication migration depends on controlling account access paths and lifecycle. |
| Recommendation — Standardise account access rules and retire weak fallback paths across user journeys. | ||
| NIST CSF 2.0 | PR.AA-1 — Identity Management, Authentication, and Access Control | The question is about who owns authentication strength and access assurance. |
| GV.RR-1 — Roles, Responsibilities, and Authorities | The core issue is cross-functional ownership and accountability for the migration. | |
| RS.MA-1 — Response and Mitigation | Fraud teams need ownership of abuse signals and incident-linked step-up actions. | |
| Recommendation — Assign clear ownership for authentication policy and enforce consistent access assurance. Define accountable roles for security, IAM, fraud, and product decisions. Use fraud signals to trigger stronger verification and account protection actions. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Authentication strength should match the assurance needed for the transaction or service. |
| Recommendation — Map each journey to the required assurance level before replacing SMS OTP. | ||
Related resources from NHI Mgmt Group
- Which frameworks require stronger authentication than SMS OTPs for sensitive access?
- How should security teams make NHI best practices usable across the business?
- What breaks when authentication services are reused across connected and isolated environments?
- Why do weak authentication methods create fraud risk in digital banking?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
