M&S Got Hit Through a Vendor: The Question Indian IT Firms Must Answer

On May 13, 2025, the M&S breach was confirmed to involve customer data theft — and the way in was a vendor. The attackers, the group known as Scattered Spider, got into Marks & Spencer through its IT helpdesk contractor, Tata Consultancy Services, using the login credentials of two TCS employees. The Co-op attack ran in parallel; the UK's Cyber Monitoring Centre later classified them as a single combined event with an estimated impact of up to $592 million. If you're an Indian IT vendor with access to a client's systems, your next client security review just got harder. This post is the set of questions you'll be asked — and the answers that win the contract instead of losing it. ## The Answer in 60 Words Scattered Spider breached M&S through its IT helpdesk vendor TCS, using two employees' credentials — likely obtained by social-engineering the help desk into an MFA reset. The lesson for Indian IT vendors: your client now treats your access as their attack surface. Win the review by showing scoped least-privilege access, phishing-resistant MFA, a hardened help-desk verification process, and a clean answer to "who at your firm can touch our systems." ## Why this matters now (May 2025) The M&S and Co-op attacks moved supply-chain risk from a slide in a compliance deck to a board-level number. Per The Hacker News reporting, Scattered Spider was behind both, with combined damages estimated up to $592 million. M&S later moved to review its service-desk arrangements with TCS, though TCS stated its own systems were not the source of the breach. For Indian IT services firms — a huge share of the global outsourced help-desk and managed-services market — this is the moment clients start auditing vendor access seriously. We've already seen the pattern in the breaches we covered in the Adobe BPO vendor-access audit and the SharePoint ToolShell vendor questions. ## What actually happened (the attack chain) The attack didn't start with a clever exploit. It started with a phone call. Scattered Spider's signature move is social-engineering a help desk into resetting credentials or MFA for an account they don't control. ## The questions your client will now ask (and the answers that win) ## The vendor-access controls checklist This is the checklist we run with Indian IT vendors who want to pass a client security review post-M&S. Hit these and you're ahead of most of the field.

• Least-privilege access — every vendor account scoped to exactly what the role needs, nothing more
• Phishing-resistant MFA (FIDO2/passkeys) on every account that touches a client system
• Just-in-time access — privileged access granted for a task and auto-revoked after, not standing
• A documented help-desk verification process with manager approval for privileged resets
• Quarterly access reviews with a named owner and a written sign-off
• 24-hour deprovisioning when an employee leaves or changes role
• Privileged-session logging, time-boxed and reviewable for at least 90 days
• A vendor-security questionnaire you've already answered, ready to hand over

