IAM, fraud, product, and compliance should share accountability, but the owner of the journey must decide whether the fallback preserves the security objective. If fraud prevention is the goal, a fallback that reuses SMS OTP undermines the control. The accountable team should be the one that can defend both the primary factor and the fallback path.
Why This Matters for Security Teams
Removing SMS OTP is not just a channel swap. It forces teams to answer who owns the security outcome when the primary factor is gone and a fallback is still needed. If fallback is treated as a convenience feature, the control objective can quietly collapse, especially when fraud, account takeover, and recovery abuse are part of the same journey. NIST’s NIST SP 800-63 Digital Identity Guidelines makes clear that identity assurance depends on the full authenticator lifecycle, not only enrollment.
The practical mistake is assigning fallback to a single team that cannot defend both security and user recovery. IAM may implement the mechanism, fraud may measure attack pressure, product may own conversion, and compliance may define acceptable risk, but accountability has to sit with the journey owner who can approve tradeoffs. That is the same governance lesson visible in breaches such as the Schneider Electric credentials breach, where weak identity controls created broader exposure than the initial failure point suggested.
In practice, many teams discover that the fallback path was the weakest control only after an account recovery abuse pattern has already become the attacker’s preferred route.
How It Works in Practice
Accountability should be defined around the authentication journey, not the individual factor. The team that owns the journey decides whether the fallback preserves the original security objective, then delegates implementation to IAM and operational review to fraud and compliance. That means documenting what the fallback is allowed to prove, what risk it accepts, and when it must be disabled. Current guidance suggests this decision should be tied to assurance level, recovery risk, and the account’s business impact, not to whether a legacy channel is still available.
Practically, strong programs separate three questions: who can approve the fallback, who can implement it, and who can override it in an incident. The approval owner should define conditions such as device binding, step-up verification, channel diversification, or call-centre verification with robust anti-social-engineering checks. The implementation team should instrument the flow so every fallback event is logged, reviewed, and trended. The risk owner should also ensure the fallback does not become a hidden bypass that grants the same access as the primary factor without comparable assurance.
For NHI programmes, the same principle appears in credential lifecycle governance: weak offboarding, excessive privileges, and unclear ownership create preventable exposure. NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that ownership without enforcement is not real control. The lesson transfers cleanly to human authentication recovery. Teams that only debate whether SMS should be removed often miss the harder question of which fallback actually maintains the security objective and which one merely preserves login success.
These controls tend to break down in high-volume consumer environments with call-centre recovery, because operational pressure pushes teams to accept weaker fallback paths to avoid conversion loss.
Common Variations and Edge Cases
Tighter fallback controls often increase support friction and recovery cost, requiring organisations to balance fraud resistance against user abandonment. That tradeoff is real, and there is no universal standard for this yet. Some programs choose no fallback at all for high-risk actions, while others allow a slower but stronger path such as in-person verification, device re-binding, or out-of-band approval.
The edge case is when product or support teams assume fallback is a UX decision. It is not. If the fallback can reset the factor, issue a replacement channel, or bypass risk checks, then it is effectively a new authenticator and should be governed accordingly. That is why compliance should not “own” the fallback in isolation, and why IAM should not be made solely responsible for policy decisions it cannot justify from a business-risk standpoint. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for framing access control, while the ISO/IEC 27001:2022 Information Security Management approach supports formal ownership, risk treatment, and control review.
In the real world, the accountable owner is the team that can stop a bad fallback from existing, not the team that merely operates it after launch.
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 SP 800-63, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Defines assurance across primary and fallback authenticators. | |
| NIST CSF 2.0 | PR.AA | Authentication governance must cover fallback paths and recovery assurance. |
| NIST AI RMF | GOVERN | Governance is needed to assign accountability for authentication tradeoffs. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Fallback paths often fail when lifecycle and rotation ownership are unclear. |
Set governance roles that approve fallback risk and review whether the control objective still holds.
