Threema DDoS Outage Shows Encryption Is Not Availability

Threema says a series of large-scale DDoS attacks against it and colocation partner Nine caused a four-hour outage on Tuesday, August 11 and intermittent interruptions the next morning. Normal service returned at 12:23 p.m. CEST on August 12. Threema says it was unclear whether the messenger was the primary target or one of several targets, and it has not attributed the activity to an actor.

The incident is an availability failure, not evidence that Threema's end-to-end encryption was broken or message contents were exposed. It still matters for organizations that depend on the service during an emergency. Threema activated upstream filtering on August 14 and plans to add status history and RSS, but customers should test an independent notification path, define message-delay behavior, preserve local crisis contacts, and decide whether their backup channel shares providers, identity systems, networks, or devices with the primary one.

Threema's August 14 postmortem places the main outage on Tuesday evening, August 11. The service was unavailable from 7:30 p.m. until 11:30 p.m. CEST. Large-scale DDoS activity resumed Wednesday morning, producing intermittent brief interruptions until normal operations were restored at 12:23 p.m. Threema says all services remained fully operational after that point. The current status page shows messaging, media and files, calls, Safe, Work management, Broadcast, Gateway, and the website as operational.

The vendor says the attacks continued over an extended period and changed patterns as defenders adapted. They targeted Threema and its colocation partner Nine. That shared target boundary matters because filtering and capacity at the hosting or transit layer can affect more than one application. Threema explicitly says it is not entirely clear whether the messenger was the main target or whether several targets were involved.

No responsible actor, motive, traffic volume, protocol distribution, botnet, ransom demand, or geographic source is confirmed in the postmortem. Threema notes that well-resourced actors can generate difficult attacks, including potentially state actors, but it does not attribute this event to a state. Reporting should stop at a sustained, adaptive DDoS campaign against the service and its colocation partner.

Threema says a denial-of-service attack targets availability and does not grant access to systems or data. For this incident, the company does not report message disclosure, key compromise, unauthorized account access, or an intrusion. That distinction is essential. A flood that prevents clients from reaching a relay does not by itself defeat the cryptography protecting a message. At the same time, a DDoS diagnosis is not a universal proof that no other activity occurred, so providers still need separate monitoring for authentication, application, and infrastructure anomalies.

Threema's documented design helps explain the boundary. Private keys are generated and kept on user devices. The server stores public keys and forwards end-to-end encrypted messages, while undelivered data may be held temporarily for asynchronous delivery and deleted after successful delivery. The whitepaper says the inner end-to-end encryption layer passes through the server without the server being able to remove it. Those properties protect content from the relay, not the route to the relay.

During an outage, messages may be delayed, calls may fail, group coordination may stall, and users may not know whether a send state reflects the recipient, their own network, or the provider. A confidential message that arrives after an evacuation decision can still be operationally useless. Security reviews for a messenger therefore need separate claims and tests for confidentiality, integrity, identity, metadata, endpoint safety, and availability.

Threema says its status page was initially not updated because of a technical problem unrelated to the DDoS attack. The company temporarily took the page offline until that issue was resolved. Service updates instead went through social channels, while Threema Work customers received email Wednesday morning and account managers answered inquiries. Those measures provided useful alternatives, but they arrived across channels that customers may not monitor or may be unable to trust during a wider incident.

A status site is part of the incident system, not a marketing accessory. It should be hosted and operated far enough from the production service that the same edge, identity provider, DNS zone, deployment pipeline, administrator access path, or capacity event does not silence both. Update authorization needs its own strong controls so attackers cannot turn an outage into a false recovery notice or malicious instruction. Subscribers also need a feed that does not depend on opening the affected app.

Threema says it will add incident history and an RSS feed to the status page. That is a useful improvement because history supports post-incident accountability and RSS offers machine-readable updates. Organizations should still ingest the feed into a separate monitoring and paging system, document the official domains and sender identities in advance, and forbid recovery instructions that ask users to weaken device security or disclose secrets.

Threema activated specialized upstream DDoS protection in production at 6:05 p.m. CEST on August 14 after final stability testing. Upstream filtering is valuable because malicious traffic can be discarded before it consumes the target's own links and infrastructure. CISA, the FBI, and MS-ISAC similarly recommend coordinating with Internet and hosting providers, enabling mitigation services, filtering traffic, preserving evidence, and designing high-availability or load-balanced systems around critical services.

The change introduces questions the public postmortem does not answer. Threema has not named the mitigation provider, described which traffic is visible to it, published false-positive handling, explained fail-open or fail-closed behavior, or stated how the filter interacts with all messaging, call, media, Gateway, and management endpoints. Those gaps do not imply a problem. They are the validation work that follows any emergency edge change, especially for a privacy-sensitive service.

Operators should measure more than uptime. Useful evidence includes legitimate connection success by client version and region, message-queue age, call setup success, media delivery, retry behavior, filter challenges, dropped traffic, and time to change a mitigation rule. Capacity exercises should test an attack that shifts protocol or endpoint rather than repeating one known packet pattern. The goal is to preserve legitimate service while the attack changes.

Threema markets Work as an out-of-band channel when corporate email or collaboration systems fail. The August outage demonstrates the reciprocal planning requirement: organizations also need a path for when Threema itself is unavailable. That path could combine emergency calling, SMS, a second managed messenger, radio, a phone tree, or a read-only incident portal. The correct choice depends on the mission, recipients, geography, accessibility needs, and the sensitivity of the messages.

Independence must be tested rather than assumed. Two apps on the same phones may still depend on the same mobile carrier, push-notification service, identity provider, device-management platform, DNS resolver, cloud region, help desk, or administrator. A status page and primary service behind the same provider can fail together. A backup channel that requires users to retrieve credentials from the unavailable primary system is not ready. Pre-enrol users, distribute verified contacts, and keep the activation procedure available offline.

Run an exercise with the primary messenger blocked. Measure how long it takes leaders to recognize the failure, authenticate the alternate channel, reach critical groups, confirm receipt, and return to normal without creating conflicting instructions. Define which data may cross the fallback channel and which decisions must wait for a higher-assurance path. The exercise should include lost devices, absent administrators, expired credentials, and a false status message.

Threema says OnPrem customers were unaffected because their installations use their own infrastructure. That separation is a genuine failure-domain difference. It does not mean OnPrem is automatically more available. The customer becomes responsible for Internet edges, capacity, filtering, load balancing, monitoring, upgrades, backups, staff, physical sites, and the dependencies needed by mobile and desktop clients.

An air-gapped or internal deployment can be appropriate for a closed organization, while an Internet-reachable deployment still needs DDoS engineering. Buyers should compare the hosted and self-managed models using evidence: topology, provider diversity, recovery objectives, attack-mitigation capacity, update ownership, status-channel independence, and results from exercises. The August incident shows one hosted dependency path; it does not establish that every private deployment would have survived the same traffic or adapted faster.

A stronger follow-up from Threema would publish per-service impact, queue and delivery behavior during the outage, regions or client populations affected, the status-page root cause, attack classes at a safe level of detail, mitigation activation times, and validation results after upstream filtering. Customers do not need the botnet's full playbook. They need enough evidence to update risk models, tune alerts, and decide whether their communication-continuity design matches the service they actually received.