How do you decide when to move beyond TOTP?

Why This Matters for Security Teams

totp is better than passwords alone, but it was never designed to stop real-time phishing, adversary-in-the-middle interception, or session theft on privileged workflows. The decision to move beyond it should be based on the blast radius of the action, not whether the login page still “works.” NIST guidance increasingly treats stronger authentication as a core risk control, not an optional hardening step, as reflected in the NIST Cybersecurity Framework 2.0.

For NHI and high-value access paths, the same pattern appears repeatedly: once attackers capture a code, they can replay it inside the active window and move directly into the session. That is why NHI Management Group research on the ultimate guide to non-human identities places strong emphasis on privilege, rotation, and exposure rather than convenience alone. In practice, many security teams encounter TOTP failure only after a credential replay or session hijack has already occurred, rather than through intentional authentication design.

How It Works in Practice

The practical test is straightforward: ask what an attacker could do if they intercepted the second factor. If the answer is “read email,” “view a low-risk dashboard,” or another limited action, TOTP may still be acceptable. If the answer is “approve payments,” “change identity policy,” “access production secrets,” or “execute code,” then the control needs to move to phishing-resistant authentication and tighter device trust.

Current best practice is to pair the authentication decision with the sensitivity of the session, not just the user. That usually means using WebAuthn or FIDO2-style phishing-resistant methods, device-bound trust signals, and step-up checks for high-impact actions. In environments with NHIs and automation, the same logic applies to workload access: short-lived credentials, explicit scope, and runtime enforcement matter more than reusable secrets. This is consistent with guidance in NHI Mgmt Group research on NHIs and implementation approaches such as the SPIFFE Project, which emphasizes cryptographic workload identity instead of shared secrets.

• Keep TOTP for low-impact access where the consequence of compromise is contained.
• Require phishing-resistant MFA for privileged consoles, admin actions, and externally exposed workflows.
• Use step-up authentication when a session crosses into sensitive operations.
• Prefer device trust and session binding where the platform supports it.
• For service-to-service and agentic access, replace static secrets with short-lived workload identity and JIT credentials.

These controls tend to break down when legacy applications only support shared secret flows because the organisation cannot enforce stronger authentication without a platform change.

Common Variations and Edge Cases

Tighter authentication often increases user friction and rollout cost, so organisations have to balance stronger protection against operational disruption. That tradeoff is real, especially for distributed teams, contractors, and mixed legacy environments where not every application can support modern phishing-resistant methods at once.

There is no universal standard for every edge case yet, but current guidance suggests treating TOTP as a transitional or lower-assurance option rather than the default for sensitive access. For example, TOTP may remain acceptable for low-risk internal tools, whereas privileged admin portals, remote access, and identity administration should move to stronger factors sooner. Attack patterns documented in incidents such as the Schneider Electric credentials breach and JetBrains GitHub plugin token exposure show why exposed secrets and reusable codes are especially risky once an attacker can intercept or reuse them.

The practical rule is to upgrade where the blast radius is highest, then phase the rest by application capability, user risk, and exposure path.

Related resources from NHI Mgmt Group

• How should organisations move beyond password-based digital identity?
• How do you know if AI token controls are actually working?
• How do organisations decide when to require biometric verification versus other proofing methods?
• How should security teams decide where to use syncable passkeys versus device-bound keys?