Why do passwords and OTPs create persistent risk in enterprise identity programmes?

Why This Matters for Security Teams

Passwords and OTPs look familiar, but familiarity is not resilience. In enterprise identity programmes, they create a durable attack surface because they depend on human memory, user behaviour, and repeated challenge prompts that attackers can manipulate. Once credentials are phished, reused, or socially engineered, the security model often degrades into who can be tricked fastest rather than who should be trusted. NIST’s Cybersecurity Framework 2.0 treats identity as a core control plane, yet many organisations still anchor access decisions to factors that are easy to intercept, relay, or fatigue into approval.

That risk becomes especially visible when secret sprawl and weak governance intersect. NHIMG’s Ultimate Guide to NHIs shows how common it is for organisations to store credentials outside managed systems, which is a useful reminder that authentication weaknesses rarely stay isolated to one login flow. For identity teams, the practical problem is not just one compromised password, but the way the same weak pattern propagates across cloud apps, admin portals, scripts, and service access paths. In practice, many security teams discover the breadth of password and OTP exposure only after a phishing chain or MFA-bypass incident has already turned into account takeover.

How It Works in Practice

The operational issue is that passwords and OTPs authenticate a moment, not a trustworthy device, workload, or session. A password proves only that someone knows a shared secret. An OTP proves that a code was received or generated, but not that the endpoint presenting it is trustworthy, uncompromised, or resistant to relay attacks. This is why current guidance increasingly favours phishing-resistant authentication, device-bound credentials, and stronger session controls rather than repeated prompts that simply add friction.

In mature programmes, teams reduce persistent risk by layering controls around the login event:

• Replace reusable secrets with phishing-resistant methods where possible, such as cryptographic authenticators that bind the session to a device.
• Limit OTP use to lower-risk or transitional scenarios, then phase toward stronger methods for privileged and remote access.
• Shorten session lifetimes and re-evaluate trust when risk changes, rather than assuming the original login remains valid indefinitely.
• Monitor for impossible travel, prompt fatigue, token replay, and suspicious approval patterns that indicate identity abuse.

This is also where NHIMG research matters operationally. The patterns documented in the 52 NHI Breaches Analysis and the JetBrains GitHub plugin token exposure reinforce a broader lesson: once a secret is portable, it becomes shareable, replayable, and hard to contain. Passwords and OTPs extend that portability to human identity flows, which is why the security outcome often depends more on detection and recovery than on the authentication method alone. These controls tend to break down in hybrid environments with legacy apps, shared admin accounts, and help-desk reset workflows because those conditions preserve fallback paths that attackers can abuse.

Common Variations and Edge Cases

Tighter authentication often increases user friction and support load, requiring organisations to balance stronger assurance against operational continuity. That tradeoff is real, especially in environments with contractors, frontline staff, or legacy systems that cannot yet support modern authenticators. There is no universal standard for every application path, so best practice is evolving toward risk-based segmentation rather than a single rule for all users.

One common exception is recovery. Even strong authentication can be undermined if password reset, OTP fallback, or service desk verification remains weak. Another edge case is third-party access, where partner portals and shared support channels often lag behind internal identity standards. In those contexts, identity teams should treat fallback workflows as production attack paths, not administrative conveniences. The Top 10 NHI Issues illustrates the same governance gap from a non-human perspective: security controls fail when ownership, lifecycle, and revocation are unclear. For human identity programmes, the equivalent fix is to remove static secrets, reduce recovery exceptions, and make stronger authentication the default for high-value access. Organisations that still rely on password resets plus OTPs as the main safety net usually find that the safety net is exactly where attackers land.

Related resources from NHI Mgmt Group

• Why do passwords create persistent identity risk even in mature IAM programmes?
• Why do connected devices create identity risk for enterprise programmes?
• Why do account takeovers create such a large risk for enterprise identity programmes?
• Why do public MCP servers create risk for enterprise identity programmes?