Cisco data breach lessons: MFA fatigue and stolen credentials

At a glance

What this is: Axiad’s analysis of the Cisco data breach shows how stolen credentials, MFA fatigue, and vishing combined to defeat account protection.

Why it matters: It matters because the same weaknesses affect human identity programmes, NHI access paths, and any environment that still treats authentication as a one-step control.

By the numbers:

• 17 minutes.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Axiad's analysis of the Cisco data breach and MFA fatigue

Context

Cisco’s breach analysis is really about authentication failure under pressure. An initial access broker used stolen credentials, push-notification spam, and vishing to get the employee to approve a request, which shows how account security breaks when humans are the final control point.

For IAM teams, the broader issue is not whether MFA exists but whether the chosen factor can survive social engineering and fatigue. That question applies to user logins, delegated access, and any process that still depends on a person saying yes at the right moment.

Key questions

Q: What breaks when push-based MFA is the main control for privileged access?

A: Push-based MFA breaks down when attackers can flood users with prompts or impersonate support staff into approving one. The control still works technically, but the human approval step becomes the weak point. For privileged access, that means attackers can convert authentication into persuasion, which is not a stable assurance model for high-value accounts.

Q: Why do stolen credentials still matter in environments with MFA?

A: Stolen credentials matter because they are often the first step in a chain that ends with social engineering or MFA fatigue. Once the attacker has a valid username and password, they only need one weak factor or one confused user. MFA reduces risk, but it does not remove the value of credential theft as an entry method.

Q: How can security teams measure whether MFA is resisting abuse?

A: Teams should watch for repeated prompts, unusual registration changes, help-desk impersonation reports, and successful approvals outside normal user behaviour. If a control is being triggered often enough to frustrate users, attackers can exploit that pressure. A resistant MFA programme should show low abuse volume, not just high deployment coverage.

Q: Who is accountable when a user approves a malicious authentication request?

A: Accountability sits with the organisation’s identity governance, not only with the individual user. If the process depends on user judgement under stress, the architecture has already accepted a fragile control point. Frameworks such as the NIST Cybersecurity Framework and Zero Trust architecture expect stronger verification than a single coerced approval.

Technical breakdown

Stolen credentials as the entry point

The breach began with compromised credentials, which remain the most common way attackers enter an account. Once username and password are known, the attacker only needs a weak second factor or a user who can be manipulated into approving access. In this case, credential theft was not the end state. It was the opening move that created a path to interactive account takeover. The technical lesson is that password compromise still matters even in MFA-enabled environments because authentication chains are only as strong as the least resistant factor in them.

Practical implication: eliminate password-only trust assumptions and prioritize phishing-resistant authentication for high-value user accounts.

MFA fatigue and push approval abuse

Push-based MFA creates a human decision point that attackers can exhaust. By sending repeated requests, the attacker turns authentication into noise, then waits for the user to approve the prompt just to stop the interruptions. That makes the control fragile under stress rather than resilient by design. Push prompts are also vulnerable because they can be socially engineered in real time, especially when users think the request is routine or help-desk related. The protocol did not fail cryptographically; it failed behaviorally.

Practical implication: reduce or remove push approval as a primary factor for sensitive access and restrict where push enrollment is allowed.

Vishing turns identity into a social engineering target

Voice phishing works because it redirects trust from the system to the attacker’s story. In the Cisco case, the adversary used impersonation and coercion to convince the employee that the prompt was legitimate. That means identity security is not just about authenticators but about the conditions under which a human will approve them. Training helps, but the bigger architectural issue is that any factor requiring user consent can be manipulated if the approval step is easy to socially engineer. The control surface is the person, not just the device.

Practical implication: pair user training with approval friction, device binding, and monitoring for unusual registration or push activity.

Threat narrative

Attacker objective: The attacker aimed to obtain interactive access to the employee account and use that foothold to compromise data and move deeper into the environment.

1. Entry occurred through stolen employee credentials obtained by an initial access broker tied to cybercrime ecosystems.
2. Escalation came from MFA fatigue and vishing, which coerced the employee into approving a push notification and bypassing the intended second factor.
3. Impact was account compromise with exposure of the employee’s data and a demonstrated path past the organisation’s existing authentication controls.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• New York Times breach — New York Times source code and credentials exposed via GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishing-resistant authentication is now a governance baseline, not an advanced option. The Cisco breach shows that shared secrets and push approval flows still create a workable path for attackers who can steal credentials and pressure users. MFA existed here, but the factor chosen was susceptible to fatigue and impersonation. The practitioner conclusion is straightforward: if the control can be socially engineered at the approval step, it is not a durable trust boundary.

