Why do OTP codes remain vulnerable even when they expire quickly?

Why quick expiry is only one part of OTP security

OTP expiry mainly limits how long a stolen code stays usable. It does not make the code unobservable, and it does not stop an attacker who can intercept it in transit, relay it in real time, or steal it from the user’s active session. That is why OTPs can still fail even when the time window is short.

A short validity period is a replay control, not an end-to-end trust guarantee. Once the attacker can act within the same window as the legitimate user, the code is still valid from the verifier’s perspective. The real question is whether the authentication path resists interception, forwarding, and session hijack.

Phishing-resistant MFA changes the problem because the verifier is no longer relying on a shared code that can be copied and reused. For a practical comparison of OTP methods versus stronger options such as passkeys and security keys, see the MFA Guide and the NIST SP 800-63 Digital Identity Guidelines.

Where OTPs still break in practice

The main weakness is not the expiry timer, it is the delivery path. SMS OTPs can be intercepted through SIM swap, message forwarding, malware, or telecom abuse. App-based OTPs are better, but they still depend on a device and user session that can be phished, mirrored, or coerced in real time.

Attackers do not need to keep the code indefinitely. They only need to capture it before it expires and submit it faster than the user or the legitimate client. In an adversary-in-the-middle flow, the victim enters the OTP into a fake site, the attacker relays it immediately to the real service, and the login succeeds while the attacker is still in the session.

That is why code lifetime and channel integrity are separate problems. Expiry can reduce the blast radius of a leaked code, but it does not address the trustworthiness of the browser, the device, the network path, or the application session that carries the challenge and response.

For organisations that still rely on OTPs, OWASP Non-Human Identity Top 10 is useful not because OTPs are an NHI topic, but because it frames the same practical issue of secret handling, short-lived credentials, and overreliance on bearer material that can be copied before expiry.

What stronger protection has to add

Effective protection must bind the authentication event to a trusted device, a trusted origin, or a cryptographic challenge that cannot be replayed by a proxy. That usually means moving away from one-time codes as the primary factor and toward phishing-resistant methods such as passkeys, hardware security keys, or other verifier-bound authenticators.

Lifecycle controls also matter. If the authentication flow depends on OTP, then secret handling, enrollment, recovery, and reset paths become part of the attack surface. A weak recovery process can undermine a strong token because attackers often target the easiest route into the account, not the nominal second factor.

For teams designing or reviewing authentication, the important distinction is between “valid for a short time” and “safe to use in an untrusted channel.” A short-lived code may be acceptable as a step-up check, but it should not be treated as proof that the overall login path is resistant to phishing, relay, or session takeover.

The operational comparison between short-lived and reusable secrets is well covered in the Guide to NHI Rotation Challenges and the Ultimate Guide to NHIs, Static vs Dynamic Secrets, because both show the same principle: shrinking validity helps, but it does not replace stronger binding and better control of the credential path.

Risk and Threat Considerations

OTP expiry reduces the window for simple replay, but it leaves the highest-value attack paths intact: interception, real-time relay, and session theft. The attacker’s objective is to use the code before the legitimate user finishes the flow, so the risk is concentrated in the delivery channel and the active login session rather than in the code’s lifetime.

Failure mechanism: The attacker captures the OTP from the victim, the device, or the channel, then forwards it immediately to the real service or uses it inside a compromised session. The code remains “fresh” long enough for the adversary to authenticate because the verifier cannot distinguish the attacker’s relay from the user’s submission.

Impact: Account takeover can succeed even when the OTP expires quickly, especially when the user is actively being phished or the device is already compromised. Short expiry lowers exposure to delayed reuse, but it does not stop live abuse of trust.

Practitioner Guidance

What to verify: Check whether your OTP flow is vulnerable to relay, SIM swap, push fatigue-style abuse, or session replay. If the answer is yes, treat the factor as weak against active phishing even if expiry is short.

Decision rule: If the login path can be completed from a phishing page or remote proxy, prioritise phishing-resistant authentication over shorter OTP windows. Shortening expiry is a tuning change; it is not a control replacement.

What good looks like: The authentication method should bind the response to the intended relying party and the intended device, so that a copied code or relayed challenge cannot be reused outside the original context.

Practitioner takeaway: A fast-expiring OTP mainly limits stale reuse, but real security comes from preventing interception and relay in the first place.

Related resources from NHI Mgmt Group

• Why do developers and DevOps teams remain vulnerable to vishing even when they understand the risk?
• Why do regression models remain vulnerable to poisoning attacks even when they look accurate on clean data?
• Why do push, TOTP, and SMS remain risky even when they are called MFA?
• Why do Kubernetes secrets remain risky even when they are base64-encoded?