---
title: "Whoever holds the root credentials owns the system"
url: "https://xubris.com/blog/whoever-holds-the-root-credentials-owns-the-system"
description: "Owning your data means little if someone else registered the domain, owns the cloud account and holds the encryption keys. How to find out who actually does."
---

# Whoever holds the root credentials owns the system

October 8, 2026·3 min read·Editorial team

A black hardware security key plugged into a graphite cube computer, a second key and a key ring beside it, one orange-red light

A small company decides to move its website and email to a new provider. The work looks simple until someone asks who can change the DNS records. The domain was registered years ago by the agency that built the first site, on the agency’s account, with a contact address belonging to a designer who has since left. The cloud account behind the customer portal was opened by an integrator and is billed through them. The keys that encrypt the backups are managed by the backup vendor, and nobody inside the company has ever seen them.

The company owns its data in every legal sense. In practice, three outside parties can stop it doing anything with that data, and none of them is the software vendor it was worried about.

## The real cause

Conversations about sovereignty focus on data and code, because those are what contracts mention. Control sits a layer below, in a handful of credentials that decide who can change everything else: the domain registrar account, the root account of each cloud subscription, the identity provider’s global administrator, the encryption keys and the billing relationship. Whoever holds those can lock, move or delete the rest.

They are usually set up once, early, by whoever happened to be doing the work — an agency, a contractor, a founder’s personal mailbox — and then forgotten, because they do not need touching again until the day they do.

## How control leaks without anyone deciding it should

**The domain is registered to someone else.** The registrant record names the agency or an employee rather than the organisation. Moving it requires their cooperation, and cooperation is not guaranteed after a dispute.

**The cloud account belongs to the partner.** Resellers and integrators often open accounts under their own organisation and bill onwards. The workloads are yours; the account, legally and technically, is not.

**The identity provider has one global administrator.** It is a person who has left, a shared mailbox nobody reads, or the vendor’s support login. Recovering it means days of proving who you are to a helpdesk.

**Keys are held by the service they protect.** Encryption managed by the vendor protects you from outsiders, not from the vendor or from losing the vendor. If you cannot hold or export the key, what you hold is ciphertext.

**Billing is the off switch.** An account billed through a third party can be suspended over an invoice dispute between two companies, neither of which is you.

## What to do instead

**Register every root in the organisation’s name.** Domain registrant, cloud account owner, identity tenant, code repository organisation. Contractors get delegated access, which can be revoked; they do not get ownership, which has to be transferred.

**Keep emergency access that you have tested.** At least two named people, hardware security keys rather than codes sent by text message, sealed credentials whose use is logged. Test the recovery once a year, because untested emergency access fails the same way untested exports do.

**Hold the keys to your encrypted data.** Where a service offers customer-managed keys, use them for what matters. Where it does not, record that as a dependency rather than assuming encryption means control.

**Pay your own bills.** Direct billing for anything that runs production, even when a partner operates it for you.

**Write the list down.** One page: each root credential, who holds it, where its recovery goes, when it was last tested. Review it whenever a person or a supplier leaves.

None of this is exotic. It is the unglamorous half of [being able to leave](https://xubris.com/blog/we-only-back-companies-you-could-leave): a perfect export is worthless if someone else decides whether you may log in to take it. In the companies we build the same rule applies to the product itself — customers create and hold their own administrative roots, and the vendor’s access is something they grant and can revoke. That is what owning “their systems” means on [the homepage](https://xubris.com/).

## A test you can run today

Open five things and look for the owner, not the user:

1.  The registrant record of your main domain.
2.  The account owner of each cloud subscription that runs production.
3.  The list of global administrators in your identity provider.
4.  The key-management settings of your backups.
5.  The name on the invoice for each of the above.

For every entry that is not the organisation itself, or a named person inside it with a tested way back in, ask what would happen if that party stopped answering tomorrow. The ones that make you uncomfortable are your real [supply chain](https://xubris.com/blog/sovereignty-is-a-supply-chain-question), whatever the architecture diagram says.

-   access control
-   encryption keys
-   cloud accounts
-   digital sovereignty

## Keep reading

-   [An export you have never restored is not an exit](https://xubris.com/blog/an-export-you-have-never-restored-is-not-an-exit)
-   [Build the exit before your first customer asks for it](https://xubris.com/blog/build-the-exit-before-your-first-customer-asks)