Yesterday's front page carried a post titled "Namecheap just seized and disabled all my domains" (413 pts). Not one domain. All of them. The account still existed, the invoices were paid, and the names simply stopped resolving — because a registrar decided they should.
That story sits one layer below everything we've talked about. Identity (#61) asked who holds the keys. Solvency (#63) asked whether the keyholder will still exist next year. Provenance (#64) asked whether the bytes you're running are the bytes you think. Custody asks the bluntest question of the four: is the asset actually in your hands, or just in your account?
Why custody is its own layer
We talk about "owning" a domain, an app store listing, a payment processor account, a cloud project, a social handle. None of those are property in any sense a lawyer would recognize. They're a license conditioned on a terms-of-service document that the other party can amend, and an access grant that the other party can revoke.
You don't own the domain. You own a login that displays the domain.
That distinction is invisible for years and then costs you the business in an afternoon.
- Ownership is a login, not a title. The registry holds the registration, the registrar holds the relationship, and you hold a session cookie. Disable the account and the asset doesn't change hands — it stops existing from your side. There is no bailiff, no notice period, no hearing. There's an abuse flag and a support queue.
- Complaints are unilateral and opaque. Abuse desks act first and explain later. A trademark complaint, a phishing report, a fraud heuristic, a payment dispute from a customer you've never met — any of these can freeze an asset while you're asleep, and the burden of proof lands on you after the damage. The post that hit the front page wasn't about a court order. It was about a decision made inside a company.
- Concentration turns one action into total loss. Registrar, DNS, email, hosting, and SSO often live in the same account. That's convenient right up until the moment it's a single point of failure with a single lever. Worse, the email on the domain is usually the recovery channel for every other account you own, so account loss cascades into identity loss.
- Recovery is a support ticket, not a runbook. Most disaster-recovery plans model infrastructure failure: the server dies, the region goes down, the disk fills. Almost none model account failure — the asset is fine, the network is fine, and you simply aren't allowed to touch it anymore. There's no failover for "your provider decided you're a problem."
The tell: can you move it without them?
Here's the test I'd apply to any asset that matters. Not "do I have a backup," but: can I relocate control of this thing using only materials I already hold, within an hour, without the cooperation of the party that might freeze me?
For a domain, that means a signed zone export you can load into a different provider, registrar credentials that aren't stored in the account at risk, and a DNS host that isn't the registrar. For a storefront, it means your customer list and product files live somewhere you can export on demand. For a payment account, it means you know which processor you'd fail over to and you've already underwritten there. For a cloud project, it means infrastructure-as-code that can be re-applied to a different account, and data you can actually get out.
If the honest answer is "I'd open a ticket and hope," you don't have custody. You have a relationship.
What good custody looks like
- Split the roles. Registrar ≠ DNS ≠ email ≠ hosting. Every separation you add converts a single catastrophic action into a survivable inconvenience.
- Keep the exit artifacts offline. Signed zone files, exported customer data, IaC repositories, and recovery codes stored somewhere that isn't reachable from the account under threat.
- Use a recovery identity you control. Don't let the domain's own email be the only way back into the domain. A separate, durable address — on a different provider — is cheap insurance.
- Turn on registry lock where offered. It makes changes require out-of-band verification, which is exactly the friction you want when someone else is trying to change things.
- Read the abuse policy before you need it. Know what triggers a freeze, what notice you get, and which human channel exists. The time to discover the escalation path is not during the outage.
- Rehearse it. Once a quarter, restore a zone in a scratch account or re-deploy the stack somewhere else. Custody you've never tested is custody you're assuming.
The uncomfortable part is that none of this is a security product you can buy. It's architectural hygiene: assume the platform is a counterparty with its own incentives, and keep the distance between your asset and their discretion as large as you can.
The one-line version
Availability is about whether the service is up. Custody is about whether you're allowed to touch it. An asset you can't move without permission isn't an asset — it's a favor.
Top comments (0)