What Happens If a Messaging Server Is Seized?

If a messaging server is seized, what anyone actually recovers depends almost entirely on what that server was designed to store. A server that keeps plaintext, account records, and message history hands over a treasure trove. A well-built no-logs relay that only holds sealed ciphertext with a short time-to-live hands over very little — and often nothing tied to a named person.

That gap is the whole story. "The server was seized" is not a single outcome; it is a question about architecture. Let's walk through what a seizure really exposes, why the account model matters as much as the encryption, and how a privacy-first messenger is designed so that a seized server is close to a dead end.

What "seizure" actually means

Seizure is a broad word. In practice it can mean any of the following:

• A court order or subpoena compelling the operator to hand over stored data.
• Law enforcement physically imaging the disks of a hosting provider.
• A hostile actor who breaches the server or the data centre.
• The operator themselves being coerced or compromised.

In every one of these cases, the attacker ends up with whatever the server had on disk (and possibly in memory) at that moment. Nothing more, nothing less. So the meaningful question is never "can a server be seized?" — assume it can. The question is: what was on it to take?

What a seized server can reveal — it depends on the design

Different messaging architectures store radically different things. Here is a rough map of what a seizure could expose, from most to least revealing:

Server design	What a seizure can expose
Plaintext on the server (unencrypted, or "encrypted" but operator holds the keys)	Full message content, contacts, timestamps, account identity
Content E2E-encrypted, but rich account + metadata retained	Who talked to whom, when, how often, phone numbers, IP logs — not message text
Cloud backups not end-to-end encrypted	Message history for anyone who enabled that backup
No-logs relay: sealed ciphertext only, short TTL, no account	Undelivered ciphertext blobs with a short lifespan, and little or nothing that names a user

The pattern is clear. End-to-end encryption protects the content of messages, so a seizure of a properly E2E system does not hand over what you said. But E2E alone says nothing about metadata — the record of who messaged whom, when, and from where. For a full picture of how servers hold messages at rest, see our guide on how encrypted messengers store messages.

Metadata is usually the real prize

When investigators or attackers can't read message content, they go after metadata, and metadata is often enough on its own. A social graph — the map of who is connected to whom — plus timing and location can reveal sources, relationships, and patterns without a single decrypted word.

This is why two servers can both offer "end-to-end encryption" and yet behave completely differently under seizure. One keeps years of connection records tied to phone numbers; the other keeps almost nothing. The encryption is the same. The exposure is not.

The three things that change the answer

Three design choices decide how much a seized server can give up.

1. No account

If registration requires a phone number or email, the server holds a durable identifier that maps directly back to a real person. Seize that server and you can often link activity to individuals, even if the messages themselves are unreadable.

If there is no account at all — no phone number, no email, no server-side profile — there is no identity record to hand over in the first place. You cannot subpoena a column that was never created.

2. No logs

A "no-logs" relay is one that does not retain connection logs, IP records, or delivery history. The value here is simple: you cannot seize data that was never written. If the server stores only sealed ciphertext and deletes it after delivery, a raid captures a thin, temporary slice rather than an archive. We unpack exactly what that phrase should mean in what "no-logs messenger" really means.

3. Short TTL and delete-after-delivery

Even a no-account, no-logs relay has to hold a message briefly while the recipient is offline. The mitigation is a strict time-to-live: undelivered ciphertext expires automatically, and delivered ciphertext is removed once receipt is confirmed. A seizure then finds, at most, the small set of messages still in flight — not a back catalogue.

How Graphite is built for the seizure scenario

Graphite is an end-to-end-encrypted messenger by PrivacyPortal, and its architecture is designed so that a seized relay is a near dead end. Here is what that looks like against each of the three factors above — stated only to Graphite's actual design:

• There is no account on the server. Graphite uses no phone number and no email. Your identity is a 12-word recovery phrase generated on your device. The server never holds an account, so there is no identity table to seize.
• The relay is no-logs and stores only sealed ciphertext. It never sees plaintext, your keys, or your recovery phrase. Messages are encrypted with NaCl/libsodium X25519 sealed boxes, wrapped in a hybrid post-quantum layer (ML-KEM-768), with forward secrecy from a Signal-style double ratchet.
• Ciphertext has a short life. Messages sit on the relay for a maximum of seven days and are deleted after delivery (acknowledgement-gated). A seizure finds only what is still undelivered inside that window.
• The network path is hidden by default. Graphite routes over Tor by default and fail-closed, connecting to a hidden service. That conceals your IP and network from the relay, so even the connection metadata a server might otherwise log isn't there to take. (Real-time call media runs peer-to-peer over DTLS-SRTP rather than Tor; signalling and messages go over Tor.)

Put together: seize the Graphite relay and you get, at most, a handful of sealed ciphertext blobs with a short expiry and no account behind them — no plaintext, no keys, no phone numbers, no IP logs, no social graph. If you want the deeper picture of how these pieces fit, start with our pillar guide to the encrypted messenger.

How this compares across messengers

A fair look at the landscape, because the details differ:

• Signal encrypts by default, is open-source, and minimises metadata (including sealed sender). It has adopted post-quantum key agreement (PQXDH). It does, however, require a phone number to register; usernames can hide your number from other users, but the number is still part of onboarding.
• WhatsApp encrypts message content by default using the Signal Protocol, but it is owned by Meta, ties you to a phone number, and collects metadata. Cloud backups are not end-to-end encrypted unless you turn on encrypted backups.
• Telegram is often misunderstood: its ordinary cloud chats are not end-to-end encrypted — Telegram can access them — and only opt-in one-to-one "Secret Chats" are E2EE. It also requires a phone number. So a seized Telegram server can, by design, reach cloud chat content.
• Session uses no phone number and onion-routes traffic, which similarly shrinks what a server can reveal.
• Threema is a paid, Swiss, open-source-client app that does not require a phone number.

Different projects make different trade-offs. The through-line for seizure resistance is consistent: the less identity and history a server is architected to hold, the less a seizure can produce.

The honest caveats

No design makes you invincible, and it's worth being clear about the limits:

• Endpoint compromise still matters. If your own device is seized or infected, server design is beside the point — the plaintext lives there.
• A recipient who is online receives and stores messages normally; server minimalism protects the relay, not your correspondent's phone.
• Metadata resistance depends on the whole path, which is why network-layer protection (like routing over Tor) matters alongside no-account, no-logs storage.

Seizure resistance is a property of the system, not a slogan. Ask any messenger the same three questions — Is there an account? Are there logs? How long is data kept? — and the honest answers tell you what a raid would actually recover.

Try Graphite

Graphite is free and in public beta (v1.13.25), running on Windows (portable .exe with bundled Tor), Android (sideloaded APK that works on GrapheneOS and de-Googled phones with no Google Play Services), and as a web app. No phone number, no email, no logs — your identity is a recovery phrase that only you hold.

See it for yourself at graphite.chat.