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

At a glance

What this is: This is an explainer on time-based OTPs and where they strengthen, and fail, as an MFA factor.

Why it matters: It matters because IAM teams still rely on OTPs as a bridge control, but the control only works when device possession, delivery path, and user behaviour all remain trustworthy.

👉 Read 1Kosmos's article on time-based OTP authentication and MFA risk

Context

Time-based one-time passwords are a familiar MFA pattern, but they are only as strong as the device, delivery channel, and enrolment path behind them. For IAM teams, the real question is not whether OTPs add a factor, but whether the programme is treating possession as a durable trust signal when that possession can be intercepted, stolen, or socially engineered.

This matters across human identity programmes first, but it also carries over into broader identity governance because the same trust assumptions show up in service access, step-up authentication, and privileged workflows. The source article uses OTPs as a bridge to passwordless authentication, but the governance lesson is broader: security improves only when the factor matches the risk, not when the factor simply exists.

Key questions

Q: How should security teams use time-based OTPs without overestimating MFA strength?

A: Security teams should treat TOTP as a useful second factor, not as proof that identity is fully trusted. The control reduces replay and simple phishing risk, but it still depends on device possession, secure enrolment, and a trustworthy recovery process. Stronger methods are needed when the account can cause material business or privileged impact.

Q: Why do OTPs still fail in phishing scenarios?

A: OTPs fail when an attacker can capture and use the live code in real time, or when the delivery channel itself is compromised. SMS, email, and even some push flows can be proxied or socially engineered. The factor narrows the attack window, but it does not eliminate account takeover if the authenticator or session path is weak.

Q: What do organisations get wrong about authenticator security?

A: They often focus on the code format and ignore the lifecycle around enrolment, reset, replacement, and recovery. If those processes are weak, a stolen phone or compromised inbox can be enough to rebind trust. The control only works when the full authenticator lifecycle is governed, not just the login prompt.

Q: How do you decide when to move beyond TOTP?

A: Move beyond TOTP when the access path is privileged, externally exposed, or likely to be targeted by phishing and real-time interception. TOTP can still be appropriate for lower-risk access, but high-impact actions need phishing-resistant authentication and stronger device trust. The decision should follow blast radius, not habit.

Technical breakdown

How time-based OTP generation works

Time-based OTPs, or TOTPs, generate short-lived codes from a shared secret and a synchronized clock. The server and authenticator each compute the same token for a given time interval, so the code changes continuously without user input beyond reading and entering it. That makes the code difficult to reuse, and it gives the verifier a simple way to reject stale tokens. The model is effective because it reduces the utility of intercepted credentials, but only while the shared secret remains protected and the clock remains reasonably aligned.

Practical implication: validate clock drift tolerance and secret protection, not just whether TOTP is enabled.

Why OTP delivery path matters more than the code format

OTP security depends heavily on how the code reaches the user. SMS and email delivery are convenient, but they inherit the risk of the underlying mailbox, phone number, or messaging account. Software authenticators and hardware tokens reduce exposure to transit interception, but they still depend on device security and enrolment integrity. Push flows can improve usability, yet they also shift attention to notification fatigue and approval misuse. In practice, the delivery channel often determines the real attack surface, not the alphanumeric code itself.

Practical implication: treat delivery method as part of the control, not as a neutral transport layer.

Replay resistance and the limits of possession-based trust

TOTP is stronger than static passwords because the token expires quickly, which frustrates replay attacks and reduces the value of captured credentials. But the control still assumes that possession equals legitimate user control of the authenticator. If a phone, token app, or physical key is stolen, the factor can be satisfied by an attacker at the moment of verification. That means TOTP improves authentication assurance, but it does not eliminate identity takeover risk when endpoints or enrolment steps are weak.

Practical implication: pair TOTP with device trust, enrolment verification, and recovery controls.

NHI Mgmt Group analysis

Time-based OTPs are a useful friction layer, not a trust model. TOTP narrows the window for brute-force, phishing, and replay, but it does not change the underlying assumption that possession of a device or authenticator equals legitimate control. That assumption is acceptable for many user journeys, yet it becomes brittle when endpoints are compromised or recovery paths are weak. Practitioners should treat TOTP as one factor in an assurance stack, not as proof that identity is truly bound to the claimant.