MFA fatigue is a control weakness because it turns authentication into a user-exhaustion contest. The attacker does not need to defeat the cryptography when the process itself rewards repeated prompting and human error. That failure mode is especially relevant in help-desk style impersonation, where the user is primed to believe the request is legitimate. Security programmes should treat excessive prompt volume as an abuse signal, not as routine authentication noise.

Human approval as an identity checkpoint: This breach illustrates a specific failure mode where the security model depends on the user making the final correct judgement under pressure. That assumption works only when the attacker cannot shape the decision environment. Once social engineering and push fatigue are in play, the control no longer separates legitimate access from coerced access. The implication is that approval-based identity flows need to be treated as a fragile governance pattern, not a stable assurance layer.

Zero Trust architecture is undermined when identity verification still relies on user persuasion. Zero Trust assumes continuous verification, but a coerced push approval can collapse that verification into a single manipulated moment. This is where human identity and session assurance intersect: the organisation may have an MFA policy, yet the attacker only needs one successful user interaction. Practitioners should read this as a warning that policy presence is not equivalent to control resistance.

The same credential abuse pattern now threatens machine and human identity programmes alike. While this incident involved a person, the underlying lesson extends to service accounts and other non-human identities that still depend on static secrets or weak approval boundaries. The field should stop treating authentication failures as a human-only problem. The practitioner conclusion is that identity governance has to account for both social engineering of people and secret abuse of machines.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, showing how one identity weakness can cascade into repeat compromise.
• The same governance pressure appears in our 52 NHI Breaches Analysis, where weak credential control repeatedly turns exposure into broader incident chains.

What this signals

Human approval remains a fragile trust boundary: the Cisco case is a reminder that authentication programmes still fail when the last decision sits with a pressured user. As organisations layer more workflow and device-based controls, they should expect adversaries to target the approval moment itself, not just the password or token.

With 72% of organisations already reporting or suspecting NHI compromise in our research, the identity problem is clearly broader than human MFA alone. Static secrets, delegated access, and approval-based flows all create moments where trust can be socially engineered or mechanically abused.

Teams that want to reduce exposure should align authentication policy with continuous verification patterns from the NIST Cybersecurity Framework 2.0 and harden high-value access paths before attackers turn user friction into a control bypass.

For practitioners

• Replace push-only MFA on privileged accounts Move high-risk users to phishing-resistant methods such as FIDO2 or certificate-based authentication, and reserve push for lower-risk scenarios with stronger device binding and alerting.
• Treat repeated push prompts as an abuse signal Log and alert on abnormal push frequency, failed approval sequences, and rapid re-registration events so security operations can spot MFA fatigue before access is granted.
• Restrict push registration paths Limit where and how push apps can be enrolled, require stronger verification for registration changes, and review any account that adds a new push device outside normal workflow.
• Train users for vishing and help-desk impersonation Run short, scenario-based awareness exercises that show how attackers combine social engineering with prompt abuse, and give users a clear reporting path when the request feels unusual.

Key takeaways

• The Cisco breach shows that stolen credentials plus MFA fatigue can still defeat accounts when the approval step is human-dependent.
• The scale of the problem is wider than one incident, because identity abuse patterns keep repeating across user and non-human access paths.
• Phishing-resistant authentication, abuse monitoring, and tighter registration controls are the controls that meaningfully reduce this failure mode.

Key terms

• MFA fatigue: MFA fatigue is an attack technique that overwhelms a user with repeated authentication prompts until they approve one out of annoyance, confusion, or pressure. It does not defeat the factor cryptographically. It defeats the human decision point that the factor depends on.
• Phishing-resistant authentication: Phishing-resistant authentication uses authenticators that cannot be easily replayed, proxied, or socially engineered into submission. In practice, this means reducing dependence on shared secrets and user-approved prompts, especially for privileged access and sensitive workflows.
• Push notification approval: Push notification approval is an authentication method where a user confirms access by responding to a prompt on a trusted device. It is operationally convenient, but it creates a human action threshold that attackers can target through fatigue, impersonation, or coercion.
• Initial access broker: An initial access broker is an attacker or criminal intermediary that acquires footholds, such as stolen credentials, and then passes them to other threat actors. This role turns access into a commodity and increases the likelihood that simple credential exposure will become a broader breach.

Deepen your knowledge

Phishing-resistant authentication and MFA fatigue defense are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building stronger access governance after a breach like this, it is worth exploring.

This post draws on content published by Axiad covering the Cisco data breach: lessons on MFA fatigue, stolen credentials, and phishing-resistant authentication. Read the original.