A temporary code used as a second factor in older authentication flows. While better than a password alone, it can still be intercepted, relayed, or phished, which makes it less resilient than modern methods that bind authentication to a device and user presence.
Expanded Definition
Legacy one-time passcode refers to an older second-factor method that issues a short-lived numeric code, often delivered by SMS, email, or an authenticator app, and then asks the user to enter it during sign-in. It is still stronger than a password alone, but it does not automatically prove that the authenticator is the intended person in the way more modern phishing-resistant methods do.
The boundary that matters is not whether the code expires, but whether the flow binds the login to the user’s device, origin, or cryptographic proof. In practice, legacy OTP often covers time-based or event-based codes that can be copied and reused within a narrow window. That is why industry usage is still evolving: some teams treat any OTP as “MFA,” while security programs increasingly distinguish legacy OTP from stronger, device-bound factors. NIST’s control catalog is useful here because it frames authentication as a control objective, not just a login feature, and helps separate factor strength from mere factor presence.
Examples and Use Cases
Legacy OTP still appears in many everyday access paths, especially where older systems, third-party portals, or migration constraints keep the authentication stack unchanged.
- A workforce portal sends a six-digit SMS code after password entry, which is convenient but vulnerable to relay attacks and SIM-based interception.
- A customer support console uses email-delivered passcodes for step-up authentication, which can be practical for low-risk access but weak when email itself is the recovery path.
- A VPN or remote access gateway accepts time-based codes from an authenticator app, which improves over passwords alone but still allows real-time phishing if the attacker can proxy the session.
- A legacy SaaS application enforces OTP as its only second factor because it does not support passkeys or device-bound cryptographic auth, creating a trade-off between compatibility and assurance.
For teams managing large identity estates, NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, which illustrates how often older authentication patterns survive inside broader access ecosystems. That same visibility gap can make it hard to tell which login paths still depend on weaker factors.
Security Implications
Legacy OTP fails most often when organisations confuse “a second factor exists” with “the authentication is phishing-resistant.” The code can be intercepted in transit, coerced from the user in real time, or replayed fast enough to complete a malicious session before it expires. That means the control may reduce casual password-only abuse while still leaving room for adversary-in-the-middle phishing, account takeover, and session hijacking.
The operational symptom is usually a gap between policy and actual assurance: the directory says MFA is enabled, but the method cannot reliably bind the authenticator to the session. In high-value environments, that difference matters because one compromised login can expose email, VPN, admin consoles, or downstream application privileges. Legacy OTP also creates recovery and help-desk pressure, since users who lose access often rely on weaker fallback paths. NHIMG reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which is a useful reminder that weak authentication and weak secret handling often appear together in the same access chain.
Domain and Governance Relevance
In identity governance, legacy OTP is best treated as a transitional control rather than a long-term assurance target. It may still be acceptable for low-risk access, constrained user populations, or short migration windows, but it does not provide the same confidence as device-bound authentication where the factor is harder to intercept and relay. That distinction affects policy, exception handling, and how security teams describe “MFA coverage” to leadership.
For NHI-adjacent environments, the lesson is broader: if human authentication is still relying on legacy OTP, the organisation is often also tolerating older patterns elsewhere in the access stack, including weak recovery, shared credentials, or thin lifecycle oversight. NHIMG’s guidance on non-human identity governance is relevant because mature access programmes tend to replace brittle, reusable secrets with stronger lifecycle controls and clearer ownership. If the login method cannot survive a phishing relay, the surrounding governance model should assume a lower trust posture and compensate accordingly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Legacy OTP is an authentication method governed by access control assurance. |
| Recommendation — Prefer stronger authentication methods and limit legacy OTP to lower-risk access. | ||
| NIST SP 800-63 | AAL — Authentication Assurance Level | Legacy OTP maps to weaker authenticator assurance than phishing-resistant methods. |
| Recommendation — Assess whether OTP meets the required assurance level for each login use case. | ||
| CIS Controls v8 | 5 — Account Management | OTP choice affects account authentication strength and fallback access paths. |
| 6 — Access Control Management | Legacy OTP influences who can obtain and use access to protected systems. | |
| Recommendation — Review account authentication methods and remove weak fallback routes where possible. Enforce stronger access controls for systems that still rely on OTP-based login. | ||
| MITRE ATT&CK | T1111 — Multi-Factor Authentication Interception | Legacy OTP can be phished, relayed, or intercepted in real time. |
| Recommendation — Hunt for MFA interception patterns and prioritize phishing-resistant authentication. | ||
