Subscribe to the Non-Human & AI Identity Journal

Why do passwords still persist even when organisations know they are risky?

Passwords persist because migration is operationally hard, not because the risk is unclear. Organisations worry about change management, legacy integration, staffing, and the perceived cost of replacing existing controls. Those barriers keep reusable secrets in place longer than security teams intend, which means the risk becomes a governance issue as much as an authentication issue.

Why This Matters for Security Teams

Passwords persist because they are embedded in workflows, legacy systems, and operational assumptions that teams cannot replace overnight. The risk is not theoretical: reusable secrets are still widely exposed in code, configs, CI/CD, and ad hoc tooling, and NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks shows how often governance gaps turn into real exposure. The issue is less about awareness and more about sequencing change safely, especially where business-critical systems still depend on static credentials.

That is why password risk should be viewed through governance, not just authentication design. The NIST Cybersecurity Framework 2.0 treats identity and access as an ongoing risk management problem, which fits the real world better than assuming every legacy login can be retired on demand. In practice, many security teams encounter password sprawl only after a breach, audit failure, or failed migration has already exposed how many systems still depend on it.

How It Works in Practice

Replacing passwords usually happens in layers, not as a single cutover. Security teams first map where passwords exist, who or what uses them, how they are stored, and which systems break if they are removed. That inventory often reveals both human authentication and non-human use cases, including service accounts, automation jobs, and API integrations that were never designed for modern identity controls. NHIMG’s Top 10 NHI Issues is useful here because it frames the operational problems that keep reusable secrets alive.

In practice, mature programmes try to reduce password dependence by combining:

  • Single sign-on and phishing-resistant authentication for humans
  • Workload identity for systems that need machine-to-machine trust
  • Secrets managers for storage, rotation, and revocation of legacy credentials
  • Just-in-time access and short-lived tokens where static access can be removed
  • Policy checks and approvals for the few remaining exceptions

For many teams, the key is not “delete passwords everywhere” but “eliminate them where the business can safely absorb the change.” That means aligning remediation to asset criticality, dependency chains, and operational ownership. The strongest programmes treat password removal as a lifecycle effort tied to service retirement, application modernization, and privileged access reduction, rather than a one-time hardening task. These controls tend to break down in distributed environments with unmanaged integrations because no single owner can safely unwind every dependency at once.

Common Variations and Edge Cases

Tighter password controls often increase migration overhead, requiring organisations to balance immediate risk reduction against application stability and user friction. That tradeoff is real, especially for long-lived platforms, third-party integrations, and industrial or regulated environments where change windows are narrow and rollback is expensive.

Current guidance suggests prioritising replacement over perfecting password policy when the underlying system can support stronger identity controls. For older systems that cannot be modernised quickly, teams often rely on compensating measures such as MFA, vaulting, rotation, network restriction, and tighter monitoring. The important distinction is that these are temporary controls, not a durable end state.

There is also a common edge case in non-human identities: some teams assume service account passwords are “safe” because no person types them in. In reality, static secrets used by automation are often easier to copy, leak, and reuse than human passwords. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now highlights how scale and visibility gaps make this worse as environments grow.

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 CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Covers weak rotation and reuse of secrets that keep passwords alive.
NIST CSF 2.0 PR.AC-1 Identity proofing and access control are central to reducing password dependence.
NIST CSF 2.0 PR.DS-1 Secret protection matters where passwords persist in code, config, and tooling.

Map password removal to access-control improvements and retire legacy login paths by risk.