What happens when organisations keep using OTPs and simple challenge questions against AI impersonation?

Why OTPs and simple challenge questions fail against AI impersonation

OTPs and simple challenge questions still help against opportunistic fraud, but they break down when an attacker can imitate a trusted person well enough to steer the conversation. If the only proof step is a code or a few remembered facts, the organisation is relying on a narrow signal that can be socially engineered, intercepted, or rendered irrelevant after a session is already compromised.

That weakness is not that the control is useless, it is that it is too easy to treat as decisive. A voice clone, scripted vishing call, breached personal data set, or compromised session can make a human reviewer accept the wrong party while believing the control worked.

Modern fraud and account attack patterns increasingly combine impersonation with access to live context, so the real issue is not whether a code was entered correctly, but whether the organisation has enough independent evidence to trust the interaction. That is why MFA Guide matters here, because the same bypass patterns that weaken OTPs also show why phishing-resistant and layered authentication is stronger than a single challenge.

What failures appear when the control is treated as sufficient

The most common failure is false assurance: staff think a caller or chat participant has been verified because one familiar hurdle was cleared. In practice, AI impersonation can supply just enough convincing detail to satisfy a challenge question, especially when answers are guessable, publicly available, or already exposed in past breaches.

A second failure is session abuse. Even if the impersonation begins as a successful verification step, the attacker may pivot into a live session, reuse an existing browser context, or exploit helpdesk workflows that trust the apparent identity too quickly. The fraud then moves from “can this person answer a question?” to “can this person be trusted to initiate a high-impact change?”

For voice and video scams, the gap is often procedural rather than technical. Organisations that do not require independent callback verification, supervisor approval, or transaction-specific confirmation are giving an attacker an easier path than the control is designed to stop. NHIMG’s Deepfakes, Social Engineering and AI Impersonation Guide is relevant because it maps the impersonation problem to the verification steps that actually interrupt it.

What stronger verification looks like in practice

Better defence starts by separating identity proof from transaction approval. A caller, chat participant, or requestor may be authenticated enough to continue the conversation, yet still not be authorised to change payment details, reset credentials, or approve sensitive access. That distinction matters because AI impersonation usually aims to win trust, not merely to pass a login step.

The stronger pattern is layered and contextual: use multiple signals, confirm from an independent channel, and bind the verification to the specific action being requested. In high-risk cases, the organisation should require something the imposter is unlikely to control, such as a known-good callback path, a pre-registered contact route, or an approval process that is separate from the original conversation. RFC 8693: OAuth 2.0 Token Exchange is useful as a reminder that delegation and impersonation need explicit handling, because trust should be granted to the right subject for the right purpose, not assumed from the current session.

Risk and Threat Considerations

AI impersonation raises the payoff for attackers because it reduces the cost of sounding credible. If the organisation still leans on OTPs and simple questions, the attacker only needs one weak link in the human verification process to gain access, reset credentials, or authorise a fraudulent action.

Failure mechanism: The control fails when the verifier over-weights a single factor, such as a code, memorised answer, or familiar voice, and does not independently confirm the requester or the transaction. Once the imposter reaches a trusted workflow, breached data, session replay, or callback deception can complete the compromise.

Impact: The organisation can end up with unauthorised account recovery, fraudulent payments, privilege escalation, or disclosure of sensitive information, all while believing a verification control succeeded. The damage is amplified when the same weak pattern is used repeatedly across helpdesks, finance teams, and executive support channels.

Practitioner Guidance

What to prioritise: Treat any process that can reset access, approve money, or change sensitive records as a high-risk workflow, not a normal support call. If the action is business-critical, verification must be stronger than whatever an attacker can realistically obtain from public data, breached data, or a convincing voice clone.

What to verify: Check whether the organisation can independently verify the requester through a channel that is not part of the same conversation. Also verify that the approval step is tied to the exact action requested, because generic identity checks are easy to over-trust when an attacker is impersonating someone known.

Common mistake: Replacing weak questions with slightly better weak questions, then calling the process “multi-factor.” If the added step can still be socially engineered or replayed in context, it is only a speed bump.

Practitioner takeaway: The goal is not to make impersonation impossible, it is to make one convincing interaction insufficient to trigger a high-impact decision.

Related resources from NHI Mgmt Group

• What happens when organisations rely on traditional security controls alone against deepfakes, sponge attacks, and AI-assisted impersonation?
• What happens when organisations keep using periodic penetration tests against fast-moving vulnerability exploitation?
• How can organisations defend against AI-generated phishing and impersonation?
• What should organisations keep humans involved in when using AI testing?