Why can call forwarding bypass voice one-time codes?

Why call forwarding creates a separate authentication path

Call forwarding changes where the call lands, not whether the phone number still looks reachable. That matters because a voice one-time code is usually a possession check, not a proof that the original subscriber is answering in a controlled environment. If the call is rerouted, the code can still be received, but by the wrong endpoint.

This is why voice delivery is weaker than many users assume. The control is tied to telephony routing, caller assumptions, and carrier or device settings, so it can fail even when the account itself has not been ported or fully taken over.

How forwarding differs from porting and why that distinction matters

Forwarding and porting are often confused, but they fail differently. With forwarding, the original number can remain active while calls are transparently redirected. With porting, control of the number itself moves to another provider or account. For authentication, the important point is that both can undermine trust in the phone number as an identity channel, but forwarding can do it without an obvious ownership change.

That distinction affects how you investigate a suspected bypass. A user may still see their number as active, receive other calls, and miss the fact that specific verification calls are being diverted elsewhere. For this reason, voice OTP should be treated as a fragile recovery or step-up factor, not a strong binding signal on its own.

Why this failure mode is attractive to attackers

Call forwarding is useful to attackers because it can preserve normal-looking service while silently changing delivery. That creates an interception opportunity for authentication callbacks, password resets, and other voice-based verification flows. It also makes the abuse harder to notice than a simple outage, because the number still works from the user’s perspective.

When voice codes are used as a fallback, the attacker does not need to break the code generation itself. They only need a way to redirect the call path. That makes the weakness operationally important wherever voice OTP is used as a recovery factor, a backup channel, or a temporary step-up method.

Risk and Threat Considerations

Voice codes are exposed to redirection, social engineering, and carrier-level abuse, so the real risk is not just interception but account recovery abuse and silent bypass of a second factor. If the organisation assumes “the phone rang, therefore the user received it,” it can miss a compromised delivery path.

Failure mechanism: An attacker or intermediary changes call routing, then waits for a verification call to land on an attacker-controlled destination while the original line still appears usable.

Impact: The account can be approved, reset, or stepped up without the legitimate user seeing the one-time code, which can enable takeover, recovery hijack, or repeated interception of future calls.

Practitioner Guidance

What to prioritise: Treat voice OTP as a weaker fallback than app-based or phishing-resistant methods, especially for recovery and step-up decisions. If the use case can be satisfied without voice delivery, remove it from the highest-risk flows first.

What to verify: Confirm whether the system accepts voice codes after recent call-forwarding changes, number changes, or recovery events. Also verify whether the account has any trusted-device, recovery, or support workflow that can still succeed even when the code path is compromised.

Decision rule: If a factor can be redirected without changing subscriber ownership, do not treat delivery to that factor as strong proof of user presence. Prefer a channel that is harder to reroute silently and that binds the verification event to the intended device or browser session.

Practitioner takeaway: The key lesson is that delivery success is not the same as authentication success, so voice OTP should be designed as a limited fallback rather than a trusted primary control.

Related resources from NHI Mgmt Group

• How should teams decide when one-time codes are still acceptable for MFA?
• Why do one-time codes create a false sense of security?
• Why do Duo OTPs and similar one-time codes still fail against phishing?
• Why do one-time codes fail for high-risk financial approvals?