The ASOS Breach Wasn't About Snowflake — It Was About the Vendor You Forgot You Had

Imagine getting a push notification from an app you know and trust, telling you there has been a security incident. Now imagine that notification was sent by the attacker, using the brand's own tools, to the brand's own staff. That is roughly what happened in the ASOS case — and it is one of the most quietly instructive breaches of recent years, precisely because the story got buried under a public argument about whose fault it was.

When the ASOS incident surfaced, a lot of the coverage latched onto a familiar name: Snowflake. Snowflake had been in the headlines for a wave of credential-stuffing attacks against customer environments, and so it became the easy villain. ASOS pointed outward. Snowflake pointed out that the issue wasn't a flaw in its platform, but compromised customer credentials and missing multi-factor authentication. Both can be true at once, and both miss the more uncomfortable point.

The breach wasn't really a story about one big, obvious SaaS platform. It was a story about the vendor you forgot you had.

The vendor nobody put on the list

Every business has a mental map of its important suppliers. For most SMEs it looks something like this: the accounting software, the CRM, Microsoft 365 or Google Workspace, the hosting provider, maybe a payroll bureau. When the subject of a 'supplier audit' comes up, these are the names that get written down. They are the systems people log into every day, so they feel like the attack surface.

But sit down and actually trace what happens when your business communicates with the outside world, and a second tier of suppliers appears — one almost nobody includes in a risk assessment.

Think about it. When a customer gets an order confirmation, who actually sends that email? Probably not you — probably a transactional email provider. When you send a marketing campaign, who holds your subscriber list and your templates? When your app fires a push notification, which platform routes it? When your website shows a live chat widget, whose code is running inside your page? When staff get an SMS alert, which gateway did it travel through?

These are communication and notification vendors, and they are everywhere. They sit between you and your customers, and often between you and your own employees. They hold contact data, message content, and — critically — the right to speak in your voice. That last part is what makes them so dangerous when compromised.

In the ASOS episode, the detail that should keep CISOs awake isn't that data moved through a third party. It's that a third-party communication channel became the medium through which the incident itself played out — the retailer's own notification pathway turned into a tool. Once an attacker controls the thing that sends trusted messages, they don't need to fake a login page or spoof a domain. The message is already trusted. It's coming from inside the house.

Why 'not our platform' is not an answer

The public finger-pointing is the part worth learning from. ASOS says the breach came through a third party. The third party says the breach came through poor credential hygiene on the customer side. A reasonable observer reads that and concludes: it doesn't matter who's technically right, because to the affected people, it was still an ASOS incident.

That is the uncomfortable rule for every SME. When a vendor in your chain is compromised and your customers or staff are harmed, 'it wasn't our platform' is not a defence anyone cares about. Your name is on the notification. Your customers hold you responsible. The ICO holds you responsible as the data controller. And your reputation absorbs the damage regardless of which company's server was the entry point.

Snowflake was arguably correct on the facts. It still ended up named in headlines alongside dozens of breached organisations, because being technically blameless doesn't stop you being associated with the mess. The lesson cuts both ways: whether you are the brand or the platform, the blast radius of a third-party compromise lands on everyone in the chain.

The blind spot in most SME audits

We see this pattern constantly with new clients in Nottingham and across the East Midlands. A business will have a tidy list of its 'IT systems' and a reasonable handle on its main SaaS tools. But ask three questions and the gaps appear fast:

• Which external services can send messages that appear to come from us? Email platforms, SMS gateways, push-notification services, chat widgets, review-request tools, booking confirmations.
• Which of those services hold our customer or staff contact data? Usually all of them, to some degree.
• Who actually set each one up, and is MFA switched on? This is where the silence gets loud. Half of these tools were configured years ago by someone who has since left, with a shared password and no second factor.

That third point is exactly the weakness the Snowflake-era attacks exploited: valid credentials, no MFA, and no one watching for unusual logins. It wasn't clever malware. It was a side door that nobody had locked, on a platform nobody had on their list.

Marketing and notification vendors are especially prone to this because they're often procured outside IT. The marketing team signs up for an email platform. The ops team adds an SMS alerting tool. The dev team drops a chat widget into the site. Each decision is small and sensible on its own. Collectively they create a web of trusted senders that no single person has mapped.

What mapping the full chain actually looks like

The fix isn't glamorous, but it works. It starts with building the real inventory — not the comfortable one.

A proper vendor map goes beyond the systems people log into and captures every external service that touches your data or speaks on your behalf. For each one you want to know: what data does it hold, what can it send, who owns the account, is MFA enforced, and what would happen if it were compromised tomorrow morning.

From there, the practical hardening is straightforward:

• Enforce MFA everywhere it's available, and treat any vendor that can't offer it as a risk to be flagged, not quietly tolerated.
• Kill shared logins. Named accounts with individual credentials mean you can revoke access cleanly when someone leaves.
• Review what each integration can actually do. A marketing tool rarely needs the sweeping permissions it asked for at setup.
• Set up alerting for unusual activity — new sign-ins, bulk exports, template changes — on the platforms that can broadcast to your audience.
• Agree, in advance, how you'd respond if a comms vendor were breached. If your notification channel is compromised, how do you warn people without using it?

That last question is the one the ASOS story forces. If the trusted channel is the one under attacker control, your incident plan can't assume it's available.

Where your IT partner comes in

This is precisely the kind of work that falls through the cracks when a business treats IT as a break-fix service rather than a strategic one. Mapping a full vendor chain requires someone who understands both the technical integrations and the business processes behind them — and who has the authority to ask the marketing team why their email platform has no MFA.

At Cloudworks, this is a standard part of how we onboard and review clients: not just securing the obvious stack, but tracing every supplier that can hold your data or send in your name, and closing the gaps on the ones you'd forgotten existed. The ASOS breach is a useful reminder that the next incident probably won't arrive through the platform you check every day. It'll come through the one you haven't thought about since you set it up.

The vendor you forgot you had is the one worth finding first.