The team’s articlesPower and governance

Network Identity Is a Board Question Because Dependence Outlives the Contract

Network identity can bind customers, routing, security and revenue to records controlled outside the company. Boards should ask who can change that identity, who bears the risk and whether the administrator can be replaced.

Contents

Three people examine a tabletop network model and trace its connection to an external records cabinet.
A business decision becomes clearer when the dependency is visible: who can change the record, and what happens to customers when it changes?

Why this belongs in a business-risk conversation

Network identity is often treated as an engineering detail because engineers maintain the routes and records. The business experiences the identity through customer access, reputation, security controls, contracts and the cost of changing every external reference.

That makes the governance of the identity a board-level question. The board does not need to operate BGP. It does need to know whether the company’s ability to keep serving customers depends on an administrator it cannot replace and a record it cannot independently verify.

Separate the asset from the authority around it

An address resource, a registration record, a route announcement and a political mandate are different things. A company may have a commercial right to use a resource while depending on an external registry to keep the public record current. A registry may have a technical duty to maintain uniqueness without having authority to decide the company’s wider commercial future.

When these layers are described as one kind of ownership, the risk disappears from the contract review. The board sees a supplier relationship; the network has acquired a dependency on the supplier’s institutional position.

The hidden cost is the difficulty of changing

A dependency becomes strategic when changing it requires renumbering customers, reworking allow-lists, repairing reputation, coordinating route filters or obtaining permission from the same administrator. The question is not only whether the administrator is competent today. It is whether the company has a credible alternative if circumstances change.

Note 42 describes how a record keeper can acquire practical power without operating the networks that bear the cost. Note 52 names the liability gap: the institution may influence valuable infrastructure while the consequences of its decision fall elsewhere.

Stability is evidence, not a substitute for a contingency

A system that has worked for years deserves evidence that it works. It does not follow that it can absorb a new dispute, financial shock, leadership change or change in the meaning of its mandate. Note 69 challenges the stability argument because continuity in calm conditions can hide the absence of an exit.

A board should therefore ask for a failure scenario: what happens if the record is wrong, the administrator is unavailable, or the company no longer accepts the conditions attached to recognition? The answer should include time, evidence, alternate coordination and customer communication.

The governance design that reduces the risk

The practical direction is limited coordination with stronger obligations. Keep a common, verifiable account of unique resources. Require evidence for changes. Preserve a history that other networks can inspect. Make the administrator replaceable so that changing the coordinator does not destroy the network identity.

Note 72 treats replaceability as a right that protects both continuity and accountability. It does not remove the need for common records. It prevents common records from becoming a permanent claim over everyone who uses them.

Five questions for the next risk review

Which customer and revenue commitments depend on our network identity? Who can alter the record that others rely on? What evidence would prove control during a dispute? Which routing and security systems must change together? Can another qualified coordinator take over without forcing a complete renumbering?

If the last answer is unclear, the issue belongs in the business-continuity register alongside provider concentration, identity systems and other dependencies that are easy to ignore until they fail.