Organisations should move critical workflows away from OTPs as the sole proof of identity and toward stronger, multi-signal authentication. That means combining device intelligence, phone-related signals, verified identity sources, and step-up checks for high-risk actions. The practical objective is to make it much harder for a fraudster to reuse a stolen number or trick a user into approving access.
Why legacy OTPs stop being enough
OTP-based authentication breaks down when the attacker no longer needs to break the secret, only the person. Social engineering can defeat SMS or voice OTPs through number theft, call forwarding, real-time relay, push fatigue, or by convincing the user to disclose the code. Once the OTP becomes a reusable proof of login, it is too weak for high-value access.
The real problem is not that OTPs have no value, but that they are single-signal and easy to weaponise in fraud workflows. For critical actions, organisations need authentication that is harder to replay, harder to proxy, and less dependent on a user’s momentary judgment.
That is why phishing-resistant authentication guidance from NIST SP 800-63 Digital Identity Guidelines is so relevant here: it pushes teams toward stronger authenticators and assurance patterns rather than treating a one-time code as sufficient proof.
What stronger authentication should add
When organisations replace OTP as the sole control, they should add signals that are harder for a fraudster to fake in real time. Device intelligence can tell you whether the session comes from a trusted device or a suspicious emulator, rooted phone, or changed browser environment. Phone-related signals, such as SIM swap or number porting risk, can expose takeover conditions that OTP alone misses.
Verified identity sources add another layer by checking whether the person or account has already been established through a stronger process, such as bound credentials, prior enrolment, or trusted recovery data. Step-up checks then reserve the highest friction for the highest-risk actions, such as changing payout details, resetting recovery factors, or authorising a new beneficiary.
The design goal is not just “more MFA”. It is better fraud resistance through factor diversity, context, and binding. A stolen code should not be enough to complete the workflow if the device, number, or transaction context looks wrong.
That same direction is reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls around identification, authentication, access enforcement, and auditing, which support risk-based decisions instead of one-step approval.
How to redesign the workflow for fraud resistance
The most practical change is to stop using OTP as a blanket login gate and instead map controls to the action being performed. Low-risk access may still use a conventional second factor, but account recovery, payout changes, privileged access, and transaction approval should require stronger proof and tighter reauthentication. That reduces the number of places where a social engineer can turn a stolen code into a loss event.
- Bind the session to a known device or cryptographic authenticator where possible.
- Use step-up checks only for actions that materially increase fraud or privilege risk.
- Treat phone-number changes, SIM swaps, and recovery resets as high-risk events.
- Log and review repeated OTP failures, unusual approval timing, and impossible travel patterns.
For most organisations, the hardest part is not the control itself, but defining which actions deserve stronger assurance. The answer should be “anything that creates irreversible business impact”, not only administrative access.
Where the login or approval path is exposed to direct social engineering, incidents such as the Uber Breach show how fast MFA fatigue and user manipulation can turn authentication into a fraud enabler rather than a defence. Legacy OTPs are especially fragile when the attacker can keep the victim engaged in real time.
Risk and Threat Considerations
Legacy OTPs create a concentration risk: once attackers learn to intercept, relay, or socially engineer the code, a single captured factor can unlock account access, recovery, or transaction approval. The exposure is highest where OTPs protect high-value workflows and where the organisation assumes a verified code means a verified person.
Failure mechanism: A fraudster exploits weak factor binding, number compromise, or user coercion to reuse the OTP in real time, then immediately pivots into account takeover, payment diversion, or recovery-path abuse.
Impact: Organisations can lose both control of the account and confidence in the approval trail, because the event looks like legitimate user activity unless device, number, and transaction context are checked together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and assurance levels address OTP weakness in social-engineered logins. |
| Recommendation — Adopt phishing-resistant authenticators for high-risk access and recovery flows. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Org-user authentication must withstand social engineering and support stronger assurance than OTP alone. |
| AU-6 — Audit Review, Analysis, and Reporting | Fraud-resistant auth depends on monitoring OTP anomalies, risky resets, and unusual approvals. | |
| Recommendation — Require stronger authentication for users who can reach critical workflows. Review authentication and recovery events for signs of social-engineering abuse. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control should gate critical workflows with stronger proof than a reusable OTP. |
| A.8.5 — Secure authentication | Secure authentication control selection is central when OTP is no longer sufficient against fraud. | |
| Recommendation — Apply risk-based access control to sensitive actions and recovery paths. Replace OTP-only checks with stronger authentication for high-risk actions. | ||
Practitioner Guidance
What to prioritise: Move first on workflows where a successful fraud event is irreversible or difficult to unwind, especially account recovery, beneficiary changes, payments, and admin privilege elevation. Those are the places where OTP weakness becomes a business-loss problem, not just an authentication gap.
What to verify: Confirm that step-up decisions are driven by multiple signals, not just a second code. A good control set should be able to explain why a login was accepted, why a transaction was challenged, and why a recovery attempt was blocked.
Practitioner takeaway: OTPs can still be one signal in a larger decision, but they should no longer be the deciding signal when social engineering can turn a code into an authorised action.
Related resources from NHI Mgmt Group
- How can organisations reduce risk from browser-based social engineering against AI tools?
- What are the signs that traditional user authentication is no longer enough against identity fraud?
- Why do trust-based social engineering campaigns remain effective against organisations and individuals?
- Why do traditional identity processes fail against social engineering and hiring fraud?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
