August 16, 2025

Insight

The £300m Lesson From M&S: Your Supply Chain Is a People Problem

Marks & Spencer's 2025 cyberattack didn't start with "elite malware." It started with people (at a third party supplier) being socially engineered. The fallout? A hit measured in the hundreds of millions and weeks of disruption. If you rely on vendors (you do), this one's uncomfortably relevant.

widget pic
widget pic

When M&S warned investors in May 2025 that an April breach would knock hundreds of millions off results, it was a wake‑up for anyone who thinks "we're fine; our tech stack's modern." Reporting suggests attackers phished a third‑party vendor's staff, reused those credentials, and then walked through the side door - classic supply‑chain social engineering, not a zero‑day thriller.

Credible estimates put the financial impact in the £300m+ range (some coverage translated to c.$400m), with weeks of operational disruption - including online downtime - compounding the losses. The Financial Times highlighted how human manipulation via a supplier enabled access and drove the scale of the damage.

Two blunt truths:

  1. If attackers can trick one person at a supplier, they can be inside your systems by lunchtime.

  2. Your board will not care whether the credentials came from you or them.

What actually failed (and often does)

  • Helpdesk verification at the supplier. Reporting points to impersonation and password reset games. If your vendor can be hustled into resetting an account tied to your environment, you inherit their weakness.

  • Third‑party access governance. Over‑broad roles, stale accounts, and shared credentials are normalised in many IT service arrangements. Once phished, it's open season.

  • Assumptions about caller ID / "known" numbers. Social engineers lean on urgency and identity theatre. UK incidents keep proving it.

This isn't unique to retail; it's any UK scale‑up leaning on MSPs, integrators, and offshore dev teams.

The practical fix (not theory, not theatre)

1) Contract for verification, not vibes
Bake specific controls into supplier agreements and measure them:

  • Admin resets require two‑person, two‑channel verification.

  • No resets based on inbound calls; callbacks only to pre‑registered numbers.

  • Mandatory MFA with phishing‑resistant factors (passkeys/FIDO) for all privileged roles.

  • Map these to ISO/IEC 27001:2022 Annex A 5.19-5.23 (supplier security, agreements, ICT supply chain, monitoring, cloud).

2) Shrink and segment third‑party blast radius

  • Minimum‑privilege, just‑in‑time access; no standing admin.

  • Separate break‑glass paths, logged and reviewed.

  • Hard network and identity boundaries between supplier environments and yours.
    This aligns with NCSC supply chain security principles.

3) Attack the helpdesk attack

  • Runbook scripts that force staff to collect a ticket ID, call back on a known directory number, and perform challenge-response known only to real users.

  • Simulate "angry exec" scenarios monthly; measure refusal rate and escalation speed.
    The Times reporting on password‑reset social engineering is your case study.

4) Instrument what matters

  • Metrics: % of privileged resets with dual verification; # of stale supplier accounts; mean time to disable vendor access after contract end; failed simulation rate.

  • Quarterly evidence pack for audit/insurers: reset logs, access reviews, simulation outcomes.
    This satisfies auditors far more than "we train annually."

5) Don't wait for the post‑mortem

  • Table‑top the exact M&S pattern: supplier phished → helpdesk reset → lateral movement → SaaS data exfil.

  • Add a kill switch: immediate vendor account suspension on anomaly; pre‑authorised comms route to the vendor's CISO.

The takeaway for your board

This wasn't a "state‑of‑the‑art exploit." It was a people‑and‑process gap at a supplier that turned into hundreds of millions in impact for a household UK brand. Your exposure looks the same if your vendor access and helpdesk protocols are soft.

Fix what fails in the real world: vendor verification, least‑privilege access, and rehearsed helpdesk scepticism (with logs to prove it).