prove to a vendor that you are the company

The hostile departure guide gives you an order of operations for a difficult exit. The notice window guide covers the weeks before anybody knows. Both quietly assume two things: that somebody more senior authorises the work, and that the person leaving is not the one holding the keys.

This guide removes that assumption.

Your founder leaves. Or your chief technology officer, or the first engineer, or whoever typed a card into the domain registrar in 2019 and has been the only super admin since.

That day you have to prove to a series of vendors that you are the company. Revoking the person’s access is the easy half.

two cases from 2026

In January 2026, the founders of the games studio That’s No Moon sued its former chief executive in US federal court. According to the complaint, as reported by Aftermath, he had kept control of the registrar account after being removed in 2022, and in January used it to take over the website, cut the studio’s access and stop employees emailing outside the company. The domain was sent to an auction listing asking $6,666,666. These are allegations in a lawsuit, and no court has ruled on them.

In June 2026, a security company told Domain Name Wire that a former employee was holding its domain. According to the company, the domain had been registered to a limited company with him as the contact, he declined to transfer it, offered to sell at escalating prices, and emailed investors and prospects announcing the end of the product. The dispute went to a standstill agreement and arbitration.

Two companies, six months apart, both in software, both with the same underlying fact: the registrar account was in a person’s name, and nobody had checked.

Notice what neither company could do. There is no vendor process for “this person no longer represents us”. A registrar will not transfer a domain because you say you are the employer, and it should not, because the next caller saying that will be somebody else. So both disputes went to lawyers, which is slow, expensive and avoidable by an administrative change nobody made in year one.

Neither was a security incident in any sense your tooling would recognise. There was no compromise. Every login was legitimate. The company discovered that a thing it believed it owned was registered to somebody who no longer worked there.

the list, and the test that applies to all of it

Here is what a founder or first engineer tends to hold personally. For each one the question is whose name is on the account? Who has the password matters less.

The domain registrar. Login identity and billing card. The registrant and administrative contact in the public record.

DNS hosting, which is often a different vendor from the registrar, and which matters most, for reasons that come up below.

Your Workspace super admins. Count them. If the answer is one, that is the whole problem.

The cloud root account. Specifically, the email address it was created with. If that is somebody’s personal Gmail, note it now.

Payment methods, because a personal card on your cloud or SaaS billing turns a departure into a failed payment three weeks later.

The Apple or Google developer account, which comes in an individual and an organisation form, with an account holder who is a named human either way.

The code-signing certificate: whose name is on it, and where the hardware token physically is.

And the ordinary ones people forget: your content delivery provider, your status page, your social accounts, your certificate issuer.

what each recovery path actually asks you to prove

• Workspace admincontrol of DNS: add a record, wait up to 48 hours
• domain registrarnothing you can prove if it is in their name
• cloud root accountaccess to the inbox it was created with
• developer accounta named account holder and company documents

no path that works without the departed person

why DNS is the only lever

Now the mechanism, and it is worth understanding before you need it.

If your only super admin is gone and the recovery details on the account are theirs, Google’s documented recovery process asks you to add a CNAME or TXT record to your domain’s DNS. Google says propagation can take up to twenty-four hours, and if the record has not been found within forty-eight you get an email saying recovery failed. If you bought Workspace through a reseller you cannot do this yourself at all; the documentation tells you to contact them.

So the proof Google accepts is control of DNS. A company registration document, a board resolution or an employment contract does not enter into it.

If you control DNS, a founder departure is a twenty-four to forty-eight hour clock. If the departed person controls the registrar, you have no lever at all, and both disputes above went where that goes, which is to lawyers.

The cloud side is worse. Amazon’s documentation for root account recovery says you must know the email address the account was created with and have access to that email account. There is no documented path for when that inbox belongs to somebody who has stopped answering.

And the developer accounts and the code-signing certificate have no ownership-proof path at all. They have support tickets and identity documents naming a human being. Apple’s route from an individual membership to an organisation asks for founder or co-founder status, a business identifier and company documents, with a named account holder at the end. That process is built for a company reorganising itself. It does not help one whose account holder has stopped replying.

the ten minutes that prevent all of this

The fix is neither a product nor a project.

Add a second super admin, on an account that is not a person. Google’s own guidance for super admins says to use an address not tied to one individual, not to use the super admin for everyday work, and to keep its security key somewhere safe, preferably physical.

The small-company version is unglamorous and nearly free. A break-glass account belonging to no individual, a hardware key for it in a safe or a drawer that two people know about, and a note of the date somebody last confirmed it works.

On cost: a second super admin on a paid Workspace edition usually takes a licence, and a hardware security key costs tens of euros. That is the whole budget. It does not require buying a privileged access product, whatever anybody tells you.

Move the registrar and DNS to accounts owned by the company, with billing on a company card and the administrative contact a role address. Both disputes above would then have been ordinary employment disagreements.

Change the root email on your cloud account to an address the company controls, and add the alternate contacts.

And write the list down. One page: a column for the artifact, one for whose name is on it, one for the recovery path. That page is the deliverable.

Then check the break-glass account works, once, on a date you write down. An emergency account nobody has ever signed into is a theory. The failure is mundane and total: the key was reset, the recovery phone was somebody’s old number, the account was suspended for inactivity. Ten minutes a year, and the year you need it is the year you find out.

the diligence question to add

Investors will spend a week on your cap table. They check who owns your intellectual property, whether your founders assigned it properly, and whether your contractors signed the right agreements. Who is named on the domain registrar account is easy to leave off that list.

If you are on the receiving end of diligence, answer it for yourself anyway. If you ever do diligence on somebody else, ask it: it takes one line, and the answer is occasionally alarming.

what to take away

Most of these guides are about somebody having more access than they should. This one is about your company having less claim to its own accounts than it assumes, which is the same problem seen from underneath.

The test is one question applied to about ten things: whose name is on it? Not who knows the password, and not who logs in today.

Half an hour, and you will probably find at least one answer you do not like.