TL;DR: Scattered Spider’s expansion into airlines shows how help desk social engineering, MFA bypass, and trusted vendor abuse can turn identity processes into the easiest entry point, according to 1Kosmos. The breach pattern is a governance failure, not a perimeter failure: organisations still trust stories, devices, and urgency more than verified identity.
At a glance
What this is: The article argues that Scattered Spider’s airline attacks exploit identity trust assumptions, especially help desk workflows, MFA registration, and contractor access.
Why it matters: It matters because airline IAM, NHI, and human identity teams must treat identity verification, device registration, and delegated access as attack surfaces, not administrative conveniences.
By the numbers:
- The MGM attack cost that organization $100 million in operational disruption.
👉 Read 1Kosmos's analysis of Scattered Spider attacks on airline identity systems
Context
Scattered Spider’s airline targeting shows what happens when identity governance depends on human judgement during high-pressure support workflows. In practice, the problem is not just credential theft, but the assumption that a convincing caller, a known employee number, or an urgent operational story is enough to justify access changes.
For IAM teams, the airline case is a reminder that help desk procedures, MFA enrolment, and contractor onboarding all sit inside the identity control plane. When those processes trust context more than proof, attackers can move through the organisation without needing to break the network first.
Key questions
Q: How should security teams stop help desk social engineering from becoming an account takeover path?
A: Security teams should treat identity recovery as a privileged workflow. That means strong caller verification, limited support authority, dual approval for sensitive changes, and audit visibility on resets, MFA enrolment, and recovery exceptions. If the help desk can change identity state on trust alone, attackers only need a convincing story to gain valid access.
Q: Why do traditional MFA controls fail against social engineering campaigns like Scattered Spider?
A: Traditional MFA fails when the factor can be redirected, coerced, or socially engineered. Push fatigue, SIM swap, and one-time code theft all exploit the fact that possession is not proof of the real user. Phishing-resistant authentication reduces this risk because the challenge is bound to the legitimate identity registration and cannot be reused by a caller.
Q: What breaks when contractor identities are governed less strictly than employee identities?
A: When contractor identities receive weaker verification and slower offboarding, attackers can use the third-party relationship as an easier entry point into production systems. The break is not just access scope, but lifecycle parity. If contractors can reach critical systems, they need the same identity proofing, logging, and review standards as employees.
Q: Who is accountable when a support workflow adds an attacker-controlled MFA device?
A: Accountability sits with the organisation that allowed a high-risk identity change to happen without adequate proof and approval. In practice, IAM, service desk leadership, and security governance all share responsibility for defining what support can change, who may approve it, and how exceptions are reviewed after the fact.
Technical breakdown
Help desk social engineering as an identity control failure
Scattered Spider’s core technique is not technical exploitation but identity impersonation at the support layer. The attacker uses public information, organisational terminology, and urgency to convince service desk staff to reset passwords, add MFA devices, or approve access changes. This works because many workflows still treat the help desk as a trusted extension of the identity system rather than a high-risk decision point. The technical weakness is the absence of strong caller verification, step-up checks for account recovery, and policy enforcement around what support staff can change. In other words, the attacker does not need to defeat authentication if they can become the person who requests it.
Practical implication: separate routine support from privileged identity changes and require strong proof before any recovery or MFA reset is processed.
Why traditional MFA breaks under push fatigue and SIM swap pressure
The article highlights several MFA bypass paths, including push fatigue, SIM swapping, and social engineering for one-time codes. These methods succeed because many MFA deployments still rely on possession factors that can be redirected, coerced, or socially engineered. A code sent to a phone is not a proof of identity if an attacker can intercept the device, persuade the user to share it, or overload the user with prompts until one is accepted. FIDO2-style phishing-resistant methods reduce this weakness because the verifier challenge is bound to the legitimate registration and cannot be replayed through a call centre or text message relay.
Practical implication: replace recoverable MFA paths with phishing-resistant authentication for high-risk accounts and recovery flows.
Third-party access expands the airline identity attack surface
The FBI warning about trusted vendors and contractors reflects a broader identity governance problem: third-party accounts often receive weaker verification, slower oversight, and less frequent review than employee accounts. In airline environments, that matters because suppliers can provide a bridge into operational systems even when the primary target has stronger internal controls. The technical issue is not just credential strength but entitlement scope, lifecycle offboarding, and inconsistent assurance across organisations that share access. When contractor identity proofing and access revocation are fragmented, the attacker only needs one exposed relationship to reach the primary target.
Practical implication: apply the same verification, review, and offboarding standards to contractor identities that you apply to employee identities.
Threat narrative
Attacker objective: The attacker aims to turn support trust into valid identity control, then use that access to disrupt airline operations and extend compromise across connected systems.
- Entry occurs through phone-based social engineering, where attackers impersonate employees or contractors to persuade support staff to reset access or add devices.
- Escalation follows when the attacker abuses approved remote tools, MFA registration changes, or help desk workflows to obtain valid access that appears legitimate.
- Impact comes from operational disruption, account takeover, and follow-on access to airline data, systems, and supplier-connected environments.
Breaches seen in the wild
- Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity trust, not network trust, is the attack surface Scattered Spider is exploiting. The airline cases show that a convincing caller can still outrun a mature perimeter when support processes are allowed to make identity decisions on narrative and urgency. That is why help desk workflows now function as a frontline security control, not an administrative back office. Practitioners should treat every recovery path as a potential intrusion path.
Standing support privilege creates a silent escalation channel. When service desk staff can reset credentials, register MFA devices, or override normal checks without strong proof, they effectively hold privileged access to every account they service. This is a governance problem because the privilege exists before any incident and often outside the usual PAM scrutiny. The implication is that support access must be governed as high-risk identity authority, not ordinary operations.
Contractor identities inherit the weakest assurance in the chain unless the organisation forces parity. The article’s warning about vendors and contractors reflects a recurring failure mode in third-party access programs: external identities are treated as lower friction because they are temporary, but they are still trusted to reach production systems. That produces asymmetric risk across the identity estate. Practitioners should assume supplier access will be targeted first and governed least well unless policy forces equal verification and review.
Help desk social engineering is a lifecycle failure as much as an authentication failure. The issue is not only that attackers can reset credentials. It is that identity programmes often lack enough lifecycle discipline to verify who may request changes, who can approve them, and when delegated access should expire. In this pattern, accountability is weaker than access. Security teams should manage recovery, enrolment, and offboarding as one control plane.
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.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
- For the broader control model behind this pattern, see Ultimate Guide to NHIs for the governance, lifecycle, and offboarding disciplines that reduce identity abuse windows.
What this signals
Support desk governance is becoming a security boundary, not an operations detail. If an attacker can convert a routine recovery call into a legitimate identity change, the programme has already lost the trust decision before authentication even begins. Organisations should expect more attacks against service teams that can alter identity state, especially where after-hours pressure is normal.
Identity lifecycle parity is the next control question for third-party access. A contractor account that can touch operational systems needs the same verification, logging, and offboarding rigour as an employee account. The more fragmented the review model, the easier it becomes for attackers to find the least governed identity in the chain.
Identity recovery debt: every exception path becomes a permanent attacker hypothesis. When reset, enrolment, and escalation rules vary by shift, geography, or urgency, attackers can model those differences and target the weakest path. Teams should map those exceptions now and align them to stronger verification before the next incident forces the change.
For practitioners
- Tighten identity recovery paths Require stronger proof before any password reset, MFA re-enrolment, or device change is accepted. Separate routine support from high-risk identity actions and make escalations visible to security operations.
- Harden MFA registration controls Eliminate phone-mediated approval paths for privileged users and replace them with phishing-resistant methods for high-risk accounts. Make MFA device additions a separately approved event, not a help desk convenience.
- Review contractor access as a primary attack path Audit third-party accounts for the same identity proofing, logging, and offboarding rigor used for employees. Pay special attention to vendor support roles that can reach operational or administrative systems.
- Treat operational urgency as a control signal Define what the help desk must never override during time pressure, after-hours incidents, or travel-related exceptions. Train support teams to challenge urgency claims and route them for secondary verification.
Key takeaways
- Scattered Spider succeeds by turning support trust into valid identity changes, which makes the help desk a front-line security control.
- The article shows how MFA weakness, contractor access, and urgency-based overrides combine into a repeatable identity abuse pattern.
- Airline teams should tighten recovery, enforce phishing-resistant authentication, and govern third-party identity with employee-level rigor.
Key terms
- Identity recovery: Identity recovery is the process used to restore access when a user cannot authenticate normally. In high-risk environments, it becomes a privileged security workflow because attackers often target it instead of the login screen. Strong recovery requires verified identity, approval controls, and full auditability.
- Phishing-resistant authentication: Phishing-resistant authentication uses methods that cannot be replayed, captured, or socially engineered through ordinary channels such as text messages or push prompts. It binds the authentication challenge to the legitimate user and device, which makes remote impersonation far harder.
- Third-party access: Third-party access is any identity granted to a contractor, supplier, or partner outside the organisation’s direct employee base. It is often operationally necessary, but it must be governed with the same scrutiny as internal access because it can provide a direct path into critical systems.
- Help desk privilege: Help desk privilege is the authority support staff have to change account state, reset credentials, and enrol authentication factors. It is effectively administrative power over identity, which means it should be treated as high-risk access with strict approvals and detailed logging.
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.
This post draws on content published by 1Kosmos: The Threat is Real and It's Here Now. Read the original.
Published by the NHIMG editorial team on 2025-06-30.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org