Nine kinds of secure¶

Against this adversary, secure means something else.

Against a watcher, secure is what cannot be read. Against a poacher, secure is what cannot be harvested. Against an adversary that ends relationships instead of reading data, secure is what keeps going when any one party it depends on decides the relationship has become too expensive to keep.

Any provider will do¶

A provider can disappear without taking the system with it.

Blue’s static stack, in Taking back the stack, tests this by making the mailbox replaceable by an MX change, and deployment replaceable without moving the source. The same question applies to hosting, DNS, certificates, payment services, identity providers and other dependencies.

The test is not whether another provider exists. It is whether the service can move to one.

Movable between countries¶

A service can move between jurisdictions without being reconstructed from scratch.

The tenant’s list tests each layer on its own contract, payment route, administration and recovery path. A move can then change the jurisdiction of one dependency without accidentally moving everything else with it.

Jurisdiction is then one more dependency that can be moved.

The graph written down¶

The actual dependency graph is known, including the dependencies underneath apparently independent services.

The test across the lists is the same: for each provider, record the contracting entity, jurisdiction, governing law, subprocessors, ownership where relevant, and payment route. On the provider’s list, record the upstream companies and services on which each layer depends.

A service that appears to have five providers may turn out to have one payment rail, one identity provider, one registry, or one parent company underneath them. Five names on a diagram do not necessarily mean five independent paths.

The door has been used¶

There is a tested path out of each important provider.

The escape route has been run at least once: files have been built, credentials transferred, DNS prepared, domains repointed, mail delivered, recovery exercised, and the result checked from outside the system being moved.

An exit plan that has never been executed is an intention, not yet an exit path.

Logins survive the move¶

Users can still log in, and still reset their passwords, while the service moves.

The static stack tests this as a recovery route that does not pass through the mailbox it is supposed to recover. The tenant tests it with a recovery mailbox at a separate provider and on a domain that is not dependent on the organisation’s main service.

Identity continuity includes more than usernames. Domains, mailboxes, credentials, recovery addresses, administrator identities and established contact routes are all things a login can depend on.

Data leaves usable¶

Data can leave in a usable form.

The test is an independent local archive of the mail kept with the backups, exports in ordinary usable formats, and an organisation-controlled copy that does not depend on the provider being available when it is needed.

The address book moves¶

The relationships around the service can be reconstructed elsewhere.

That includes contacts, subscriptions, mailing lists, DNS records, domain configuration, membership records and other information that tells the organisation not only what data it has, but how the pieces connect.

The test might be a zone that is exportable and nameservers that can be changed without a support ticket, or a volunteer roster held in the organisation’s own store rather than in somebody’s personal account.

The receipts survive¶

The organisation can retain enough evidence to understand and contest what happened, even if a provider disappears.

Invoices are kept independently. Design notes and issues remain in the repository rather than only in a platform. Contracts, relevant correspondence, configuration history, suspension notices and appeal procedures can be retrieved without access to the provider’s interface.

The test is whether the organisation can still assemble the sequence of events after the provider that recorded part of it has gone.

The people survive¶

The architecture does not assume that users can recreate their identities elsewhere.

The observed case shows this most plainly. The provider’s disappearance was much larger than the provider itself. The collective counted roughly twelve thousand mailboxes, sixteen thousand by other counts, including addresses that some users relied on for recovery of bank accounts or government logins. Once the provider disappeared, those identities could not be recreated by moving the service to another host.

User survivability includes the things users have built around a service: addresses, subscriptions, correspondence, recovery routes, memberships, established contacts and historical records.

A service can be technically replaceable while the people attached to it are not.

The limit of a list¶

A checklist tests properties one provider at a time.

The dependency test asks the question that a list cannot: what happens when the replacement makes the same calculation?

There the model stops being a collection of backup plans and becomes a graph. One provider can be replaceable. Two providers can be replaceable. The harder case is when the supposedly independent replacement depends on the same registry, payment system, identity provider or jurisdiction.

The property is that another path through the graph remains. A second provider is not by itself another path.

Last reviewed: 2026-09-25.