Signed updates that arrive by media

An air-gapped node still needs new software from time to time. The question is how new software reaches a machine that, by design, has no path to anything outside the building. The answer on a Czar is old and plain: someone carries it in. What makes the answer safe is that the bundle is signed and the node checks the signature before it changes.

This article walks the update path from the customer portal to the rack, explains what the signature does, and shows that the connected posture does not take the step away from the customer.

The update path on an air-gapped site

A signed update bundle begins on the Element 31 customer portal, where signed update downloads are available to the customer. The customer downloads the bundle on a machine outside the air gap. Nothing about this step touches the node, and the node has no way to reach the portal itself.

The bundle then crosses the gap the only way anything can: on media, carried by a person the site has authorized, under a procedure the site wrote. At the node, the customer applies the bundle. Before anything changes, the node verifies the signature. If the signature holds, the update is applied and the node's sealed, signed, read-only image is replaced by the new one. If it does not, the node refuses the bundle and keeps running what it had.

Afterwards, the node attests what it is running before it rejoins the Grid or accepts a task, so the new load is confirmed against the record the same way the original one was. The update and the attestation both land in the record. The site can later see what was applied, when, and that the node matched afterwards.

What signed protects

The signature does a specific job. It lets the node establish that the bundle came from Element 31 and that it has not been changed since it was signed. Those are the two things that could go wrong between the portal and the rack: a bundle from somewhere else, or a bundle that was altered on the way.

A node that verifies signatures does not have to trust the media, the person carrying it, or the machine that downloaded it. It trusts the signature or it refuses. That is why a physical update path can be sovereign rather than merely isolated. Isolation keeps outsiders away from the node. Signing keeps the node from accepting anything that is not what it claims to be, even from an insider's hand. What a sealed enclosure means explains the image discipline the signature upholds.

The portal side

The customer portal is where support, billing, signed update downloads, and remote sessions live. It is worth being precise about its relationship to the appliance, because the usual pattern elsewhere is a device that checks in with a vendor service.

Customer appliances never connect to the portal. Not on air-gapped sites, not on connected ones. The portal is a place a person goes, and what that person brings back is a signed bundle. Remote sessions are likewise customer-initiated, and on sovereign sites they open only inside an uplink window that the customer attests to, with data disks detached, the network isolated, the console supervised, and the requester's authority confirmed, and that window has a hard expiry.

The arrangement keeps the direction of every interaction the same. The customer reaches toward Element 31 when the customer chooses. Nothing reaches toward the customer.

The connected posture keeps the step

A connected Czar has declared routes to the systems the site already secures: fleet software, the warehouse system, the PLCs. It does not have a route to the portal, because customer appliances never connect to it. Updates on a connected site are still customer-initiated. The customer downloads the bundle, moves it to the node by whatever means the site's own network allows, applies it, and the node verifies the signature.

The difference between the postures is in the carrying, not in the deciding. An air-gapped site moves the bundle on media. A connected site may move it over its own wires. In both, a person at the site chooses to update, chooses when, and the node checks what it is given. Air-gapped, or connected only to what the site secures covers the postures more broadly.

The operational rhythm

Because the update is a procedure, it becomes part of how the site runs the floor rather than something that happens to the floor. The automation team schedules it around the work. The person who carries the media is named. The node that receives it is recorded. The attestation that follows confirms the result.

Operators sometimes expect this to be a burden compared with automatic updates. In practice it replaces an unplanned event with a planned one. A pool that changed itself on a vendor's schedule would be a pool whose behavior on a given night the site could not fully account for. A pool updated by hand, from a signed bundle, with the record to show it, is a pool the site can describe exactly. Who holds the keys on a facility pool places the update decision among the others the site holds. For the serving system the update maintains, see Substrate.