ASOS Data Breach: The Real Cause Behind the 'ASOS HACKED' Notification

Cyber Security Data Breaches Identity Security Incident Response

ASOS Data Breach: The Real Cause Behind the 'ASOS HACKED' Notification

Three weeks after the unusual customer notification, ASOS has confirmed stolen employee credentials and access to third-party platforms. Here's what businesses can learn from the incident.

Written by Jordan Stewart Cyber security and incident response
ASOS data breach: the real cause behind the ASOS HACKED notification
The short answer

Three weeks have passed since ASOS customers got a concerning-looking notification, informing the ASOS DPO and IT department that their Snowflake instance had been ‘fully compromised in a dramatic claim sent to customers on the 6th of October 2026. ASOS has since said that an attacker impersonated a trusted contact, obtained an employee's login credentials and used them to access information held in third-party platforms. Names, contact details and other account-related information were accessed, while ASOS says payment card details and account passwords weren't.

The strange push notification was the public spectacle, yet the more useful business lesson sits behind it: one trusted identity reached more than one external platform, and at least one of those platforms could speak directly to customers.

From a strange notification to a clearer account

At around 10am on the 6th of October, some ASOS customers received a push notification headed “ASOS HACKED”. It was addressed to the retailer's data protection and IT teams, claimed that a Snowflake instance had been compromised and directed readers towards a Telegram contact.

There’s no two ways about it, it was an unusual (and unique) way for an incident to go public. Most businesses hope to tell customers what has happened after the response team has established the facts. In this case, the attacker appears to have reached a trusted customer channel first, and then used it to apply pressure in public.

ASOS's first statement confirmed that the notification was unauthorised and that activity involving third-party customer communication platforms was under investigation. It said names and contact details may have been accessed, but payment card information and account passwords weren't believed to be affected.

That left several obvious questions. Was Snowflake itself compromised? Had information actually been copied? How had somebody reached both the customer data and the notification channel? A few weeks later, the picture is getting clearer, although it still isn't fully complete just yet.

What ASOS has now confirmed

ASOS's current customer update says an unauthorised party impersonated a trusted contact and obtained an employee's login credentials. Those credentials were then used to access information on certain third-party platforms used by ASOS.

The retailer says the affected platforms were locked down and that its investigation, supported by internal and external specialists, is continuing. It has confirmed access to some personal information, including names and contact details, as well as certain non-personal account-related information. Crucially, it says no payment card information or account passwords were accessed, and that its website and app were safe to use throughout.

Separate reporting has added more detail - the BBC reported that a sample of the downloaded customer profiles shown to it contained names, postal addresses, phone numbers, email addresses, customer numbers, dates of birth and website searches. ASOS hasn't publicly confirmed the complete set of fields across every affected record or the final number of customers involved.

What remains unconfirmed

The attacker's original Snowflake claim shouldn't be treated as an established technical finding. Snowflake said its platform hadn't been compromised, and ASOS's public account focuses on stolen employee credentials and access to third-party services. That could still involve a customer environment built on or connected to Snowflake, but it isn't the same as a security failure in Snowflake's underlying platform.

The final scope also remains open: ASOS says its investigation will continue and that it will contact customers directly if additional information, support or action is required. Until that work is complete, any PR-approved statements about exactly how many people were affected or precisely which fields were taken may still be a little way away.

Why the stolen information still matters

Of course, there’s a natural temptation to hear “no passwords or card details” and take it to mean “no real risk”, but that would be a little too optimistic.

A name, address, date of birth and recent search can give a criminal enough context to sound convincing. A fake courier message can mention the right postcode. A refund call can refer to an item someone looked at. An account-security email can arrive weeks later, after the incident has fallen out of the news.

None of that proves - or even guarantees - a follow-on scam will happen. It does explain why the National Cyber Security Centre has advised ASOS customers to assume they may be affected and to stay alert for suspicious messages, including those that arrive some time after the breach.

For what it’s worth, ASOS says customers don't need to take action on their accounts at present. The sensible ways to move forward, if you’re planning on treating yourself after the recent payday, is to use the official app or website directly - don't follow an unexpected link, never share a password or one-time code with an unsolicited caller, and make sure the password used for ASOS isn't reused elsewhere.

The push notification is more than an odd detail

For a customer, a push notification from an installed app carries a certain authority. It doesn't arrive from an unfamiliar email domain or an obviously misspelt sender. It appears on the lock screen of your own device, delivered under a brand the person already knows and probably uses a handful of times a year (at least).

That makes a customer messaging platform more than a marketing tool. It is part of the organisation's security perimeter and, during an incident, part of its crisis infrastructure too.

If an attacker can publish through that channel, they can create confusion, direct customers towards a malicious destination, or undermine the company's later updates. The business may then have to explain the incident through the very system whose integrity is in question. That's a fairly uncomfortable communications meeting.

What UK businesses should take from the ASOS data breach

Treat publishing access as privileged access

The ability to send an email, SMS, in-app message, or push notification to thousands of people deserves the same level of care as other high-impact administrative access. Identify every account and integration that can publish to customers. Remove access granted to old roles, agencies, or abandoned campaigns, and use phishing-resistant multi-factor authentication where the service supports it.

The important question isn't only who can open the platform, but also to whom can send, export, change permissions, new administrators created, or access generated access tokens. Those actions should be limited and, where practical, separately approved.

Protect the identity path, not just the application

