When a server is seized
Answer
A server seizure begins with a court order served on the provider, followed by imaging or physical removal of the hardware. Encrypted volumes yield nothing without the passphrase. The practical defence is architectural: encrypt at rest, keep backups in another jurisdiction, and hold no data you do not need.
The realistic sequence
It starts with a valid order from a court in the jurisdiction where the hardware sits. Our legal team reviews it for validity, scope and jurisdiction; overbroad or improperly served orders are challenged, which sometimes works and sometimes only buys time.
If the order stands, what happens next depends on its scope. Most orders seek a copy of specific data. Physical removal of hardware is less common and usually accompanies a criminal investigation into the operator of a specific service. Notification to you depends entirely on whether the order includes a gag — if it does not, you hear from us the same day.
What survives it
An encrypted volume yields ciphertext. LUKS2 with Argon2id and a strong passphrase is not brute-forceable with any technology that exists, so a powered-off encrypted disk is, in practical terms, a very expensive brick.
The critical qualifier is powered off. A running machine has the key in RAM. Cold-boot attacks against a running server are real, if fiddly, and a machine seized while running is a much worse outcome than one seized while off.
Build so that it does not matter
The goal is not preventing a seizure, which you cannot. It is making one survivable and uninformative.
Encrypt at rest with a key we never hold. Keep backups in a jurisdiction that would not be reached by the same order. Hold the minimum data your service actually needs — data that does not exist cannot be seized. Distribute across jurisdictions so no single order takes everything. And know in advance how you would rebuild, because a seizure with a tested recovery plan is an outage and a seizure without one is the end of the project.
- LUKS2 at rest, passphrase entered over console at boot
- Backups in a jurisdiction not reachable by the same order
- Minimum viable data retention in the application itself
- Distributed architecture, no single-country dependency
- A rebuild plan you have actually rehearsed
What we do
Review every order for validity and scope, and challenge what is challengeable. Provide only what the order compels, and nothing beyond it. Notify you unless legally prohibited. Publish counts in the quarterly transparency report.
What we cannot do is refuse a valid order from a jurisdiction we operate in. Any provider claiming otherwise either has never received one or is not being straight with you.
Frequently asked questions
01 Would you tell me if my server were seized?
Yes, unless the order carries a gag provision. Where we are permitted to notify, we do so the same day, with the order text where that is allowed.
02 Can encrypted data be recovered by force?
Not from a powered-off LUKS2 volume with a strong passphrase — no technology that exists brute-forces Argon2id at that strength. A machine seized while running is a different matter, because the key is in RAM.
03 Do you challenge legal orders?
Where there are grounds — improper service, wrong jurisdiction, overbroad scope. That sometimes succeeds and sometimes only buys time. We cannot refuse a valid order from a jurisdiction we operate in, and neither can anyone else.
Related