A strange email gives a customer something to question. A notification from the shopping app already installed on their phone starts with rather more credibility.
That is the uncomfortable part of the ASOS cyber incident reported on 6–7 October. Someone was able to put an unauthorised message into a channel customers associated with the retailer. The immediate business question is what happens when somebody else can speak with your voice.
Australian customers were among those receiving the notification on Tuesday night, with ABC News reporting the alert. This is relevant well beyond a large overseas retailer. Plenty of Australian businesses give external services permission to contact their customers every day.
What ASOS has actually confirmed
In its 6 October announcement, ASOS confirmed an unauthorised customer notification and said it was investigating activity involving third-party communication platforms. It restricted access to the notification platforms and is working with specialist advisers and relevant authorities.
ASOS says basic personal information, including names and contact details, may have been accessed. It currently does not believe payment-card information or account passwords were affected. That is its stated assessment, not a final finding about every customer's exposure.
The message claimed attackers had “fully compromised” an ASOS Snowflake instance. ASOS has not confirmed that claim. Snowflake says it has no evidence its platform itself was compromised, as reported by Computer Weekly. Access to a customer's environment and compromise of the underlying provider's platform are different claims. Neither should be inferred simply from the notification.
As at 7 October 2026, there is no basis here to describe the whole ASOS environment as compromised, say passwords or payment-card data were exposed, or assume all customers were affected identically. The route used to send the message remains unconfirmed.
Sending a message is a privilege
A customer-notification platform is a privileged publishing channel. Its permissions determine who can put words in front of people under your business's identity.
We teach customers to question unfamiliar domains, odd SMS messages and unexpected emails. An installed app changes the starting point. The customer recognises the icon and has already agreed to receive notifications. The delivery channel can be genuine while the person controlling the message is unauthorised.
If an attacker controls that channel, they do not need to spoof the brand. For the purposes of that message, they can temporarily become the brand.
Consider a booking service sending a false request to pay a deposit again, or a support platform telling customers to verify their password through a supplied link. Those are possible abuse scenarios, not claims about what happened at ASOS. The same access could create panic, distribute malicious links or make a fraudulent instruction look routine.
Customer communication security therefore includes controlling who can publish, what they can send and how quickly the business can stop them. Protecting the customer list is only part of the job.
You do not need your own app to have this problem
For a small business, the equivalent might be Mailchimp, HubSpot, Twilio, a CRM, a booking system, an SMS gateway, an e-commerce notification service or a support platform. These are examples of the category, not providers being implicated in the ASOS incident.
Some have a visible send button. Others send automatically when a record changes or another system makes a request. Both deserve attention. An integration allowed to trigger messages can carry significant authority without appearing on the staff administrator list.
My recent article on outsourced IT and third-party cyber risk makes the related point: your attack surface includes the services you connect to, not just the server you own. A secure website does not settle who can send an email carrying your name.
Who can message every customer right now?
Who, exactly, can send a message to every customer right now?
I would ask the owner and whoever manages marketing to answer that together, with the account settings open. “The agency handles it” is a starting point for the conversation. It is not an access review.
Look at individual users first. Each administrator should have their own account, protected by MFA. Shared logins make it harder to remove one person's access or establish who made a change. My guide to stronger MFA and account protection explains the options, including phishing-resistant methods where supported.
Then compare permissions with the work. Someone preparing a newsletter may need to edit drafts without managing users, exporting contacts or sending to the entire database. Give people the least privilege their role needs. Where the platform supports separate approval for broad sends, use it deliberately.
Remove former staff, agency and contractor accounts after checking dependencies. An old project does not justify permanent administrator access. Confirm that recovery addresses and account ownership remain under the business's control.
Review API keys as well. These credentials let software act without a person signing in for each request. Record which integration owns each key, whether it can send messages, who maintains it and how to revoke it. Remove unused keys and restrict active ones where possible. MFA on human logins does not automatically protect a separate sending credential.
This fits the practical approach to small-business cybersecurity: identify the access that could cause real trouble, give the fix an owner and check it was completed.
Know how to stop the next message
Before an incident, establish who can pause campaigns, disable an integration, revoke keys and remove active sessions. Check what the platform actually supports and keep its emergency support details accessible.
A password reset may leave an API key or an already queued campaign untouched. The response needs to cover the routes that can still send. Document dependencies so pausing marketing does not accidentally leave the business unable to send essential booking or service updates.
Audit trails should help answer which account or integration sent a message, when permissions changed and who received it. Confirm that logging is enabled where configurable, how long records are kept and who can retrieve them. Retain relevant records while containing an incident. The article on patching and incident response explains why closing access does not settle what happened beforehand.
Give customers another way to check
Businesses should make urgent messages independently verifiable. Publish clear updates on a known website and give support staff consistent information. Decide beforehand which channel will carry authoritative updates if the usual messaging service becomes suspect.
Customers can navigate directly to the business's known website or open its app themselves, rather than follow a link in an alarming alert. If that app's messaging is in doubt, provide an independent contact route, such as a known telephone number. Repeating the same message through the same affected system is not independent verification.
Be explicit about unexpected payment or credential requests. A familiar app icon does not guarantee that a notification is authorised. Businesses also help by avoiding routine messages that train customers to enter passwords or pay urgently through unexplained links.
Basic contact information deserves a measured response too. A name and email address are not equivalent to a password or card number, but they can make follow-on phishing and impersonation more convincing. A caller who knows where somebody shops has a more plausible opening than one guessing at random.
In private-client and high-net-worth environments, assistants, advisers, household IT providers and private service platforms may hold similar communication privileges. Limit that access, review old accounts, make revocation possible and agree which channels are authoritative.
At Solway Web Consulting, I would start this review with the systems already sending messages on the business's behalf. Open their access lists, identify the people and integrations with sending rights, and check who can withdraw those rights. A customer messaging platform carries your business's voice. Its permissions should reflect that responsibility.
Tags: security, small-business, australia