TL;DR: The MGM and Caesars attacks show how social engineering, stolen credentials, and MFA bypass can still defeat enterprise identity controls, according to 1Kosmos, with Reuters linking Scattered Spider to 52 attacks since 2022. Legacy MFA assumes the authenticator proves the person, but attackers now exploit account recovery, help desks, and alternate identity providers instead.
At a glance
What this is: This analysis says Scattered Spider’s casino intrusions show legacy MFA can be bypassed through social engineering, admin abuse, and alternate authentication paths once the attacker gets into the identity workflow.
Why it matters: It matters because identity teams still treat MFA as a login checkpoint, while modern attacks target recovery, support, and privilege paths that sit around the checkpoint.
Context
Legacy MFA is built to confirm a login, but it does not by itself control who can reset access, impersonate a user, or register a new trust path. That gap becomes material when attackers use support workflows and administrative authority to move around the authentication layer rather than through it.
The article frames this as an identity governance problem, not just a breach story. For enterprise IAM, the question is whether the programme can verify the person behind the account across enrollment, recovery, and privileged session creation, or whether those steps remain exploitable handoffs.
Key questions
Q: What breaks when legacy MFA is paired with weak account recovery?
A: Legacy MFA breaks down when support staff or recovery workflows can reset access without strong identity proofing. At that point, the attacker does not need to defeat the factor directly, because the reset path becomes the new trust decision. Teams should govern resets, factor changes, and help desk escalations as high-risk authentication events.
Q: Why do alternate identity providers create a higher identity risk than ordinary login changes?
A: Alternate identity providers can redefine which identity source the enterprise accepts, so a compromised admin path can bypass the original MFA control altogether. That creates a control-plane risk, not just a login risk. Organisations should treat provider creation and federation changes as privileged changes with review and audit.
Q: What are the warning signs that MFA governance is too easy to bypass?
A: Common warning signs include frequent support-driven resets, broad administrator ability to enroll authenticators, weak logging around federation changes, and outsourced help desk processes that can authenticate users without strong proofing. If any of those are present, the enterprise may have strong MFA on paper but a weak trust model in practice.
Q: How should security teams reduce vishing success against privileged users?
A: Security teams should harden the workflows that vishing targets first: password resets, MFA resets, help desk overrides, and privileged support requests. Require out-of-band verification, separate approval paths for high-risk users, and telemetry that flags unusual recovery activity. The goal is to make persuasion insufficient on its own, even when the attacker sounds legitimate.
Technical breakdown
Why legacy MFA fails when attackers target account recovery
Legacy MFA usually protects the authentication moment, not the broader identity lifecycle around it. If an attacker can persuade a help desk, trigger a password reset, or obtain an alternate path into the account, the MFA challenge becomes irrelevant because the trust decision has already moved upstream. That is why social engineering works so well against organisations that still equate MFA with identity assurance. The real weakness is not the factor itself but the assumption that the attacker must face it at login. Practical implication: treat recovery and support workflows as part of the authentication surface, not as separate business processes.
Practical implication: Protect account recovery with the same rigor as primary login, including stronger verification and tighter support workflow controls.
How alternate identity providers can bypass enterprise trust
An identity provider is only as strong as the binding between the user, the authenticator, and the policy that governs enrolment. In the MGM case described here, attackers reportedly used administrative access to configure a second identity provider, which shifts trust away from the original control plane. Once that happens, MFA can be sidestepped without defeating the original factor at all. This is a control-plane problem: whoever can redefine trust relationships can often outpace the factor designed to prove identity. Practical implication: govern identity provider changes as privileged changes, with approval, logging, and review.
Practical implication: Treat identity provider configuration as privileged infrastructure and lock down who can create or modify federation paths.
Why privileged access makes biometric and push-based MFA brittle
Biometrics and push approvals can be strong when the authenticating device and identity binding are tightly governed, but they become brittle when administrators can enroll new factors or alter trust paths. The issue is not that biometrics fail in principle, but that administrative privilege can let an attacker redefine what counts as valid authentication. That is why high-risk accounts need separate controls around factor enrollment, device registration, and privileged session initiation. Practical implication: do not assume a strong factor compensates for weak privileged administration.
Practical implication: Separate factor enrollment and privileged administration so one compromised admin path cannot rewrite authentication trust.
Threat narrative
Attacker objective: The objective was to seize privileged enterprise access, bypass identity controls, and use that access to extort the victim through ransomware and operational disruption.
- Entry occurred through vishing and impersonation of a resort employee, which let the attackers reach outsourced IT support and request account help.
- Credential and trust abuse followed when the attackers used that support interaction to obtain access and elevate into the Okta environment.
- Escalation continued as the attackers configured a second identity provider and bypassed MFA for highly privileged users.
- Impact came when the group deployed ransomware and disrupted email, reservations, booking systems, slot machines, and digital keycard access.
Breaches seen in the wild
- Caesars Entertainment breach 2023: Social engineering of an IT support vendor let attackers copy Caesars loyalty database; about $15 million was reportedly paid.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legacy MFA is a control around login, not a governance model for identity trust. The article shows attackers winning before the MFA challenge mattered by exploiting support workflows, administrative rights, and alternate trust paths. That means the security problem is not whether the factor is strong enough, but whether the programme still assumes the only dangerous moment is initial sign-in. Practitioners should treat identity assurance as a lifecycle issue, not a single checkpoint.
Support desks have become part of the authentication plane. When an outsourced technician can be convinced to act on behalf of an impostor, the control boundary has already failed. This is not a people problem in isolation, it is a governance design problem where recovery, enrollment, and reset authority are under-modeled. Identity teams need to recognise that every delegated reset path creates a new trust perimeter.
Alternate identity providers are a trust-altering privilege, not an administrative convenience. Once an attacker can register or redirect the trust source, they can make enterprise MFA irrelevant without defeating the original authenticator. That is why federation changes belong in the same risk class as privileged access changes. The implication is clear: trust-path mutation must be governed as a high-risk control-plane event.
Non-phishable authentication only helps when factor enrollment is also controlled. The article’s core lesson is that strong biometric or device-bound authentication can still be undermined if an attacker can alter the registration process, enroll a new factor, or manipulate privileged administration. The real issue is not which factor a user presents, but who can redefine the conditions under which it is accepted. Teams should therefore focus on enrollment authority as much as authentication strength.
Identity blast radius now depends on who can rewire trust, not just who can log in. Once an attacker reaches an admin path, the damage is no longer limited to a single account compromise. They can reshape the authentication fabric for many users at once, turning one social-engineering success into enterprise-wide exposure. Practitioners need to map the control points where trust can be rewritten and narrow them aggressively.
What this signals
Identity teams need to stop treating authentication as the end of the control story. The decisive question is who can alter enrollment, recovery, and federation after the user is supposedly verified. When those paths are weak, the enterprise is defending a login screen while the attacker is controlling the identity plumbing.
Trust-path mutation is the operational risk to watch. If an attacker can register new factors, redirect identity sources, or coerce support staff into resetting access, they can bypass the original MFA design without needing to crack it. That shifts programme focus from factor strength alone to governance over who can rewrite trust.
For practitioners
- Lock down recovery workflows Require stronger identity proofing for password resets, factor resets, and help desk escalations so a support interaction cannot become a trust shortcut.
- Treat identity provider changes as privileged events Put creation, modification, and deactivation of identity providers under privileged access review, approval, and full audit logging.
- Separate factor enrollment from admin rights Prevent the same administrative role from both enrolling new authenticators and approving high-risk authentication policy changes.
- Review outsourced support access Validate whether external help desk and support vendors can trigger resets, identity changes, or privilege grants without compensating controls.
- Recheck privileged user authentication paths Map how super-admin and other high-value accounts authenticate, then remove any path that allows trust to be redefined from the same session or role.
Key takeaways
- The article shows legacy MFA can be bypassed when attackers target support workflows, admin rights, and federation rather than the login prompt itself.
- The MGM breach description includes vishing, super administrator access in Okta, a second identity provider, and ransomware that disrupted core operations.
- Identity teams need tighter control over recovery, factor enrollment, and identity provider changes if they want MFA to remain meaningful.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on MFA bypass and weak identity assurance at login and recovery points. |
| NHI-10 — Human Use of NHI | Support staff and administrators are manipulating non-human trust paths that the attack turns against the enterprise. | |
| Recommendation — Review authentication flows for bypass paths and harden any step where an attacker can replace the intended identity proof. Restrict human ability to create or alter NHI trust relationships without privileged review and audit. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle control is central to the factor reset and enrollment weaknesses described here. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | The attack exploits identity assurance for non-organizational and delegated support workflows. | |
| Recommendation — Apply authenticator management controls to resets, enrollment, and replacement of all high-value authenticators. Strengthen proofing and authentication for external support and delegated access paths before granting recovery authority. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack combines social engineering credential access with movement into privileged identity infrastructure. |
| Recommendation — Map vishing-led identity compromise to credential access and lateral movement in detection and response playbooks. | ||
Key terms
- Legacy MFA: Older multi-factor authentication methods that add a second check but still depend on human response or reusable codes. In practice, SMS, voice, and push-based flows can reduce casual compromise while leaving room for phishing, fatigue attacks, and adversary-in-the-middle interception.
- Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
- Factor enrollment: Factor enrollment is the process of adding a new trusted authentication method to an account, such as a device, push token, or software token. In IAM governance, it is a privileged identity event because it can create durable access paths that survive the original login session.
- Recovery Workflow: A recovery workflow is the sequence of checks and actions used to restore access after a credential issue or account lockout. It includes verification, credential issuance, synchronization, and audit logging. Weak recovery workflows are attractive to attackers because they often sit outside the strongest authentication controls.
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.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org