Why do passwords and basic MFA still fail in real breaches?

Why This Matters for Security Teams

Passwords and basic MFA still fail because they authenticate a moment, not a trustworthy actor or a trustworthy intent. Attackers rarely need to crack the factor when they can replay a session, proxy a prompt, abuse recovery flows, or trick a user into approving a push. That is why NHI Management Group treats secret exposure as a systemic control failure, not a user mistake, especially when the same pattern shows up in both human and machine access paths. The risk becomes sharper when credentials are reused across SaaS, cloud, and AI tooling, as shown in the 52 NHI Breaches Analysis and the Microsoft Midnight Blizzard breach.

For security teams, the operational lesson is that password policy and basic MFA are necessary but not sufficient. NIST SP 800-63 makes clear that authenticators have different assurance properties, and phishing-resistant factors are materially stronger than SMS or approval-based methods. In practice, the gap appears when a valid login becomes a reusable foothold, then the breach expands through cloud consoles, API tokens, and delegated access. In practice, many security teams encounter the weakness only after a session has already been replayed or a help desk flow has already been abused, rather than through intentional testing.

How It Works in Practice

The real problem is that basic MFA protects the front door while attackers use the side windows. If a password is phished, relayed, or bought, and the second factor is a push approval, OTP, or recovery channel, the adversary can often complete the same workflow the user would. Once inside, they do not need to stay on the original login path. They can export session cookies, create app passwords, add new devices, mint tokens, or pivot into NHI-managed services. That is why the control model must move from static login trust to continuous, contextual verification.

Current guidance suggests combining phishing-resistant MFA with short-lived sessions, device posture checks, and step-up authentication for sensitive actions. For machine access, the better primitive is workload identity, not shared secrets. Standards such as SPIFFE and the policy model described in NIST SP 800-207 support cryptographic identity and decisioning at request time. That matters because the actor and the action must both be evaluated. A user who can read email may not be allowed to approve a fund transfer, and an agent that can query a database should not also be able to change its schema.

• Prefer phishing-resistant MFA such as FIDO2/WebAuthn for interactive users.
• Replace long-lived shared secrets with short-lived, scoped credentials.
• Bind access to device, workload, and session context where possible.
• Use real-time policy checks for privileged or irreversible actions.

This approach aligns with broader NHI guidance in the Ultimate Guide to NHIs and the threat patterns documented in the DeepSeek breach. These controls tend to break down in environments that still rely on legacy VPN access, long-lived service account passwords, or approval-based MFA tied to shared help desk recovery processes because those paths create durable replay opportunities.

Common Variations and Edge Cases

Tighter authentication often increases friction, requiring organisations to balance user convenience against the much higher cost of credential replay and session theft. There is no universal standard for every MFA scenario yet, especially where regulated workloads, break-glass access, or third-party support accounts are involved. Current guidance suggests treating these as exception paths with tighter monitoring, not as normal access patterns. That is especially important when contractors, admins, and automation all share the same control plane.

One common edge case is the “mfa fatigue” or push bombing scenario, where basic MFA creates more prompts than signal. Another is service-to-service access, where human MFA does not apply at all and secrets are often copied into scripts, CI/CD pipelines, or agent workflows. In those cases, the right question is not whether a password plus MFA exists, but whether the access should exist at all, for how long, and under what runtime conditions. The Anthropic report on AI-orchestrated cyber espionage reinforces why static assumptions fail once automation can chain actions faster than a human can intervene.

For organisations modernising identity controls, the practical takeaway is to retire reusable secrets wherever possible, phase out weak MFA methods, and enforce per-session or per-task trust decisions. The most resilient environments are the ones that assume a password will be exposed and design so that exposure does not automatically equal compromise.

Related resources from NHI Mgmt Group

• Why do weak MFA deployments still lead to major breaches?
• Why do complex passwords still fail in real environments?
• Why do still-valid secrets matter after public disclosure?
• Why do MFA controls still fail against account takeover?