Passwords and one-time passcodes fail because they are reusable, easy to phish, and vulnerable to social engineering, interception, and user fatigue. In consumer environments, friction also causes abandonment when login feels slow or repetitive. Security teams should treat them as weak standalone controls and use stronger identity signals for account opening, login, and servicing.
Why This Matters for Security Teams
Passwords and one-time passcodes look familiar, but familiarity is not assurance. In high-risk digital journeys such as account opening, login, recovery, and servicing, attackers target the weakest step in the chain: credential reuse, phishing, SIM swap, help-desk social engineering, or session hijack. That is why guidance from the NIST Cybersecurity Framework 2.0 and control-driven approaches like Top 10 NHI Issues both push teams toward stronger, risk-based identity signals rather than single-factor gatekeeping.
The practical problem is not just breach probability. It is journey failure. If authentication is easy to replay, easy to phish, or easy to fatigue into acceptance, then the control can be bypassed without raising meaningful friction to the right actor. In consumer and employee environments alike, that creates a false sense of security while still leaving high-value actions exposed. In practice, many security teams encounter compromise only after a password reset, OTP interception, or support-channel takeover has already occurred, rather than through intentional design.
How It Works in Practice
High-risk journeys need authentication that reflects both the user and the transaction. Static passwords prove little beyond shared knowledge, and OTPs mainly prove access to a channel that may itself be compromised. Current guidance suggests using them only as part of a layered flow, not as the primary trust anchor. The stronger pattern is to combine risk signals, device binding, behavioral checks, and step-up authentication so that access decisions are made at the moment of action, not assumed from a prior login.
For teams mapping this to implementation, the operational shift usually looks like this:
- Replace password-only entry points with phishing-resistant methods where possible.
- Use OTPs as fallback or step-up, not as the default proof of identity.
- Bind sessions to trusted devices and detect anomalous recovery or enrollment attempts.
- Apply stricter controls to sensitive actions such as beneficiary changes, payout approvals, or credential resets.
This aligns with security baselines in NIST SP 800-53 Rev 5 Security and Privacy Controls, and it mirrors the risk pattern documented in The 2024 ESG Report: Managing Non-Human Identities, where compromised identities frequently lead to repeated incidents rather than one-off events. For adjacent identity abuse patterns, NHIMG also documents how exposed secrets and rapid attacker follow-on activity turn weak access controls into fast-moving compromise in the OWASP NHI Top 10. These controls tend to break down when account recovery, call-center verification, or SMS delivery is the only fallback because those channels are routinely targeted before the core login is ever defeated.
Common Variations and Edge Cases
Tighter authentication often increases abandonment and support load, so organisations must balance fraud reduction against conversion, accessibility, and recovery risk. That tradeoff is especially sharp in consumer banking, healthcare portals, and any journey where users switch devices or lose channel access frequently.
There is no universal standard for this yet, but best practice is evolving toward assurance by context. Low-risk browsing can tolerate lighter checks, while payments, data export, profile changes, and recovery should trigger stronger verification. OTPs may still be acceptable as a secondary signal in some regulated flows, but they should not be treated as phishing-resistant or as a durable primary factor. Teams should also be careful not to overcorrect: adding too many steps can create help-desk dependency, which becomes its own attack surface.
For organisations using federated login, legacy IAM, or mixed mobile and web journeys, the safest path is to treat password and OTP coverage as transitional, then progressively move critical steps toward stronger methods and runtime risk evaluation. That is usually the point where security, fraud, and product teams stop arguing over a single factor and start governing the whole journey.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Addresses identity proofing and access assurance for risky user journeys. |
| NIST SP 800-63 | Digital identity guidance explains why phishable factors are weak primary assurance. | |
| NIST SP 800-53 Rev 5 | IA-2 | Primary authentication controls must resist replay, phishing, and interception. |
| NIST AI RMF | GOVERN | Risk-based identity decisions depend on governance over assurance and recovery paths. |
Strengthen assurance for sensitive journeys and step-up actions based on risk, not just password entry.
Related resources from NHI Mgmt Group
- How should financial institutions reduce reliance on SMS one-time passcodes for customer authentication?
- What is the difference between SMS one-time passcodes and mobile network based authentication?
- Why do one-time codes fail for high-risk financial approvals?
- Why do passwords and one-time codes fail as the primary basis for enterprise identity assurance?
