Social engineering and MFA bypass are still breaking enterprise identity

At a glance

What this is: This is an analysis of how social engineering attacks are bypassing traditional MFA and help-desk controls to gain enterprise access.

Why it matters: It matters because identity teams must treat human-targeted access abuse as an IAM, PAM, and lifecycle problem, not just a fraud or awareness issue.

By the numbers:

• Marks & Spencer has yet to restore online shopping after more than $80 million in lost profit from the attack.
• One 2025 survey found that 70% of consumers would stop shopping with a brand that suffered a security incident.

👉 Read 1Kosmos's analysis of social engineering, MFA bypass, and enterprise identity risk

Context

Social engineering is the abuse of trust to obtain access, approvals, or account recovery actions that should not have been granted. In this case, the primary identity security problem is not a new exploit chain, but the way attackers turn help desks, mobile carriers, and MFA workflows into access brokers for corporate systems.

For IAM, PAM, and lifecycle teams, the warning is clear: if identity assurance depends on a password reset, OTP delivery, or device possession alone, an attacker can redirect those controls through impersonation. That makes the issue broader than retail, because the same failure pattern applies wherever human operators can reset, approve, or vouch for access.

Key questions

Q: How should security teams reduce social engineering risk in identity recovery workflows?

A: They should treat recovery as a privileged control path, not a customer service process. That means verifying the person through independent proof, restricting who can approve resets, logging every step, and separating account recovery from routine support. Where possible, use phishing-resistant authentication so an attacker cannot simply move the second factor onto a new device.

Q: Why do traditional MFA controls fail against help-desk and SIM swap attacks?

A: Traditional MFA often trusts channels that can be redirected, such as SMS delivery, carrier changes, or support-assisted resets. If an attacker can move the factor to a device they control, the login still looks valid. The control fails because it proves factor possession, not that the right person is controlling the factor.

Q: What breaks when attackers gain access through impersonation rather than malware?

A: Impersonation bypasses many perimeter assumptions because the session begins with valid credentials or a valid recovery action. That makes downstream access, directory trust, and help-desk approval the real attack surface. The biggest failure is that security teams may not see a malicious event at all, only an apparently legitimate authentication path.

Q: Who is accountable when social engineering defeats identity controls?

A: Accountability sits with the teams that own authentication, support workflows, telecom dependencies, and privileged access, not only with end users. If a reset, SIM swap, or device rebind can grant access without strong verification, the governance gap is structural. Organisations should map those responsibilities before an incident forces the issue.

Technical breakdown

How social engineering turns help desks into access brokers

The article describes a playbook that avoids malware-first intrusion and instead targets people who can grant or reset access. Attackers use convincing conversations, SIM swapping, or insider manipulation to reroute authentication factors and persuade help-desk staff to accept a false identity. Once the victim’s recovery path is under attacker control, MFA becomes a transport mechanism rather than a control. The key weakness is not the login screen, but the identity recovery workflow around it, especially when support processes trust caller assertions more than verified proof of identity.

Practical implication: treat help-desk recovery and carrier interactions as privileged identity workflows, not routine service requests.

Why traditional MFA fails against impersonation-driven attacks

Traditional MFA assumes that possession of a device or one-time code strongly binds the session to the rightful user. The problem is that SIM swaps, push fatigue, and recovery-channel abuse let attackers move the second factor onto their own device or approve access through a proxy channel. In that model, the factor is still present, but the trust relationship has been hijacked. Stronger assurance requires binding the authenticator to the actual person and to a verifiable enrollment event, not just to a handset or a code delivery path.

Practical implication: re-evaluate MFA methods that can be re-bound through telecom or support-channel abuse.

Why identity compromise becomes a platform-wide breach

Once attackers obtain valid access, the article shows how they can move from a single account or system into broader enterprise control, especially where directory services or inherited permissions are in play. That turns one compromised identity into many accessible systems, which is why business interruption and ransomware follow quickly after initial access. In identity terms, the blast radius is determined less by the first compromise than by how much standing privilege and directory reach that account carries.

Practical implication: map which accounts can cascade into broad access through directory inheritance or privileged session reuse.

Threat narrative

Attacker objective: The attacker aims to convert impersonation into durable enterprise access that can be monetised through data theft, disruption, or extortion.

1. Entry occurs through social engineering, SIM swapping, or help-desk manipulation that redirects recovery and authentication to the attacker.
2. Escalation follows when the attacker uses the newly gained access path to impersonate the victim across connected corporate systems or directory services.
3. Impact emerges as systems are disrupted, data is extracted, and ransomware or wider operational sabotage becomes possible.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Social engineering is now an identity-control failure, not just a people problem. When attackers can redirect recovery channels, the weak point is the governance chain that lets humans authenticate via trust rather than proof. That is why help desks, telecom carriers, and delegated support processes belong in the same control conversation as IAM and PAM. Practitioners should treat impersonation resistance as a core identity requirement, not an awareness campaign.

