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.
Why TOTP Still Has a Place in an MFA Stack
Time-based OTPs are not the end state for phishing resistance, but they still raise the cost of opportunistic attack. They help block simple password reuse, brute-force guessing, and replay of stolen passwords, and they are easy to deploy across mixed user populations. That makes TOTP useful where adoption speed matters more than maximal assurance.
TOTP also fills gaps while stronger methods are being rolled out. Many organisations cannot move every user, device, and recovery path to passkeys or hardware-backed authentication at once, so a time-based factor remains a pragmatic step up from password-only access.
Where TOTP Fits Relative to Phishing-Resistant MFA
The practical distinction is assurance depth, not whether TOTP has value. A time-based code proves the user has the shared secret and the current time window, but it does not reliably resist adversary-in-the-middle phishing or session theft in the way that NIST SP 800-63 Digital Identity Guidelines describes for phishing-resistant authenticators. For that reason, TOTP is best treated as a transitional or lower-assurance step, not as the finish line.
That does not make it obsolete. In many environments, especially large workforces, contractors, and lower-risk applications, TOTP still meaningfully reduces account takeover risk compared with passwords alone. It is also often easier to support at scale than methods that depend on device binding, browser support, or more complex enrollment flows.
TOTP is strongest when the goal is to raise baseline authentication quality quickly. It is weakest when the threat model includes targeted phishing, help desk social engineering, token theft, or high-value administrative access. In those cases, organisations should separate “good enough to reduce broad abuse” from “strong enough to resist modern phishing campaigns.”
How to Use TOTP Without Mistaking It for Phishing Resistance
Think of TOTP as a control that improves the common case while you migrate critical access paths to stronger authenticators. It works well for general workforce sign-in, low-risk applications, and as a fallback factor where user friction would otherwise block adoption. It should not be the default end state for privileged users or the only factor protecting sensitive systems.
That staged approach aligns with the way mature identity programmes are built. MFA Guide and Workforce Identity Security Guide both support the same operational pattern: use a broadly adoptable factor to reduce exposure now, then reserve phishing-resistant methods for the users and systems where compromise would be most costly.
Recovery paths are the part most teams underestimate. If a phishing-resistant rollout still allows weak resets, fallback SMS, or poorly governed help desk recovery, the overall assurance level collapses to the weakest path. TOTP can be acceptable in a mixed environment, but only if account recovery, step-up access, and privileged workflows are being hardened in parallel.
Risk and Threat Considerations
TOTP reduces exposure to some routine attacks, but it does not stop the main phishing and session-theft patterns that make MFA bypass effective. The risk is that organisations treat “has MFA” as a binary achievement and leave high-value access, recovery flows, or legacy sign-in paths exposed to adversary-in-the-middle phishing, OTP relay, or fatigue-driven abuse.
Failure mechanism: Attackers capture or relay a valid time-based code, or they avoid it entirely by targeting a weaker recovery path, a legacy login, or a session token that persists after sign-in.
Impact: The account can still be taken over even though MFA is technically enabled, which is why TOTP improves baseline security but does not by itself deliver phishing resistance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines assurance levels and phishing-resistant authentication relevant to TOTP limits |
| Recommendation — Use phishing-resistant authenticators for high-value access paths and treat TOTP as lower-assurance transitional protection. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Covers limiting and strengthening authentication for sensitive access paths |
| Recommendation — Restrict stronger authentication requirements to privileged and high-risk accounts first. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Applies to authenticating workforce users and selecting appropriate factors |
| IA-5 — Authenticator Management | Directly covers lifecycle and handling of OTP authenticators and related secrets | |
| Recommendation — Require stronger authentication for users whose compromise would create material impact. Manage OTP authenticators with rotation, protection, and controlled recovery procedures. | ||
| OWASP ASVS | V6 — Authentication | Addresses authentication strength, MFA, and resistant sign-in design in applications |
| Recommendation — Verify that application sign-in paths use stronger factors where phishing resistance matters most. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Covers secret-based authentication weaknesses that can affect OTP-like factors |
| Recommendation — Eliminate brittle shared-secret sign-in paths where stronger authenticators are feasible. | ||
Practitioner Guidance
What to prioritise: Use TOTP where it meaningfully raises the floor, then move administrators, break-glass access, and sensitive applications to phishing-resistant methods first. If the account can approve money movement, admin changes, or production access, TOTP should be treated as temporary rather than final.
What to verify: Check the weakest path, not the strongest one. Confirm that account recovery, help desk resets, and legacy authentication routes are not quietly undermining the assurance you think MFA provides.
Practitioner takeaway: TOTP is valuable when it closes a real gap quickly, but it should be measured as an incremental control, not as proof that phishing-resistant authentication has been achieved.
Related resources from NHI Mgmt Group
- Why do phishing-resistant MFA methods matter if attackers can still get in?
- What is the difference between phishing-resistant MFA and Just-in-Time access in browser-based attack defence?
- What is the difference between push-based MFA and phishing-resistant authentication?
- Why do phishing-resistant MFA controls still fail against social engineering?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org