Accountability sits with the institution’s control owners, risk leaders, and compliance function, because the article makes clear that some regulators also shift liability for fraud linked to weak authentication. The practical question is whether the remaining exception is documented, time-bound, and defensible under the applicable market rule.
Why This Matters for Security Teams
When a bank continues using SMS OTP after a regulator has restricted it, the issue is not just a channel preference. It becomes a control accountability problem across the business, risk, and compliance owners who approved the exception, tolerated the residual exposure, or failed to retire the control on time. NIST frames this as a cybersecurity governance and risk decision, not an isolated technical setting, in NIST Cybersecurity Framework 2.0.
The practical danger is that SMS OTP is often treated as “good enough” because it exists, not because it is resilient against SIM swap, number port-out fraud, interception, or social engineering. That creates a gap between policy intent and operational reality. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how auditability and ownership matter when security controls remain in use under exception. In practice, many security teams encounter accountability failures only after a fraud event or supervisory review exposes that the “temporary” exception was never formally removed.
How It Works in Practice
Accountability typically follows the control owner model: the team that owns authentication, the risk function that accepted the exception, and the compliance group that mapped the control to the applicable rule all share responsibility for whether SMS OTP remains defensible. The bank should be able to show who approved it, why it was allowed, what compensating controls exist, when the exception expires, and what trigger retires it. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because the same lifecycle discipline applies to credentials, secrets, and any authentication method that should not stay in place indefinitely.
Operationally, a defensible exception record should include:
- Named control owner, risk owner, and approver
- Regulatory basis for the exception and the customer cohort affected
- Compensating controls such as transaction monitoring, step-up authentication, and fraud alerts
- Expiry date, review cadence, and sunset plan
- Evidence that the bank tested a stronger alternative and documented why it was not yet deployed
Security teams should also align the decision with control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where authentication assurance, audit logging, and risk acceptance need traceable ownership. This is not about proving perfection. It is about proving that the bank knowingly accepted a bounded risk and actively tracked retirement of the weaker factor. These controls tend to break down when product, fraud, and compliance teams each assume someone else owns the exception register.
Common Variations and Edge Cases
Tighter authentication policy often increases customer friction and migration cost, requiring organisations to balance fraud reduction against operational disruption. That tradeoff is real, which is why current guidance suggests not every SMS OTP use is automatically negligent if a regulator has allowed a limited transition period or an explicit exception path. The difference is whether the exception is current, narrow, and evidenced, not whether the bank can point to legacy practice.
Edge cases usually appear in segmented populations. A bank may still use SMS OTP for low-risk, non-monetary actions while requiring stronger factors for payments, password resets, or new-device enrollment. In those cases, accountability shifts to the business owner who defined the scope and the control tester who verified the boundary. NHIMG’s Top 10 NHI Issues is relevant because weak or overextended credentials often persist for the same reason weak OTP exceptions do: no one owns the cleanup.
There is no universal standard for this yet across all jurisdictions, so the safest posture is to document the market rule, the compensating control set, and the retirement plan, then review them on a fixed cadence. If the bank cannot show that chain of accountability, the exception starts to look less like regulated tolerance and more like unmanaged drift.
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 AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Risk acceptance and exception ownership are core governance duties. |
| NIST SP 800-63 | IAL/AAL guidance | SMS OTP touches authentication assurance and identity proofing strength. |
| NIST AI RMF | Accountability for exceptions supports governed risk decisions and traceability. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Long-lived authentication exceptions resemble unmanaged credential lifecycle risk. |
| NIST Zero Trust (SP 800-207) | PR.AC-3 | Zero trust expects continuous verification, not weak static factors by default. |
Map the bank's factor choices to the required assurance level and retire weak factors where they fall short.
