Threema, the Swiss-based privacy-focused messaging service popular with users seeking end-to-end encrypted communication outside the mainstream app ecosystem, spent the better part of two days fending off a sustained distributed denial-of-service (DDoS) campaign that intermittently knocked its hosted service offline. The company says the attacks targeted both its own infrastructure and that of its colocation partner, Nine, and that no attacker group has claimed responsibility.

A Two-Day Siege With Shifting Tactics

The disruption began on a Tuesday evening, with the service largely unavailable between 7:30 p.m. and 11:30 p.m. CEST. Rather than a single burst, the attack continued into the following morning as a wave of intermittent disruptions, with Threema describing the traffic as constantly shifting in pattern — attackers varying their traffic sources, request types, and attack signatures, likely in an effort to stay ahead of mitigation efforts. Normal operation wasn’t fully restored until 12:23 p.m. CEST on Wednesday, nearly a full day after the disruptions began.

Compounding the confusion for users during the incident, Threema’s public status page also went offline — the company says this was due to a separate, unrelated technical issue rather than a direct consequence of the DDoS traffic, but the timing meant that official updates on the outage were harder to find precisely when people were looking for them most.

What Was — and Wasn’t — Affected

Threema was clear in its communications that the incident was an availability problem, not a confidentiality or data-security one. A DDoS attack, by its nature, floods a target with junk traffic to overwhelm its capacity to respond to legitimate requests — it does not, on its own, grant an attacker access to servers, stored messages, account data, or internal systems. The company emphasized this distinction directly to users and to its Threema Work customers, who were notified separately by email.

Notably, Threema OnPrem — the version of the platform that runs on infrastructure controlled directly by customers, typically government agencies and enterprises with strict data-residency requirements — was unaffected throughout the incident, since it does not depend on Threema’s own hosted infrastructure.

An Unclear Motive, an Unclaimed Attack

As of this writing, no hacktivist group, extortion crew, or other actor has claimed responsibility for the campaign, and Threema says it remains unclear whether it was specifically and solely targeted or whether the activity was part of a broader wave of DDoS attacks hitting multiple organizations around the same time. DDoS campaigns against privacy and encrypted-communication tools have periodically drawn attention from actors ranging from state-aligned groups to hacktivist collectives to garden-variety extortionists, though attributing any specific incident without a claim of responsibility or deeper technical attribution work is inherently speculative.

Threema’s Response

In the aftermath, Threema says it has deployed a new, specialized DDoS protection mechanism centered on upstream traffic filtering — designed to strip out malicious traffic before it ever reaches the company’s internal systems, rather than trying to absorb and process it directly. That protection reportedly went live in production on August 14, 2026. The company also says it plans to expand its public status page with a fuller incident history and RSS feed support, addressing the transparency gap created when the status page itself became unavailable during the attack.

Why It Matters

Even when a DDoS attack doesn’t touch message content or account security, extended outages carry real costs for a service explicitly marketed on trust and reliability — particularly among journalists, activists, and organizations that may depend on it during sensitive moments. The incident is a reminder that availability is itself a security property: an attacker doesn’t need to break encryption or breach a database to disrupt a service that people are relying on to be there when they need it. For users of any messaging platform, privacy-focused or otherwise, the episode underscores the value of understanding a provider’s incident-response transparency and having a fallback communication channel for moments when a primary service is degraded.