Who is accountable when organisations keep relying on passwords after repeated credential-based breaches?

Accountability sits with the organisation’s security and identity leadership, because authentication design is a governance decision, not just a technical setting. Teams should assess whether their controls actually verify identity, whether they support phishing resistant MFA, and whether high risk workflows still depend on passwords. If they do, the residual risk remains with the business.

Why This Matters for Security Teams

Repeated password-based breaches are not just a user training problem. They show that the organisation is still treating authentication as a convenience layer instead of a security control with governance, ownership, and measurable risk. Passwords remain easy to phish, replay, reuse, and harvest through malware or credential stuffing, which means they do not reliably prove identity in high-risk workflows. NIST’s Digital Identity Guidelines and the OWASP Non-Human Identity Top 10 both point to stronger identity assurance as the practical alternative.

For security and identity leadership, the accountability question is simple: if passwords are still accepted after a breach, then the residual risk has been accepted, not removed. NHIMG’s research on the 52 NHI Breaches Analysis shows how often compromised credentials and weak identity controls become the entry point for broader abuse. In practice, many security teams discover this only after attackers have already reused stolen passwords, rather than through intentional control testing.

How It Works in Practice

Accountability sits with the leaders who define authentication policy, approve exception handling, and decide when password reliance is tolerated. That usually includes the CISO, IAM leadership, application owners, and risk owners for the workflows that still depend on passwords. The key question is not whether passwords exist somewhere, but whether the organisation has a documented path away from them for sensitive access, admin actions, and external-facing systems.

Operationally, that means mapping where password authentication is still used, ranking those flows by exposure, and replacing them with phishing resistant MFA, device-bound authenticators, or federated identity where possible. For non-human access, the expectation should be even stricter: secrets should be scoped, rotated, and short-lived, not reused as standing credentials. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because the same failure pattern appears in both human and machine identity. When static passwords or API secrets remain in place after compromise, attackers often just come back through the same door.

A practical control stack typically includes:

• Eliminating passwords for privileged and remote access first.
• Enforcing phishing resistant MFA on every high-risk path.
• Using conditional access, session controls, and step-up verification for sensitive actions.
• Auditing exception approvals so risk acceptance is explicit and time bound.
• Measuring whether repeated authentication failures lead to control change, not just incident tickets.

This is also consistent with NIST SP 800-53 Rev. 5, which treats access control and identification as formal security responsibilities rather than ad hoc configuration choices. These controls tend to break down in legacy application estates where password-only authentication is hard-coded into vendor workflows or cannot be replaced without application redesign.

Common Variations and Edge Cases

Tighter authentication controls often increase operational overhead, requiring organisations to balance fraud resistance against login friction and support burden. That tradeoff is real, but it does not change accountability. If a business chooses to keep passwords for a legacy system, the risk owner still needs to document why, how long, and what compensating controls reduce exposure.

There is no universal standard for every environment yet. Best practice is evolving toward passwordless and phishing resistant access for users, while machine and service identities move toward short-lived tokens and workload identity. For example, the Guide to the Secret Sprawl Challenge shows how unmanaged credentials accumulate across CI/CD, cloud, and application layers, making breach recovery harder than the initial compromise.

Edge cases usually involve contractors, shared systems, break-glass accounts, and third-party integrations. In those cases, current guidance suggests compensating controls such as tighter monitoring, just-in-time access, and strong revocation processes, but not permanent exception status. The Cisco Active Directory credentials breach is a reminder that exposed credentials often become enterprise-wide access problems, not isolated account events. Password dependence tends to break down fastest in environments with broad privilege, poor inventory, and no explicit owner for authentication risk.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Who is accountable for wallet trust when organisations rely on certified identity wallets for access decisions?
• What breaks when organisations rely on SMS codes and knowledge-based checks for identity assurance?
• How can organizations prevent NHI-related breaches?