Time-based OTPs still matter, but MFA assumptions are shifting

At a glance

What this is: This is a 1Kosmos explainer arguing that time-based OTPs remain a valid MFA factor, but their value drops quickly when the authenticator device or token generator is compromised.

Why it matters: IAM teams need to treat OTP as one factor in a broader trust model, because possession-based authentication alone no longer maps cleanly to how credentials, devices, and user trust are actually abused.

Context

Time-based OTPs are a possession-based MFA factor that changes on a synchronized clock, which makes them harder to guess, replay, or reuse than static passwords. The governance gap is not whether OTPs work at all, but whether identity programmes still treat possession of a phone or token as sufficient proof of trust.

That assumption becomes weaker when the authenticator itself is compromised, stolen, or delivered through channels that can be intercepted. For identity teams, the question is no longer whether OTP fits MFA, but where it still fits in a programme that also has to govern phishing resistance, device loss, and recovery paths.

Key questions

Q: What breaks when time-based OTP is the only MFA factor teams rely on?

A: The trust assumption breaks when the authenticator device is stolen, shared, or exploited in a live phishing flow. In that case, the code may still be valid, but the control no longer proves that the right person is present. Teams should reserve TOTP for lower-risk access or combine it with stronger phishing-resistant methods for sensitive actions.

Q: Why do time-based OTPs still matter if phishing-resistant MFA is the goal?

A: They still reduce brute-force, replay, and password-guessing risk, and they are easy for users to adopt. The limitation is assurance depth, not usefulness. For many organisations, TOTP remains a practical middle layer while stronger methods are rolled out for administrators, high-value systems, and recovery paths.

Q: What are the signs that an OTP-based MFA programme is too dependent on possession?

A: Common warning signs include weak device-loss handling, easy account reset processes, broad use of SMS delivery, and no extra checks for privileged logins. If a stolen phone or intercepted code can quickly unlock sensitive access, the programme is treating possession as stronger evidence than it really is.

Q: Should organisations keep TOTP for all users or reserve it for lower-risk access?

A: Most organisations should keep TOTP where usability matters, but reserve the highest-risk access for stronger methods that resist phishing and device theft. The right decision depends on the consequence of compromise. If the account can expose production systems, financial controls, or admin functions, TOTP alone is usually not enough.

Technical breakdown

How time-based OTP generation works

Time-based one-time passwords, or TOTPs, use a shared secret plus synchronized time to generate short-lived codes. The verifier and the authenticator each compute the expected code for the current interval, so the code changes predictably without user input. That design reduces reuse and replay risk because the value expires quickly and is tied to a narrow time window. It is still a possession factor, though, because the security property depends on control of the device or application generating the code rather than on the user’s inherent identity.

Practical implication: treat TOTP as a narrow possession check, not as proof that the account holder is present and trustworthy.

Why TOTP resists phishing and replay better than static factors

A TOTP code is stronger than a password or static OTP because it is only valid for a brief interval and is not reused across sessions. That limits the usefulness of intercepted credentials, especially in attacks that try to replay a captured code after the original transaction. The limitation is that the attacker only needs the code and the time window, not necessarily the user’s long-term password, if the authentication flow allows rapid capture and use. Phishing resistance therefore depends not only on the code format, but also on the surrounding identity workflow and user interaction model.

Practical implication: evaluate whether your OTP flow can still be abused in real time by adversary-in-the-middle phishing.

Where OTP assurance collapses when the device is stolen

TOTP security degrades sharply when the token generator is compromised, because the attacker no longer needs to bypass the time factor. If the authenticator app or hardware token is on a stolen phone or device, the possession assumption has already failed. That is why OTPs protect against some credential attacks but do not solve the problem of trust in the authenticator itself. In governance terms, the issue is not the algorithm’s math, but the lifecycle and protection of the thing generating the code.

Practical implication: align recovery, device-loss, and authenticator replacement processes with the actual trust boundary of the OTP factor.

NHI Mgmt Group analysis

Possession-based MFA is no longer the same as trust. Time-based OTPs still add value, but they do not change the fact that many identity programmes equate control of a device with control of the account. That assumption breaks as soon as the authenticator is stolen, shared, or intercepted in a live phishing flow. Practitioners should treat possession as a conditional signal, not a durable trust anchor.

OTP reduces attack success, but it does not remove the identity-boundary problem. A synchronized code narrows brute-force, replay, and offline guessability, yet the surrounding workflow still determines whether an attacker can use a captured factor fast enough to matter. That means authentication design, recovery flows, and step-up logic matter as much as the TOTP algorithm itself. Identity teams need to govern the full path, not just the factor.

Authentication strategy is shifting from factor strength to factor resilience. The decisive question is not whether OTPs are obsolete, but whether the programme can survive device theft, SIM compromise, and real-time phishing without relying on a single possession claim. That makes recovery, proofing, and phishing-resistant alternatives part of the same governance conversation.

Time-based OTPs expose a trust-boundary problem that many MFA programmes still ignore. The code expires quickly, but the risk persists for as long as the authenticator can be duplicated, stolen, or replayed through user deception. In practice, the weak point is not the timer. It is the assumption that the authenticator itself remains trustworthy throughout its lifecycle.

TOTP should be viewed as a transitional control, not an endpoint. It remains useful where the threat is low-to-moderate and user adoption matters, but it is no longer enough as the highest assurance factor for sensitive access. Teams should design MFA with the expectation that possession can be lost, copied, or coerced, and then govern accordingly.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: MFA Guide

What this signals

Phishing-resistant MFA is becoming the real benchmark: time-based OTPs still help, but they no longer satisfy the assurance expectations for sensitive access where real-time interception and device theft are realistic. Identity programmes should separate broad user convenience from privileged access assurance and stop assuming one factor fits every trust boundary.

The operational question is not whether OTP should disappear, but where it should stop being the primary control. For many teams, that boundary is privileged access, high-value transactions, and recovery flows, where possession of a device is too fragile to stand alone.

For practitioners

• Assess possession assumptions in MFA design Review where TOTP is being treated as sufficient proof of user trust and identify any high-risk access paths that still rely on that assumption.
• Harden authenticator recovery flows Make device replacement, token reset, and account recovery reflect the same assurance level as the protected application, especially for privileged access.
• Prioritise phishing-resistant authentication for sensitive roles Move the most exposed users and administrators toward controls that do not depend on a reusable code being entered during a live session.
• Audit stolen-device blast radius Map what an attacker can do if a phone, hardware token, or authenticator app is compromised, then reduce the resulting access scope.
• Keep OTP in a layered access model Use TOTP where it fits operationally, but pair it with risk-based step-up, device trust checks, and tighter recovery governance.

Key takeaways

• Time-based OTPs still reduce common credential attacks, but they are only as strong as the authenticator device that generates them.
• The practical failure mode is not the code format itself, but the assumption that possession of a phone or token proves durable trust.
• Identity teams should keep TOTP where it helps adoption, then raise assurance for high-risk access with stronger authentication and tighter recovery governance.

Key terms

• One-Time Password: A one-time password is a short-lived authentication code used once, then discarded. It usually supplements a primary password as a second factor, but its security depends heavily on how the code is generated, delivered, and recovered if the user loses access.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Authenticator recovery: Authenticator recovery is the process used to restore access when a primary login method is lost or unavailable. It is often the weakest part of a modern identity stack because attackers target support workflows, reset paths, and backup channels that have lower assurance than primary authentication.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.