Seven ways to end

Seven threat events, each concrete enough to become a scenario against which an architecture can be tested. They are numbered so that a case or checklist elsewhere can name the one it exercises.

Six of the seven were observed between 26 August and 18 September 2026. The seventh is the one the observed case did not get far enough to show.

T1. The provider leaves

A provider terminates the relationship after asking what keeping the customer could cost it.

Examples include:

  • a registrar or registry suspends the domain or refuses renewal

  • a bank freezes or closes the account

  • a hosting provider terminates service

  • a mail provider suspends accounts

  • a certificate provider refuses issuance or renewal

  • a payment processor terminates service

  • an identity provider suspends an administrative account

  • a DNS provider stops providing authoritative service

  • a transit provider withdraws connectivity

No direct attack on the infrastructure is required.

The provider does not need an order to withdraw. It can make the decision itself. In the observed case, Banca Etica condemned the listing and announced the suspension of the account in the same statement.

The test is simple: if one important provider leaves, what can the system still do?

T2. The next desk reconsiders

One provider’s withdrawal raises the number the next provider puts on keeping the customer.

    pressure
       │
       ▼
    provider A withdraws
       │
       ▼
    provider B reassesses
       │
       ▼
    provider C reassesses
       │
       ▼
    more dependencies fail

Each decision can be locally rational without central coordination. One provider does not need to wait for another to withdraw. It only needs to think the customer might cost it a fine.

This is how the pressure spreads. It can appear inside T1, T3, T4 or T5 rather than being a separate kind of legal action.

The test is whether the loss of one provider causes other providers to reconsider relationships that were previously unaffected.

T3. Under another state’s warrants

A service moves into another jurisdiction because the available providers elsewhere have disappeared, withdrawn, or become inaccessible.

The move can be voluntary. The service may continue to function technically while becoming subject to a different set of legal powers.

These can include:

  • compulsory disclosure

  • warrants

  • gag orders

  • local material-support rules

  • different retention requirements

  • different legal remedies

  • different obligations imposed on providers

No jurisdiction is safer in itself. Moving between them changes which state can serve the provider with which of those instruments.

A service can therefore move from a state whose warrants cannot be served on its provider to one whose warrants can.

Out of reach, then into reach, is a threat of its own.

The test is whether a forced migration changes who can legally compel the replacement provider to disclose, suspend or alter the service.

T4. The users scatter

Users leave because the provider has become risky, has shut down, or no longer resolves.

The secondary effects can include:

  • user fragmentation

  • loss of contact

  • abandoned accounts

  • loss of archives

  • recovery failures

  • concentration in a small number of replacement providers

The user population itself becomes part of the dependency graph.

Migration can also put users under a second state’s jurisdiction. A replacement provider may be technically suitable but have a different jurisdiction, different policies, or different dependencies of its own.

The migration threads after the designation show displaced users looking for alternative providers. The destination most often named, Riseup, requires an invitation, a restriction that predates the designation. The nearest alternative offered is another small provider.

The test is whether users can move without losing identity, relationships, archives or recovery routes, and whether the available destinations introduce a new concentration or jurisdictional dependency.

A dependency that looked peripheral becomes the thing that prevents recovery.

Examples include:

  • domain lost, therefore email recovery fails

  • email lost, therefore account recovery fails

  • payment account lost, therefore renewal fails

  • identity provider lost, therefore administrative access fails

  • DNS lost, therefore services using the domain become unreachable

  • certificate renewal lost, therefore clients can no longer establish trusted connections

A mailbox that is the recovery address for a bank login is not only correspondence. It is part of the identity infrastructure of every system that points at it.

The test is whether the loss of one dependency can prevent recovery of another dependency, and whether recovery still works when some fail together.

T6. Nobody left to sue

The target dissolves before a legal challenge can establish the facts.

The disappearance of the target can mean:

  • no plaintiff

  • no test case

  • no discovery

  • no authoritative interpretation

  • no ruling defining the boundary

This is a threat to the evidentiary layer.

A test case might have required a US court to decide whether hosting, political affinity and refusal to log could together constitute material support. It might also have failed. With no test case, the question stays open, and the next intermediary still cannot say what keeping the customer would cost it.

The application filed at Pisa on 8 September tests whether an Italian bank may freeze funds on a foreign listing. It does not test the designation itself.

Dissolution can therefore remove the organisation that could have challenged the first decision while leaving the underlying question unresolved.

The test is whether the organisation can preserve evidence, legal standing and a route to challenge a decision without requiring the organisation itself to remain operational indefinitely.

T7. Independent on paper

A system appears decentralised because its visible components are distributed, while the dependency graph underneath remains concentrated.

For example:

five hosting providers
        │
        ├── one domain registry
        ├── one payment rail
        ├── one certificate ecosystem
        └── one identity provider

The system has distributed nodes and a centralised failure graph.

This is not an attack event in the same sense as provider withdrawal. It is a condition that lets any one of the other events stop everything at once. An architecture can appear resilient while resting on a single dependency.

It is also the one most likely to survive an architecture designed to withstand the other six. The concentration sits below the layer where the drawing was made.

The test is to collapse the graph from the bottom up rather than from the visible services down. For every provider, ask which deeper providers, registries, payment systems, identity systems, legal jurisdictions or other dependencies it shares with the others.

Count the independent paths that remain when the shared dependency fails, not the nodes that can fail.

Last reviewed: 2026-09-25.