Grids that many owners can trust

01A grid that nobody owns alone

An observing grid is more than a set of stations. It is the devices, software, models, data feeds and links that many providers supply, run by operators who may never meet each other.

That mix is its strength and its risk. Each owner brings coverage that no one else has, and each one brings equipment and code that the others did not choose and cannot inspect directly.

Operational technology now covers systems that monitor and measure the physical environment, alongside industrial control and building automation, and it carries its own performance, reliability and safety needs².

The old answer was a perimeter: trust whatever is inside the fence. In a grid of many owners there is no single fence to draw, and the inside of one owner's network is the outside of another's.

Zero trust replaces the perimeter with a simple rule. No implicit trust is granted to an asset or account based solely on its network location or its ownership¹.

Authentication and authorisation of both the subject and the device are discrete functions, performed before a session with a resource is established¹.

Trust then becomes something each part earns and keeps earning. It is checked at admission, renewed while the part is in service, and withdrawn as soon as the evidence stops holding.

02Admission: entering for a stated scope

Admission is the front door of a shared grid. A provider presents a manifest of what it supplies, and the grid reviews its rights, its security and its technical fitness before anything is connected.

Admission should be scoped, not general. A provider is admitted for a named product and version, a stated purpose and a place, so that a new release or a new use returns to review.

Device buyers can state what they expect in advance. NIST guidance helps organisations identify the cybersecurity capabilities they need from a connected device and from its maker before they acquire it³.

Software needs the same scrutiny. SLSA offers levels for supply-chain security, so that producers can protect against tampering and consumers can verify the software they rely on⁴.

Transparency services add a public memory. An IETF working group is defining interoperable building blocks for publishing supply-chain information so that its integrity and date of publication can be checked⁵.

Presence on the network is never admission. A device that is plugged in but not admitted stays outside every trusted path, however close it sits to the rest.

Admission is also reversible. A provider can be suspended for a single product or place while its other admissions stand, and the grid keeps running on the parts that remain trusted.

03Identity and attestation for every device

Once a provider is admitted, each of its devices must still prove what it is. A serial number on a label is a claim; attestation turns it into evidence.

In the IETF remote attestation architecture, an attester produces believable information about itself so that a relying party can decide whether to treat it as trustworthy⁶.

A verifier sits between them. It appraises the evidence using reference values and endorsements under an appraisal policy, then issues attestation results for relying parties to use⁶.

Network equipment that admits a device into a network is one of the relying parties the architecture describes, using reports of the device's hardware and software identity and versions⁶.

Where a device has a hardware root of trust, the evidence can be anchored in it, so that it reports what actually started on the device rather than what its label says.

Identity should be short-lived and renewable, so that a stolen credential soon expires. Sessions between devices and their controllers can then be protected with mutual authentication over TLS 1.3⁷.

Evidence must expire too. A result bound to a fresh challenge and a short lifetime cannot be replayed later to admit a device whose firmware has since changed.

04Segmentation and zero trust

Admission and attestation decide who may enter. Segmentation decides how far anything can reach once it is in, so that a single compromised part cannot touch the whole grid.

Industrial security standards describe systems as zones joined by conduits. IEC 62443-3-3 sets system security requirements and security levels, used with the defined zones and conduits of the system under consideration⁸.

Those requirements are tied to seven foundational requirements described elsewhere in the IEC 62443 series⁸.

Zero trust adds a finer grain. It focuses on protecting resources such as assets, services and workflows rather than network segments, because network location is no longer the main part of a security posture¹.

In a field site this means separate paths for instruments, management and public data, each passing through a controlled conduit. Management traffic never rides on the path that publishes data to the outside.

Segmentation also helps operators of different grids work together. Each keeps its own zones and exchanges only through agreed conduits, so a fault in one grid does not become a fault in its neighbour.

Zones belong on the site plan as well as in the configuration, so that installers, operators and auditors can all see which conduit each cable and radio link belongs to.

05Qualification by evidence

A grid of many owners runs on claims: this sensor is calibrated, this release was tested, this site meets its design. Each claim is only as good as the evidence that stands behind it.

A sound approach treats every step as its own evidence. Installation is not qualification, qualification is not observation, and a passing test in a laboratory says nothing about a site it never saw.

Evidence can rise in steps. A provider first declares what it supports, then runs an open test suite itself, then has a laboratory repeat the tests, and finally shows field observations for the declared scope.

Each step is recorded with what it covered and when it expires. A claim can be suspended or withdrawn, and the record says why, so nobody relies on a statement that is no longer true.

Guidance for operational technology follows the same order: understand the system and its typical topology, identify common threats and vulnerabilities, then apply recommended security countermeasures².

This is also the honest way to talk about a grid in public. Every statement about a site or a provider names its scope and its evidence, and leaves out what has not been shown.

06Records that every owner can check

Trust between owners grows when the records are open to inspection. If admissions, revocations and releases are written to logs that anyone can audit, no party has to take another's word for them.

Certificate Transparency shows the pattern. It publicly logs certificates as they are issued or observed, so that anyone can audit the issuers and the logs themselves⁹.

The same idea can carry admission decisions, software releases and attestation results across a federation. Each owner keeps its own records and shares proofs, not control.

Nexus Observatory Inc. designs grid services around this model, with admission, attestation and evidence records that each operator holds and can export.

The building blocks are public and stable. They describe how to deny trust by default, how to segment systems, how to attest devices and how to make records auditable.

A grid built this way can grow by adding owners rather than by adding exceptions. Every new provider walks the same path, and every claim carries its evidence.