## The help-desk hardening steps (where the breach actually happens) Scattered Spider's edge is the help desk, so that's where to spend your hardening effort. Here's the process we put in. ## What a vendor breach actually costs (the numbers that move a board) The reason this stopped being a compliance footnote is the size of the bill. The M&S case put real figures on what a vendor-route breach does to a public company, and those numbers are what your client's board now has in mind when they audit you. Now translate that to your contract. You don't carry $592 million of exposure, but you carry the thing that sits upstream of it: the access that let it happen. When a client prices the risk of working with you, they multiply the damage a breach would do by how easy your access makes it. Tightening the access side is the only variable you control, and it's the one a security review actually measures. A vendor who can show scoped access and hardened help-desk verification is quantifiably cheaper to insure against — and that shows up in whether you win the deal. ## Common mistakes Indian IT vendors make Symptom: "We use MFA, so we're covered." Cause: SMS or push MFA, which Scattered Spider routinely defeats via SIM-swap and push-fatigue. Fix: move privileged access to FIDO2/passkeys. Not all MFA is equal. Symptom: "Our access list is whatever was set up at onboarding." Cause: no review cadence, so access accretes and ex-employees keep credentials. Fix: quarterly reviews with a named owner and 24-hour deprovisioning. Symptom: "The help desk resets MFA when a manager calls in stressed." Cause: no callback rule, social pressure works. Fix: no identity action on a single inbound call, ever — even for the CEO. Especially for the CEO. Symptom: "We can't produce an access log for a client audit." Cause: privileged sessions aren't logged. Fix: log and time-box every privileged session; keep 90 days. You'll be asked for this, and "we don't have it" loses the contract. Symptom: "We answer security questionnaires from scratch each time." Cause: no maintained vendor-security pack. Fix: keep a current questionnaire answer-set; it speeds the sale and signals maturity. ## A note on the "blame the vendor" trap TCS stated the breach did not originate from a compromise of its own systems, and the full forensic picture took months. The point for Indian vendors isn't to assign blame — it's that the client doesn't care whose fault it was when their customer data is on a leak site. The contract, the reputation, and the relationship take the hit regardless. Founder Vivek Singh has written about this on his personal blog: in a vendor relationship, perceived responsibility follows access, not fault. If you hold the keys, you own the question. ## Real example: a vendor-access review we ran An Indian managed-services firm (around 200 staff, providing help-desk and infra support to UK and US mid-market clients) came to us after a prospect's security team failed them on the vendor review — specifically on help-desk verification and standing privileged access. The review was led by Vivek, our co-founder. We ran a two-week audit through our security and automation practice: mapped every account with client access, moved privileged accounts to hardware-key MFA, implemented just-in-time access so standing admin rights dropped to near zero, and rewrote the help-desk runbook with a callback rule and manager-approval gate. They passed the re-review and closed the contract. The access-scoping discipline is the same one we apply on regulated client builds like Radiant Finance, where privileged data access has to be locked down by role from day one. We've since run the same playbook for two more vendors, and it parallels the customer-support access work in our Discord-breach support-audit post. We track Scattered Spider's evolving tactics against the r/cybersecurity community and the supply-chain takeaways from RSAC — help-desk social engineering remains their most reliable initial-access method into large enterprises through their vendors. ## When this level of control is overkill If you're a 3-person dev shop building marketing sites with no production access to client data, the full FIDO2-plus-just-in-time-plus-quarterly-vishing programme is more than your risk warrants — and a client asking for it is mis-scoping. Match controls to access. The vendors who need every item on the checklist are those with standing privileged access to systems holding personal or financial data. A vendor with read-only access to a staging environment is a different risk conversation. Don't let a security-theatre questionnaire push you into controls that don't fit your actual access footprint. ## FAQ ### How did attackers get into M&S? Through its IT helpdesk vendor, TCS. The group Scattered Spider used the login credentials of two TCS employees — most consistent with help-desk social engineering to reset access or MFA. No software zero-day was the entry point; a human with valid credentials was. ### Was payment-card data stolen in the M&S breach? No. M&S stated no payment-card details, bank information, or account passwords were taken. The stolen data included customer names, dates of birth, contact details, and online order history — still sensitive enough to trigger notification and reputational damage. ### Why are Indian IT vendors specifically exposed here? Indian firms provide a large share of the world's outsourced help-desk and managed services, which means they often hold privileged access to client systems. The M&S case makes vendor access the focus of client security reviews, and that scrutiny lands disproportionately on outsourced providers. ### What MFA actually stops Scattered Spider? Phishing-resistant MFA — FIDO2 hardware keys or passkeys. SMS codes are SIM-swappable and push notifications are defeated by fatigue attacks, both of which the group uses routinely. Hardware-bound factors are the control they have not reliably beaten. ### What is the single highest-impact help-desk control? No identity action on a single inbound call. A help desk that never resets a password or MFA based on one phone call — always calling back on the number of record — breaks the most common initial-access path. Add manager approval for privileged-account resets. ### How long does a vendor-access review take? We typically run a focused review in two weeks: access mapping, MFA hardening, just-in-time access, and a help-desk runbook rewrite. A full programme with quarterly vishing simulations is ongoing, but the core gaps that fail a client review are closable in a fortnight. ### Does this matter under India's DPDP Act too? Yes. The DPDP Act makes you accountable for personal data you process, including through vendors. A vendor breach exposing personal data is your liability as the data fiduciary, so vendor-access controls are a compliance requirement, not just good practice.