Teams often assume app-based TOTP is inherently phishing resistant because it is not sent over a mobile network. That is only partly true. If attackers can use a real-time proxy, steal the device, or socially engineer the code, TOTP still fails as a high-assurance method.
Why This Matters for Security Teams
App-based TOTP is often treated as a safer fallback because it is generated on the device rather than delivered over SMS, but that framing overstates its assurance. TOTP can still be intercepted through real-time phishing, harvested from a compromised phone, or relayed through an attacker-controlled session. That makes it a shared-secret factor with limited resistance to modern adversary-in-the-middle attacks, not a high-assurance proof of user presence.
This matters because teams commonly design access policy around the label of the factor instead of the threat model behind it. A code that expires in 30 seconds still fails if an attacker can prompt the user in the moment and replay the code immediately. The difference between “better than SMS” and “phishing resistant” is operationally significant, especially for privileged access, admin consoles, and remote workforce access. Current guidance from the NIST Cybersecurity Framework 2.0 supports risk-based identity controls, not blind trust in one mechanism. In practice, many security teams discover TOTP weakness only after an attacker has already used a valid code to enter a trusted session.
How It Works in Practice
App-based TOTP works by sharing a secret seed between the authenticator app and the verifier, then generating a time-based one-time code from that seed. The code changes frequently, but the seed itself is long-lived unless the account is reset. That is why TOTP is still vulnerable when the attacker can obtain the code in real time or compromise the device where the app lives. For high-risk access, the issue is not whether the code was “sent over the air,” but whether the factor resists interception, replay, and social engineering.
Security teams usually get better results when they treat TOTP as one control in a layered identity design rather than as a phishing-resistant endpoint. Practical improvements include:
- reserving TOTP for lower-risk use cases and step-up access, not privileged administration;
- pairing it with device signals, conditional access, and session risk checks;
- preferring NHI management guidance from NHI Mgmt Group for understanding how identity assurance breaks when secrets are reused or long-lived;
- moving privileged users toward phishing-resistant authenticators such as hardware-backed methods where policy allows.
In the real world, this is less about code generation and more about whether the authentication flow can be proxied, coerced, or replayed before the session is established. The NIST Cybersecurity Framework 2.0 encourages stronger access governance, while NHIMG research shows how often identity controls fail when assumptions about trust do not match actual attacker behaviour. The Schneider Electric credentials breach is a useful reminder that identity compromise often succeeds through process gaps rather than technical novelty. These controls tend to break down in environments with unmanaged endpoints and remote access flows because the attacker can capture the live OTP before the verifier sees any sign of fraud.
Common Variations and Edge Cases
Tighter authentication usually increases user friction and help desk load, so organisations have to balance assurance against operational disruption. That tradeoff becomes especially visible when users depend on personal mobile devices, travel frequently, or work in regions with inconsistent connectivity.
Best practice is evolving, and there is no universal standard that says TOTP must be banned everywhere. For some low-risk applications, app-based TOTP remains acceptable when paired with good account recovery, anomaly detection, and fast revocation. For administrative access, however, many security teams now treat it as insufficient on its own because real-time proxy attacks can defeat it without ever exposing the underlying secret.
Another edge case is recovery. If the fallback path is weaker than the original factor, attackers will target reset workflows instead of the TOTP app itself. Teams should also distinguish between user authentication and device authentication, since a valid OTP does not prove the endpoint is trustworthy. NHIMG guidance on lifecycle control in the Ultimate Guide to Non-Human Identities reinforces a broader point: security fails when credentials outlive the conditions they were meant to protect. In practice, TOTP breaks down most often in help-desk-driven recovery chains and high-speed phishing campaigns, where the attacker controls the timing and the user only sees a legitimate-looking prompt.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Identity authentication choices must reflect actual phishing and replay risk. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Long-lived shared secrets behind TOTP mirror the credential risks seen in NHI systems. |
| NIST AI RMF | Risk governance helps teams assess when TOTP assurance is insufficient for access decisions. |
Reduce reliance on reusable secrets and tighten lifecycle controls around authentication material.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