ASOS's account points to impersonation and stolen credentials rather than a cinematic piece of malware, which is precisely why “we have MFA” needs a follow-up question: what happens during account recovery, help desk verification and supplier support calls?

Staff with powerful access need a reliable way to verify unusual requests through a second route. A familiar display name, a convincing voice or knowledge of an internal project isn't enough. Recovery and reset procedures should be tested against the same social-engineering pressure as the normal sign-in process.

Know what your third parties can see and do

Think about where your customer data lives… I’d have a stab in the dark and say, like most others, it probably doesn’t live in one tidy database. It flows through CRM, analytics, support, personalisation and communication services, often owned by different teams. Each platform may be legitimate on its own, while the combined picture becomes far richer than anyone intended.

Keep an inventory of the services that hold customer information, the data sent to each one and the internal owner. Record the supplier's emergency contact route, what logs are available, how quickly access can be suspended and what the contract says about preserving evidence and reporting an incident.

Make unusual activity visible

A bulk export, a new administrator or a message sent to the full customer list should produce a useful alert. ‘Useful’ is doing an awful lot of heavy lifting there, if we’re honest: somebody must receive it, understand why it matters and be able to act before the log disappears into a mailbox nobody checks.

Test the evidence in advance. Can you identify who exported a file? Can you see which administrator approved a campaign? Can you revoke active sessions and tokens? How long are the logs retained? An incident is a poor time to discover that the audit trail was an optional subscription.

Plan a second route for incident communications

The NCSC recommends preparing alternative communication channels because normal systems may be unavailable or untrusted during an incident. For a smaller business, that might mean a pre-agreed website status page, an independently managed social account, a customer helpline and an offline contact list for key suppliers and staff.

The alternative route must be protected and understood before it is needed. A dormant status-page account with one shared password isn't much of a fallback.

Write updates that can survive changing facts

The first hours of an investigation are full of partial information and hunches about what’s right - or what’s happening. Communications should avoid that speculation, though, and only say what’s confirmed, what’s being checked and when the next update is expected. Avoid absolute reassurance that may need to be withdrawn later.

If personal data is involved, the legal clock matters too. The Information Commissioner's Office says a notifiable personal data breach must be reported without undue delay and within 72 hours of the organisation becoming aware of it. When the risk to individuals is high, they must be told without undue delay in clear, plain language, with practical advice on what to do.

Five questions to ask this week

  1. Which systems can send a message to all customers, staff or suppliers?
  2. Who has administrative or publishing access to each one, including agencies and service accounts?
  3. Would a bulk export, a new administrator, or a mass notification create an alert that someone will actually investigate?
  4. Can account recovery and supplier requests be verified through a separate trusted route?
  5. How would we publish an authoritative update if email, the website, or the normal customer messaging platform were no longer trusted?

The useful lesson is behind the notification

The ASOS data breach attracted attention because the attacker appeared on customers' lock screens. Three weeks on, the more important detail is rather less theatrical: a trusted contact was impersonated, an employee's credentials were obtained, and third-party platforms were reached.

That chain will look familiar to many UK organisations. The software may differ, and the audience may be smaller, but the same concentration of access exists across CRM systems, mailing platforms, support tools, and cloud applications in the mid-market.

A sensible next step isn't to buy a product because ASOS appeared in the news. It is to trace the route from one employee account to the systems that hold customer data and the channels that speak in your company's name. Then ask where that route should stop, what would make unusual behaviour visible and how you would communicate if it didn't.

ASOS data breach FAQs

What happened in the ASOS data breach?

ASOS says an attacker impersonated a trusted contact, obtained an employee's login credentials and used them to access information in certain third-party platforms. The attacker also sent an unauthorised push notification to customers through an ASOS communication channel.

What information was accessed?

ASOS has confirmed access to names, contact details and certain non-personal account-related information. It says payment card information and account passwords weren't accessed. The BBC reported that a sample shown to it also included postal addresses, phone numbers, email addresses, customer numbers, dates of birth and website searches. ASOS hasn't confirmed the final scope across all affected records.

Was Snowflake breached?

The unauthorised notification claimed that an ASOS Snowflake instance had been compromised, but ASOS hasn't confirmed that account. Snowflake said it found no compromise of its platform. The confirmed ASOS explanation centres on stolen employee credentials and access to third-party platforms.

Do ASOS customers need to change their password?

ASOS says account passwords weren't accessed and that customers don't currently need to take action on their accounts. Customers should still use a unique password for ASOS. If the same password has been used elsewhere, it should be changed on those other accounts.

What should SMEs learn from the ASOS breach?

Customer communication services should be treated as privileged systems. SMEs should restrict publishing and export access, protect account recovery, monitor high-impact actions, understand the access held by third-party platforms and keep an alternative incident communication route ready.

The Last Word

Could one employee account reach your customer data and the channels speaking in your company's name? Fifosys can help you review identity controls, third-party access, monitoring and incident response arrangements, then turn the gaps into a practical improvement plan.

Talk to the Fifosys team

Jordan Stewart
Jordan Stewart Fifosys insights, news and practical technology guidance for UK business leaders.
Talk to Fifosys

Understand your exposure before an incident

From identity security and third-party access to threat detection and incident response, we help UK businesses identify weaknesses, prioritise improvements and put practical protection in place.

Next
Next

AI Workforce Strategy Lessons from Microsoft, Barclays, and IKEA