Notifications
Clear all
Topic starter
10/07/2026 9:25 pm
TL;DR: Replacing SMS OTP is becoming a governance problem, not just a UX tweak, as phishing relay, SIM swap, port-out fraud, recycled numbers, and SS7 interception are industrialised attacks, according to IDlayr. The hard question is whether teams can measure conversion, fraud, and fallback risk before they let an outdated factor keep defining their authentication posture.
NHIMG editorial — based on content published by IDlayr: How to Replace SMS OTP: A Practical Guide
By the numbers:
- Lydia, the European payments app, deployed Silent Network Authentication in checkout and saw a 25% uplift in conversion alongside elimination of the phishable OTP step.
Questions worth separating out
Q: How should security teams replace SMS OTP without disrupting key user journeys?
A: Start with one journey that has clear business pain, such as onboarding, checkout, or step-up authentication.
Q: Why does SMS OTP create more risk than many teams assume?
A: Because the trust boundary sits in the telecom and messaging path, not in the user’s device alone.
Q: What do security teams get wrong about replacing SMS OTP?
A: They often treat the replacement as a technology swap instead of a governance decision.
Practitioner guidance
- Prioritise one high-friction, high-loss journey first Choose the journey where SMS OTP causes the most abandonment or fraud loss, then define success metrics before any integration work begins.
- Run the replacement in shadow mode before cutover Deploy the new verification path alongside the current OTP flow for a measured period so you can capture real coverage, latency, and success-rate data without changing the user experience.
- Design the fallback as part of the threat model Decide in advance what users outside coverage will receive, and do not use SMS OTP as the fallback if the goal is to remove phishing and relay risk.
What's in the full article
IDlayr's full guide covers the operational detail this post intentionally leaves for the source:
- A journey-by-journey deployment sequence for teams replacing SMS OTP in mobile-first authentication flows.
- A business-case template that breaks out conversion uplift, fraud reduction, operational drag, and regulatory exposure.
- A practical shadow-mode approach for validating coverage, latency, and fallback behaviour before user-facing cutover.
- Selection criteria for deciding whether a native app, mobile web, or checkout flow is the right first use case.
👉 Read IDlayr's practical guide to replacing SMS OTP in enterprise journeys →
Replacing SMS OTP: what identity teams need to decide first?
Explore further
10/07/2026 9:47 pm
SMS OTP is no longer a durable trust mechanism for regulated identity journeys. The channel was designed for convenience, not for phishing-resistant assurance, and that assumption now fails under relay attacks, SIM swaps, and number recycling at scale. The practical implication is that IAM teams should stop treating SMS OTP as a permanent factor and start classifying it as a legacy fallback with shrinking applicability.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who should be accountable for fallback authentication when SMS OTP is removed?
A: 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.
👉 Read our full editorial: SMS OTP replacement is now a governance and fraud priority