Traditional MFA is built on assumptions that attackers now routinely invalidate. The control assumes the second factor stays bound to the legitimate user and the legitimate device. SIM swapping and recovery-channel abuse break that assumption by relocating the factor without breaking the authentication workflow. The implication is that identity assurance must be anchored in stronger proof of personhood, not just code delivery. Practitioners should re-evaluate where their MFA design still trusts channels that can be socially engineered.

Standing privilege turns a single impersonation into enterprise-wide blast radius. Once one account is captured, directory inheritance and broad permission sets can expose many systems at once. This is not a narrow access issue, it is a privilege architecture issue. The article’s pattern fits the same failure mode seen in many identity-led breaches: access was broad enough that one successful deception became a platform outage. Practitioners should map which identities can still fan out into major operational impact.

Live biometric identity verification closes the gap that credential-only controls leave open. The article points to the need for verification tied to the actual person, not just the device or secret. That is especially relevant where human support teams can reset credentials or vouch for access. The field should stop treating phishing-resistant authentication as a niche upgrade and start treating it as baseline protection for recovery and enrollment paths. Practitioners should align assurance levels to the risk of the recovery channel.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirming and 26% suspecting compromise.
• To see how compromised machine identities fit into broader breach patterns, review The 52 NHI breaches Report for root-cause case studies and recurring governance failures.

What this signals

Access recovery is becoming the new front line of identity governance. When attackers can win by talking to support teams or mobile carriers, the security programme has to govern the recovery path with the same rigour as primary authentication. The practical shift is toward stronger identity proofing, tighter approval chains, and reduced reliance on recoverable factors that can be socially engineered.

Impersonation-resistant assurance should now sit alongside phishing-resistant MFA in priority order. Organisations that only harden login screens but leave reset flows weak are protecting the wrong boundary. For IAM and PAM teams, the programme question is whether a human operator can still create a new trusted device or factor through a process that an attacker can manipulate.

With 72% of organisations having experienced or suspected an NHI breach, the broader lesson is that identity governance failures cluster around trust edges, not just credentials. That is why related controls such as Ultimate Guide to NHIs , Key Challenges and Risks remain relevant here: the same governance discipline that limits credential sprawl also constrains how easily an attacker can turn one trusted action into enterprise access.

For practitioners

• Harden help-desk recovery workflows Require step-up verification for password resets, device rebinds, and MFA changes, and make support staff validate identity with independent proof rather than caller-supplied details.
• Lock down telecom-based recovery paths Add carrier-level safeguards for SIM swap and number port requests, and monitor for changes that can move the second factor onto an attacker-controlled device.
• Replace code-only MFA on sensitive accounts Use phishing-resistant authentication for privileged and high-impact accounts, especially where account recovery can be socially engineered through help desks or mobile providers.
• Review directory inheritance and privileged reach Identify accounts that can cascade into broad system access through Active Directory or similar identity layers, then reduce standing privilege and segment escalation paths.

Key takeaways

• Social engineering succeeds when identity recovery is treated as routine support instead of privileged access control.
• Identity programmes that rely on SMS, help-desk resets, or device possession alone remain exposed to impersonation-led account takeover.
• The most effective response is to harden recovery, reduce standing privilege, and bind authentication to stronger proof of the actual user.

Key terms

• Phishing-resistant authentication: Authentication that cannot be easily replayed, forwarded, or redirected by an attacker who tricks the user or support team. In practice, it binds the login to a stronger, cryptographically verifiable factor and reduces dependence on codes, SMS, or channels that can be socially engineered.
• Identity recovery workflow: The process used to restore access when a user cannot sign in, change a factor, or re-establish trust in an account. It is often more sensitive than the login itself because it can create new trust, so it needs stronger proof, tighter approvals, and better monitoring than standard support.
• Standing privilege: Access that remains available without a just-in-time grant or task-specific approval. In identity governance, it increases blast radius because one compromised account can persistently reach systems and data that should only be exposed for a short, verified business need.
• Help-desk impersonation: An attack pattern where a threat actor convinces support staff to reset, rebind, or approve access as if they were the legitimate user. It exploits trust in human operators and procedural shortcuts, making the service desk part of the authentication surface.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by 1Kosmos: Social engineering and MFA bypass in recent retail attacks. Read the original.