When ASOS customers received alarming "ASOS HACKED" alerts on their phones, the fashion retailer faced a critical question: who controls your customer touchpoints when things go wrong?
ASOS confirmed that unauthorized access to third-party platforms used for customer communication led to the breach. Although the company hasn't verified claims that its Snowflake environment was compromised, the damage was done once those notifications reached customer devices. This incident raises a fundamental debate: should you own and operate your notification infrastructure, or rely on third-party platforms?
The Case for Third-Party Platforms
Many organizations use third-party services for push notifications, SMS, and email because building these systems internally demands significant resources. A dedicated platform manages device tokens, delivery optimization, retry logic, and compliance with Apple and Google requirements.
Third-party providers offer immediate scale. They maintain relationships with mobile operating systems and can route millions of notifications without your team managing infrastructure. When Apple or Google updates protocols, the vendor handles the changes.
Cost efficiency is a factor. A mid-sized retailer might send millions of notifications monthly but doesn't need full-time engineers for certificate renewals or troubleshooting. The platform provider employs specialists to solve these problems.
Integration speed is another advantage. Your team can implement push notifications in days. Most platforms provide SDKs, handle authentication, and offer analytics dashboards without custom instrumentation.
The Case for Owned Infrastructure
The ASOS incident highlights the risk: delegating your communication channel means losing control when you need it most. Unauthorized access allowed attackers to speak directly to customers using ASOS's voice.
You own the liability, regardless of who operates the platform. Article 28 of the GDPR requires processors to act on your instructions, but customers don't differentiate between "ASOS's vendor was compromised" and "ASOS was compromised." The notification came from the ASOS app, and the trust violation is yours.
Incident response becomes dependent. ASOS had to coordinate with the third-party platform to investigate, determine scope, and prevent further unauthorized notifications. You can't independently verify what happened or when access began. Your breach timeline depends on another organization's forensic capacity.
Notification infrastructure isn't overly complex at scale. If you're already operating mobile apps and APIs, adding a notification service is engineering work, not research. You trade vendor dependency for operational responsibility, gaining the ability to implement controls that match your risk appetite.
Data residency and access controls become enforceable. When you own the infrastructure, you can implement security on customer contact details, restrict access, and audit every query. Third-party platforms may offer these controls, but you're trusting their implementation rather than verifying your own.
Where Practitioners Actually Land
Most organizations use third-party platforms and focus risk management on vendor assessment and contract terms. They require SOC 2 Type II reports, negotiate liability caps, and implement measures to limit vendor data access.
A practical middle ground involves segmentation. High-risk notifications (password resets, payment confirmations, security alerts) route through owned infrastructure. Marketing messages and promotional content use third-party platforms. This approach focuses engineering resources where unauthorized access would cause the most damage.
Some teams use a hybrid model: they own the notification decision engine and customer preference data but use third-party platforms for delivery. The vendor receives a device token and message content but never stores customer identities. This limits breach exposure to active messages in transit.
Organizations with sufficient engineering capacity increasingly bring notification infrastructure in-house as apps mature. The initial speed advantage of third-party platforms diminishes once you've built the integration. Ongoing costs shift from vendor fees to internal overhead, but you gain control during incidents.
Our Take
Own the channel if you can justify the engineering investment. The ASOS breach shows that notification platforms aren't peripheral systems. They're direct communication channels to your customers, and unauthorized access lets attackers impersonate you at scale.
If you use third-party platforms, implement these controls immediately:
Require multi-factor authentication and break-glass access procedures for any account that can send notifications. The ASOS incident suggests credential compromise or API key exposure. Standard authentication isn't enough for systems that can broadcast to your entire customer base.
Implement notification approval workflows for any message outside predefined templates. Marketing teams shouldn't be able to send arbitrary content without technical review. Pre-approved message templates reduce the attack surface.
Monitor notification sends in real-time. Set up alerts for sends outside business hours, exceeding normal volume thresholds, or containing keywords suggesting compromise. ASOS customers received notifications at around 5:00 a.m. ET. Automated monitoring would have detected the anomaly quickly.
Maintain an incident response plan assuming notification platform compromise. You need the ability to revoke API credentials, disable the integration, and communicate with customers through an alternate channel. ASOS displayed an in-app warning, but only after unauthorized notifications reached customers.
The debate isn't about owned versus third-party infrastructure. It's about whether you're willing to accept that your incident response depends on another organization's cooperation. ASOS still hasn't confirmed whether its Snowflake environment was compromised or disclosed how many customers were affected. That uncertainty is what you're buying when you delegate control.
