Why do passwords and one-time codes fail as the primary basis for enterprise identity assurance?

Why This Matters for Security Teams

Passwords and one-time codes look familiar, but they were designed to assert control over a secret, not to deliver strong identity assurance. That distinction matters because enterprise access decisions increasingly gate privileged SaaS, CI/CD, admin consoles, and AI-enabled tooling. NIST’s NIST SP 800-63 Digital Identity Guidelines makes clear that assurance depends on how an authenticator is bound, verified, and protected, not just on whether a code was entered correctly.

In real environments, the weaknesses are operational, not theoretical. Users reuse passwords, attackers phish OTPs in real time, help desks reset credentials under pressure, and shared accounts collapse any meaningful link between a login and a specific person. The same pattern appears in non-human access: the Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into service accounts, while 80% of identity breaches involved compromised non-human identities. In practice, many security teams encounter identity compromise only after a legitimate login has already been abused for lateral movement or privilege escalation, rather than through intentional assurance testing.

How It Works in Practice

Primary identity assurance should be anchored in stronger authenticators, phishing-resistant flows, and continuous context checks. For humans, current guidance increasingly favours mechanisms that bind the authentication event to the device and session, not just a short-lived secret. That usually means passwordless methods, hardware-backed authenticators, and step-up controls for high-risk actions, aligned to the risk-based thinking in NIST SP 800-63 Digital Identity Guidelines and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

For non-human identities, the control model shifts even more sharply. An API key, token, or certificate is a workload credential, not proof of a person, and it should be treated as a scoped operational secret with lifecycle controls. NHIMG research in the Ultimate Guide to NHIs highlights why: secrets linger, privileges sprawl, and visibility is limited. The practical response is to reduce dependence on static secrets, issue short-lived credentials where possible, and bind access to workload identity, environment, and policy conditions. That means:

• Use phishing-resistant authenticators for human administrators and sensitive workflows.
• Require device, session, and risk signals before granting privileged actions.
• Prefer short-lived, automatically rotated credentials over reusable secrets.
• Separate human identity from workload identity so service access is not masquerading as user trust.

This model works best when the verifier can evaluate context at the moment of access and revoke trust quickly after the session changes. These controls tend to break down in legacy SSO chains, shared admin accounts, and systems that cannot distinguish a human from a script because they were built around password checks rather than assurance signals.

Common Variations and Edge Cases

Tighter authentication often increases user friction and operational overhead, so organisations must balance assurance against support cost and business continuity. There is no universal standard for every workforce or application tier yet, especially where offline access, regulated call centres, or emergency break-glass workflows are involved.

Some environments still rely on OTPs as a backup factor, but best practice is evolving toward using them only as a fallback, not as the primary trust anchor. OTPs remain vulnerable to phishing proxies, SIM swap attacks, session replay, and social engineering at the help desk. In high-risk environments, the better pattern is layered assurance: strong primary authentication, conditional access, privileged access management, and separate controls for secrets handling. The NHIMG 52 NHI Breaches Analysis and Top 10 NHI Issues both underscore the same lesson: credential strength alone does not solve identity misuse when lifecycle, scope, and revocation remain weak.

Where identity platforms still depend on shared service accounts, legacy VPNs, or static API secrets embedded in build pipelines, passwords and OTPs become an incomplete shield rather than an assurance model. The gap is most visible when attackers authenticate successfully and then use legitimate sessions to access what the original login should never have reached.

Related resources from NHI Mgmt Group

• Why do passwords and one-time codes still leave organisations exposed to identity fraud?
• Why do usernames, passwords, and one-time codes create weak assurance in modern authentication flows?
• Why do SMS and email one-time passwords remain risky for enterprise access?
• Why do Duo OTPs and similar one-time codes still fail against phishing?