Starlight and air gap

Modern defense infrastructure has an uncomfortable dependency hiding in plain sight: many products that claim to operate at the edge still need to phone home to establish identity, validate a license, refresh authorization, or determine which capabilities a user is allowed to access.

That model works until the network disappears.

For the Department of War, disconnected operation is not an exception. Systems may operate aboard ships, at forward locations, inside classified enclaves, across disrupted networks, or in environments intentionally isolated from the Internet. In those environments, connectivity to a vendor should never determine whether mission infrastructure remains usable.

That is why we created the Starlight Offline Authorization Bundle, or OAB.

Authorization that lives inside the enclave

An OAB allows a Starlight environment to establish authorization and authenticate approved users entirely within the disconnected environment. Before deployment, an organization creates an Offline Authorization Bundle containing the information required for that specific environment, including its authorization, licensed capabilities, approved credential set, expiration, and offline policy. The bundle is cryptographically signed and validated against the Starlight trust anchor already installed on the platform.

Once the OAB is installed and validated, Starlight switches from portal-based authentication to offline authentication. From that point forward, authentication happens locally. The Starlight system does not need to reach Mainsail, a cloud identity service, or an external licensing server for normal authorized operation.

This is particularly important in DoW environments because disconnected operation is treated as a normal operating state rather than a degraded mode.

Bounded by design

The bundle itself is bounded. It identifies the environment for which it was issued, carries an expiration, defines the capabilities available to that environment, and establishes the credential set permitted to authenticate locally. Local sessions are also time-boxed according to the bundle's offline policy. A session can expire without requiring connectivity to renew it. The authorized user simply authenticates again against the locally installed OAB.

That gives operators an important combination: independence from connectivity without removing authorization controls.

Part of a full air-gapped deployment

OAB also fits into Starlight's larger air-gapped deployment model. A system can be installed from offline media, configured with its OAB, provisioned with operating-system images and other required assets from local media, and brought into service without Internet access. Starlight's offline setup explicitly prevents Internet downloads and preflights required assets before changing the system, reducing the risk of discovering halfway through an installation that some external dependency was overlooked.

For mission owners, the benefits are straightforward. Starlight can be deployed into an air gap without creating a permanent connection back to Mainsail. Authorization remains local to the environment. Users can authenticate while disconnected. Licensed platform capabilities remain available according to the bundle. Sessions remain bounded by policy. The authorization package itself can be controlled and transported as a sensitive credential rather than turning the entire enclave into an extension of a vendor control plane.

And when an environment no longer needs offline authorization, the OAB can be ejected and Starlight can return to portal-based authentication.

A disconnected system should be able to remain disconnected

This is a relatively small feature with a much larger architectural implication.

A disconnected system should be able to remain disconnected.

For Starlight, air-gapped operation is not a special version of the product with half of the platform disabled. The authorization model, installation process, local infrastructure, workloads, and management experience are designed so the system can continue operating where external connectivity is unavailable, unreliable, denied, or intentionally prohibited.

For DoW infrastructure, that distinction matters. The network should extend what the mission can do. It should not be the thing that grants the mission permission to keep operating.

Planning an air-gapped deployment? Talk with Mainsail about Starlight's offline installation and authorization model, or read more about Starlight at the edge.