Should organisations replace SMS OTP before changing their broader identity stack?

Why SMS OTP should not wait for the broader identity refresh

sms otp is usually a recovery control before it is a primary login control. That matters because recovery paths are where number recycling, SIM swap, port-out fraud and carrier account takeover can turn a valid code into unauthorised account access. If the business already sees high-value consumer flows through SMS, the safer order is to replace the riskiest journey first, not to defer it until the rest of the stack changes.

Where the weakest journey usually sits

The highest-risk cases are the ones where SMS OTP can unlock money movement, communication access or credential reset. Banking, wallet and messaging products deserve earlier attention because compromise there tends to create immediate downstream harm, not just a nuisance login event. Organisations should treat recovery and step-up authentication as separate decisions, then replace SMS where the blast radius of a recycled number is hardest to absorb.

That usually means asking two questions: can an attacker obtain the phone number without the customer losing the account, and does the OTP gate a recovery path or only a low-impact session? If the answer to either is yes, SMS is already too brittle to be the last remaining legacy factor.

What the replacement path should prove before rollout

A good replacement is not just “something stronger than SMS”. It needs to preserve the user journey under real failure conditions, including device loss, SIM change and account recovery. Phishing-resistant MFA, authenticator apps, security keys and well-designed recovery flows all reduce dependence on telco ownership assumptions, but each changes support burden, enrolment friction and exception handling in different ways.

For teams modernising incrementally, the practical sequence is often to move recovery first, then login step-up, then long-tail fallback handling. That sequencing reduces exposure fastest without forcing a big-bang identity migration that leaves the old recovery path in place longer than necessary.

Risk and Threat Considerations

SMS OTP is exposed to telephone-number lifecycle failure, not just credential theft. When a recycled number or fraudulent SIM change can satisfy recovery or step-up checks, an attacker can convert access to a telecom channel into access to the account itself.

Failure mechanism: The control assumes stable number ownership, but number reassignment, port-out abuse, SMS interception and recovery workflow abuse break that assumption and let an attacker receive the OTP intended for the legitimate user.

Impact: The result can be account takeover, irreversible recovery path compromise and, in high-value services, direct financial loss or messaging impersonation that spreads the incident beyond the original account.

Practitioner Guidance

What to prioritise: Replace SMS first on journeys where OTP can reset credentials, recover access or authorise a high-value action. If the factor only protects a low-risk interaction, it can usually wait behind the highest-blast-radius paths.

What to verify: Test whether your current flow still trusts number ownership after a SIM swap, number recycle or port-out event. If the recovery journey remains reachable by SMS alone, the control is not sufficiently bounded.

Decision rule: If a failed SMS factor would expose funds, private communications or privileged account recovery, treat replacement as a current-risk remediation rather than a future identity programme item.

Practitioner takeaway: The right sequencing is driven by recovery risk, not by platform migration convenience, because the oldest factor is usually the one that preserves the attacker’s shortest path to takeover.

Related resources from NHI Mgmt Group

• Why do organisations replace SMS OTP in high-risk journeys before full account-wide migration?
• How should organisations replace SMS OTP without creating user friction?
• How should identity and fraud teams decide when to replace SMS OTP?
• Should organisations replace unsupported identity platforms before the next major disclosure wave?