Cisco data breach lessons: MFA fatigue and stolen credentials

At a glance

What this is: Axiad’s review of Cisco’s breach argues that stolen credentials, MFA fatigue, and vishing can still defeat push-based authentication when attackers combine social engineering with account compromise.

Why it matters: It matters because identity teams still need controls that reduce reliance on passwords and stop approval abuse, especially where push-based MFA remains part of the access path.

Context

This case is about human identity compromise through credential theft and authentication coercion, not a tooling failure in isolation. The core problem is that one stolen password can still become a live account compromise when the authentication flow depends on user approval.

Axiad uses Cisco’s incident to show why MFA strength depends on the specific factor and the surrounding registration, alerting, and user-training controls. When push approvals can be manipulated through fatigue or impersonation, the governance issue is not whether MFA exists, but whether it resists coercion.

For IAM teams, the lesson extends beyond one breach. Authentication design has to assume that attackers will combine stolen credentials, repeated prompts, and social engineering until the user yields.

Key questions

Q: How should security teams reduce the risk of MFA fatigue attacks?

A: Security teams should remove approval-based MFA from high-risk access paths, replace it with cryptographic authentication, and reduce the privileges attached to any successful session. They should also detect repeated prompt events as attack signals, not user noise, and trigger response when requests spike unexpectedly.

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: What are the signs that push-based MFA is being abused?

A: Look for repeated prompts, unusual login timing, multiple failed attempts followed by one success, and support calls that reference unexpected authentication requests. Those signals often indicate an attacker is trying to exhaust or confuse the user rather than break the factor directly. Monitoring should tie those events to account risk, not just authentication volume.

Q: What should teams do when MFA still allows account compromise?

A: Teams should move high-risk accounts to phishing-resistant methods, restrict device enrollment, and review whether support workflows let attackers impersonate legitimate help-desk activity. The goal is to break the chain between credential theft, user coercion, and successful approval before access is granted.

Technical breakdown

How MFA fatigue turns approval into the attack surface

Push-based MFA adds a second factor, but it can also create an approval channel that attackers can manipulate. MFA fatigue works by repeatedly triggering prompts until the user accepts them just to stop the interruptions. That makes the human response the weak point, not the cryptographic strength of the login flow. In this incident, the attacker still needed a valid username and password first, then used repeated prompts and pressure to convert a denied login into approved access. The lesson is that the security property of MFA changes with the factor type and the user experience around it.

Practical implication: treat push approval as a controllable risk surface, not just an authentication feature.

Why vishing works against account recovery and push approval flows

Vishing, or voice phishing, works because it borrows trust from a believable authority figure such as a help desk agent or internal support contact. Once the attacker has that interaction, the user may interpret the prompt as routine rather than malicious. This is especially dangerous when the organisation allows flexible push registration or broad device enrollment, because the attacker can combine social engineering with legitimate-looking workflow steps. The breach shows that identity controls cannot be evaluated only at the protocol layer. They also need to account for human persuasion, help-desk script abuse, and registration abuse.

Practical implication: limit who can register push apps and harden support scripts against impersonation.

Why phishing-resistant authentication changes the threat model

Phishing-resistant authentication reduces the value of stolen passwords because the login ceremony binds the user to a specific origin or device in a way the attacker cannot replay through simple social engineering. Methods such as FIDO2 and other strong authenticators remove much of the attacker’s leverage from password theft and push spam. In governance terms, this is less about adding another control and more about changing the attacker’s cheapest path into the account. The Cisco case reinforces that weakly phishable factors still allow coercion to substitute for proof of identity.

Practical implication: prioritise phishing-resistant methods for high-risk users and privileged access paths.

Threat narrative

Attacker objective: The attacker’s objective was to obtain account access by coercing authentication approval after credential theft, then use that access to compromise data.

1. Entry began with stolen credentials taken from the employee’s personal account, giving the attacker a valid starting point for authentication attempts.
2. Escalation came through MFA fatigue and vishing, which pressured the user into approving a push notification and bypassing the existing second factor.
3. Impact followed once the account was accessed and data was compromised, showing how one coerced approval can defeat the intended protection of MFA.

Breaches seen in the wild

• Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
• Cisco DevHub breach 2024: A misconfigured script left non-public files on Cisco's DevHub; IntelBroker took them and claimed reuse of hard-coded SSH credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Push-based MFA is not the same as phishing-resistant authentication: the Cisco incident shows that a second factor can still be coerced when the attacker controls the pace of prompts and the user is fatigued into approving one. That distinction matters because many programmes count MFA coverage without testing whether the factor resists real-world coercion. The practical conclusion is that control strength depends on factor type, not just factor count.

Credential theft plus user coercion remains the lowest-friction path into enterprise accounts: attackers do not need to defeat every control when they can pair a stolen password with a human approval loop. Cisco’s breach reinforces that identity assurance fails at the seam between stolen secrets and interactive login workflows. Practitioners should treat that seam as the real risk boundary.

Registration and support processes are part of the authentication surface: when push apps can be enrolled too loosely, or when help-desk style vishing succeeds, the identity programme has already over-trusted the surrounding process. Authentication governance must therefore include device registration, support scripts, and exception handling, not just login policy. The practical implication is to govern the whole approval journey, not only the factor itself.

Phishing resistance should be the default for high-risk access paths: once the attacker can steal a password and rely on human behaviour, the attacker has a repeatable route that scales across users. The Cisco case validates a broader identity principle: the closer authentication gets to a replayable secret, the more it depends on user discipline. Security teams should reserve weaker factors for lower-risk use cases and move sensitive access to stronger methods.

Identity attack surface is widened by trust in familiar workflows: vishing succeeds because users recognize the support pattern, the prompt, or the device notification and infer legitimacy. That is not just a training gap, it is a design assumption that users can reliably distinguish normal from malicious pressure in the moment. The implication is to redesign workflows so they are harder to impersonate, not merely easier to explain.

What this signals

Identity programmes that stop at MFA coverage are measuring the wrong thing: the Cisco case shows that factor presence is not the same as factor resistance. What matters is whether the chosen method can survive prompt abuse, impersonation, and repeated user pressure without turning approval into the attacker’s shortcut.

If a help-desk script, device enrollment path, or push prompt can be socially engineered, the authentication programme has a process problem, not just a technology problem. That makes registration governance and user reporting behaviour part of identity assurance, especially for high-risk accounts.

For practitioners

• Deploy phishing-resistant authentication Use strong authenticators such as FIDO2 or PIV for users who can access sensitive data, admin portals, or privileged functions. Reduce reliance on passwords and push approvals where a replayable secret would create unacceptable account risk.
• Constrain push registration and enrollment Limit where push apps can be registered, which devices are eligible, and which enrollment paths can be used. Review exceptions and ensure support staff cannot override registration controls through informal processes.
• Train users on MFA fatigue and vishing Teach employees to reject unexpected authentication prompts, confirm support contacts through out-of-band channels, and report repeated push requests immediately. Make social engineering reporting part of the authentication programme, not a separate awareness topic.
• Reduce password dependence in high-risk accounts Migrate high-value accounts away from password-first flows and toward methods that do not rely on shared secrets as the primary proof of identity. This narrows the attacker’s ability to combine stolen credentials with approval coercion.
• Monitor for repeated prompt abuse Look for clusters of failed logins, repeated MFA prompts, unusual enrollment events, and support interactions that do not match normal user behaviour. These signals often appear before an approval-based compromise becomes a full account takeover.

Key takeaways

• The breach shows that stolen credentials can still become account compromise when the second factor depends on user approval under pressure.
• The scale of the issue is not MFA absence but MFA weakness, because push fatigue and vishing can turn normal login workflows into a coercion channel.
• Phishing-resistant authentication and tighter registration controls are the controls most directly aligned to this failure mode.

Key terms

• MFA Fatigue: MFA fatigue is the behavioural pressure created when repeated login prompts make a person more likely to approve access without checking carefully. It is a control failure in the authentication experience, and it becomes dangerous when the approved session carries broad privilege or long-lived access.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Vishing: Voice phishing is a social engineering technique that uses phone calls or voice channels to persuade a target to reveal information or approve access. It succeeds by exploiting trust, urgency, and procedural shortcuts, often bypassing technical controls that would have stopped a direct login attack.
• Push-based MFA: A multi-factor method that sends an approve or deny notification to a device during login. It is convenient and fast, but that same convenience creates a behavioral weakness when users are asked to make repeated trust decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.