Cisco breach lessons show MFA fatigue remains an identity risk

At a glance

What this is: This is Axiad’s analysis of Cisco’s breach, showing that stolen credentials plus MFA fatigue and vishing can still bypass push-based authentication when attackers pressure the user into approving access.

Why it matters: It matters because IAM teams still have to govern the human approval path, not just the credential, and that affects MFA design, push-app controls, and adoption of phishing-resistant authentication.

Context

Cisco’s breach illustrates a familiar identity gap: authentication can still fail when the attacker does not break the factor, but instead manipulates the person expected to approve it. The article centres on stolen credentials, push-notification abuse, and vishing as a combined path to account takeover.

For IAM and PAM teams, the lesson is that MFA is not a single control outcome. Push-based flows need governance over registration, device trust, user education, and fallback methods, because the weakest point can be the approval decision itself.

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: What are the signs that MFA fatigue is being used against users?

A: Common signs include a burst of push requests, approvals that happen after several denials, unexpected enrolment of a new device, and suspicious sign-ins that align with user distraction or help desk impersonation. Security teams should treat these as correlated indicators of pressure-based authentication abuse, not isolated login events.

Q: When should organisations replace legacy MFA with phishing-resistant MFA?

A: They should do it first for privileged accounts, remote access, and any workflow that attackers can target with phishing or adversary-in-the-middle attacks. If the access path protects sensitive systems and the current factor can be replayed or approved out of band, the upgrade should move from backlog to priority.

Technical breakdown

How push-based MFA gets bypassed in practice

Push notification MFA works by asking the user to approve a login on a second device. That model adds a barrier, but it also creates a human decision point that attackers can target with repeated prompts or social engineering. MFA fatigue attacks rely on repetition and annoyance until the user approves, while vishing adds a persuasive voice channel that makes the prompt feel legitimate. The control is not broken because MFA exists. It breaks when approval becomes routine, unverified, or detached from the actual sign-in context.

Practical implication: Limit push sprawl, add stronger approval context, and treat user consent as part of the control surface.

Why stolen credentials still matter when MFA is enabled

Stolen usernames and passwords remain the entry point that gives the attacker a live authentication attempt to work against. Once the password is valid, the adversary only has to defeat the second factor, and push-based MFA often makes that possible through repeated prompts or impersonation. Phishing-resistant methods change the equation because they bind authentication to the origin and device more tightly, reducing the usefulness of stolen credentials alone. The issue is not that MFA adds no value. The issue is that some MFA methods still leave a social-engineering path open.

Practical implication: Treat compromised passwords as a trigger to move toward phishing-resistant authentication, not as a reason to trust legacy MFA more.

How push-app governance changes the attack surface

The article points to practical controls around where push apps can be installed and registered. That matters because every extra enrolment path expands the number of ways an attacker can redirect or overload the approval process. Stronger push governance does not replace authentication design, but it can reduce the chance that a rogue device, duplicated registration, or poorly controlled fallback path becomes the deciding factor in account compromise. In this kind of attack, lifecycle and registration control are part of authentication security, not administrative detail.

Practical implication: Constrain push registration, review fallback methods, and monitor for abnormal device enrolment or approval patterns.

Threat narrative

Attacker objective: The objective was to take over the employee account and 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 account access attempts.
2. Credential access was reinforced through MFA fatigue and vishing, which pressured the employee to approve a push notification and bypass the second factor.
3. Impact followed as the employee’s account was compromised and data was exposed through the attacker’s successful access path.

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.
• Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.

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 a complete defence when the attacker can move the decision to the user. The Cisco breach shows that approval becomes the attack surface once the credential is already valid. That is not a failure of authentication in the abstract. It is a failure mode in which human consent is treated as a reliable security signal when it can be socially engineered.

MFA fatigue is a control abuse pattern, not merely user error. Repeated prompts, impersonation, and vishing work because they exploit how people interpret urgency and familiarity under pressure. The practical implication is that push flows need governance for registration, device binding, and anomaly handling, not just user awareness training.

Phishing-resistant authentication should be treated as the default target state for high-risk access. The breach shows that passwords and basic push prompts still leave too much room for coercion. The more important question for IAM teams is which accounts, applications, and privilege paths cannot tolerate a human approval bypass.

Identity security has to include approval-path design. Once attackers can coerce a user into confirming access, the control plane extends beyond authentication into device trust, push policy, and user verification. That makes MFA governance part of broader identity threat management, not a narrow sign-in concern.

What this signals

Push approval has become part of the identity attack surface. In mature IAM programmes, the question is no longer whether MFA exists, but whether the approval step can be coerced, overloaded, or detached from the actual sign-in context. That shifts governance toward device binding, prompt controls, and phishing-resistant methods for high-risk access.

Approval-path design is now a security control in its own right. If users can be trained to distrust prompts, then the environment must be designed so that suspicious prompts are rare, visible, and tightly bound to verified devices. That is where modern identity programmes separate basic MFA deployment from real identity risk reduction.

For practitioners

• Restrict push-app registration paths Allow push enrollment only from trusted contexts and review any workflow that lets a user add a new device without strong verification.
• Move high-risk access to phishing-resistant methods Prioritise FIDO2 or other phishing-resistant authentication for privileged users, remote access, and applications that handle sensitive data.
• Detect MFA fatigue patterns early Watch for repeated push requests, unusual approval timing, and sign-in attempts that cluster around the same account or device.
• Train users on vishing and push abuse Use short, scenario-based awareness content that teaches people to reject unsolicited verification calls and report unexpected push prompts immediately.
• Review fallback authentication paths Check whether SMS, voice, or other weaker methods remain available after phishing-resistant authentication is introduced, and retire unnecessary backdoors.

Key takeaways

• The Cisco breach shows that push-based MFA can still fail when attackers combine stolen credentials with fatigue and vishing.
• The practical weakness is not the existence of MFA, but the approval step that a user can be manipulated into accepting.
• High-risk identity programmes should prioritise phishing-resistant authentication and tighter push-app governance over reliance on legacy prompts.

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.
• Push Notification MFA: Push Notification MFA is a multi-factor authentication method that sends a login approval prompt to a trusted device. The user approves or denies the request, and the system uses that response as a second factor tied to a registered authenticator, often through a mobile app or device-bound channel.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.