The real control boundary is the authenticator lifecycle, not the code itself. The article spends most of its time on token generation, but the operational failure modes sit around enrolment, device replacement, recovery, and loss. A stolen phone, a compromised email inbox, or a poorly verified reset path can all defeat an otherwise sound TOTP design. The practical conclusion is that IAM teams need lifecycle governance for authenticators, not just authentication policy.

Phishing resistance improves only when the factor cannot be easily proxied. TOTPs reduce the effectiveness of simple credential harvesting, but they do not stop real-time interception, adversary-in-the-middle flows, or social engineering that captures the live code. That is why MFA strategy should distinguish between possession factors that are merely second factors and those that materially resist proxy attacks. The practitioner takeaway is to reserve stronger methods for higher-risk access, especially where account takeover would create material blast radius.

Private and permissioned identity architectures are trying to solve a governance problem, not a UX problem. The source article ties OTPs to passwordless authentication and decentralized identity, which reflects a wider market move toward reducing dependence on shared secrets. That shift matters because password reset, device enrollment, and recovery are often the weakest parts of the identity chain. Security teams should evaluate whether the new model actually reduces attack paths or simply relocates them into different trust assumptions.

Time-based OTPs expose the gap between authentication strength and identity assurance. A code that changes every interval can still be produced on an attacker-controlled device if the authenticating identity has already been compromised. The implication is that organisations should stop treating MFA presence as the end state and instead measure whether the factor meaningfully raises attacker cost in the specific access path under review.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding shows that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why detection without revocation does not close the risk window.
• For lifecycle-focused identity teams, the NHI Lifecycle Management Guide is the natural next step for turning authentication choices into governance controls.

What this signals

With 64% of valid secrets leaked in 2022 still valid and exploitable today, the broader lesson is that authentication controls do not end at issuance. The same logic applies to OTP enrolment and recovery: if the binding process is weak, the factor is only as trustworthy as the last account reset.

Authenticator lifecycle debt: the accumulation of weak enrolment, device replacement, and recovery paths that gradually undermine an otherwise sound MFA policy. Teams that only measure login success rates miss the governance failures that happen before and after the prompt, which is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs remains relevant even in human authentication design.

The practical signal to watch is not whether OTP is deployed, but whether the organisation can prove that device binding, reset approval, and recovery access are stronger than the login itself. Where they are not, phishing resistance is being inferred rather than demonstrated.

For practitioners

• Review where OTP delivery creates exposure Map every place the organisation still uses SMS or email OTPs and classify the dependent channels, including mailbox compromise and SIM-swap exposure. Prioritise higher-risk applications for stronger authenticators and remove OTP delivery paths that rely on the same account being protected.
• Harden authenticator enrolment and recovery Require strong identity proofing before binding a new device, and verify recovery events with separate controls from the original login path. A lost phone or compromised inbox should not be enough to re-establish trust without additional checks.
• Set risk-based step-up rules Use TOTP for lower-risk access paths, but escalate to phishing-resistant methods for privileged actions, sensitive data, or external access. Make access policy reflect the business impact of account takeover rather than assuming one MFA pattern fits every journey.
• Measure authenticator lifecycle failures Track how often users replace devices, reset access, or recover accounts through help desk workflows, then test whether those paths are more vulnerable than the login itself. If recovery is weaker than login, the control posture is misleading.

Key takeaways

• Time-based OTPs improve authentication security, but they still depend on a trustworthy device, delivery path, and recovery process.
• The main failure mode is not the code algorithm itself, but weak enrolment, lost devices, and real-time interception of the live factor.
• IAM teams should treat OTP as a transitional control and reserve stronger phishing-resistant methods for higher-risk access.

Key terms

• Time-Based One-Time Password: A time-based one-time password is a short-lived authentication code generated from a shared secret and synchronized clock. The code changes at regular intervals, which makes replay harder, but the control still depends on secure enrolment, protected devices, and trustworthy recovery processes.
• Authenticator Lifecycle: Authenticator lifecycle is the full set of events that create, bind, replace, recover, and retire an authentication factor. For OTP systems, lifecycle weaknesses often matter more than the code algorithm because attackers exploit enrolment, reset, and device loss paths rather than token generation itself.
• Phishing Resistance: Phishing resistance is the degree to which an authentication method remains effective when an attacker can trick a user or intercept the login flow. OTPs improve resistance compared with passwords, but live-code capture, proxy attacks, and weak recovery can still defeat the control.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by 1Kosmos: time-based OTPs, MFA, and identity verification. Read the original.