Threema knocked offline by shifting DDoS attacks, Swiss messenger says
The encrypted messaging service and its Swiss hosting partner Nine faced sustained flood attacks that changed tactics to slip past defences.
Key points
- Threema, a paid Swiss encrypted messaging app, was disrupted on Tuesday evening and Wednesday morning by a series of distributed denial-of-service attacks.
- Floods hit both Threema and its colocation partner Nine; attackers kept changing patterns to defeat mitigation.
- Business customers on Threema Work were emailed on Wednesday morning; organisations running Threema On-Prem on their own servers were unaffected.
- Threema has added upstream DDoS filtering to reduce load on its own network.
- No group has claimed responsibility, and attribution remains open.
Threema, a paid encrypted messaging service run by a Swiss company of the same name, spent much of Tuesday evening and Wednesday morning fighting off junk internet traffic. The company confirmed the outage in a Friday post-mortem, first reported by BleepingComputer.
The attacks were distributed denial-of-service floods, known as DDoS, where attackers aim huge volumes of traffic at a service until it buckles. The status page briefly showed everything as green because a separate technical fault was stopping it from updating. Threema took the page offline until it could be fixed.
What actually happened to the service?
Around 6pm UTC on Tuesday, users started seeing their apps stuck on "Connecting" instead of "Connected". Threema first blamed a network outage at its colocation partner, the Swiss hosting firm Nine. About three hours later it said the network issue had been resolved.
It hadn't. By Wednesday the picture was clearer: Threema and Nine were both being hit with sustained DDoS traffic. In its write-up, Threema said the attackers "continually changed" tactics to get around filtering, which is why defences that'd normally absorb these floods quietly couldn't keep up.
"It is not entirely clear whether Threema was the primary target or whether the attacks were directed at multiple targets," the company wrote. No cluster has claimed responsibility. In threat intelligence terms this is an unattributed disruptive event, with no public indicators tying it to a known actor. That pattern isn't unusual right now: our Cloudflare report from 11 August found terabit-scale attacks had jumped fivefold in a single quarter, and large-scale floods are increasingly used to pressure hosting providers rather than single targets.
Who was affected, and who wasn't?
Regular Threema users saw delayed or failed messages during the two disruption windows. Business customers on Threema Work got an email on Wednesday morning warning them the service was unstable.
Organisations running Threema On-Prem, the version hosted on a customer's own servers, saw no impact because their traffic never touched Threema's network.
| Product | Impact |
|---|---|
| Threema (consumer app) | Delayed and failed messages Tue evening, Wed morning |
| Threema Work | Same disruption; customers notified by email |
| Threema On-Prem | No impact, runs on customer infrastructure |
Should users worry about their messages?
No. A DDoS attack is a traffic flood, not a break-in. It knocks a service offline but doesn't compromise the content flowing through it. Threema's end-to-end encryption, which scrambles messages so only the sender and recipient can read them, wasn't touched. There's no indication that message content or key material was exposed.
If messages are delayed during a future incident, waiting rather than resending repeatedly is the better move. Check Threema's status channel for updates once the status page is trustworthy again.
What is Threema changing?
The company says it has added "specialised DDoS protection as an additional measure" that filters attack traffic upstream, before it reaches Threema's own servers. That's the standard playbook after an incident like this: push the scrubbing further out so the origin infrastructure sees a cleaner pipe.
Whether that holds against an attacker willing to keep shifting patterns is the real question. This week's floods showed that a determined operator, targeting a hosting provider alongside the application itself, can still cause hours of pain for a service that had previously absorbed DDoS traffic without users noticing. That's the detail worth watching: it wasn't Threema's defences that failed first.
