📋 Table of Contents
An air-gapped environment is deliberately isolated from less-trusted networks under a defined security boundary; a computer that is merely offline is not necessarily air-gapped. Software deployment across that boundary needs an approved sourcing, review, transfer, installation, and maintenance process. A bootstrapper that depends on an unreachable endpoint cannot complete, so determine the exact package's network behavior and prerequisites instead of relying on an offline label. This guide outlines the evidence and tests to record for that workflow.
1 Step 1 — Identify the package and its live dependencies
A common air-gap mistake is grabbing a vendor's default download when it is a web bootstrapper that fetches its payload at install time. That package cannot complete without access to the required endpoint. Look for a publisher-documented standalone package or other deployable artifact for the target platform, and identify whether it also needs prerequisites, activation, language packs, or optional components.
File size is only a clue, not confirmation: a tiny file may be a complete utility, while a large installer can still retrieve dependencies or updates. Prefer labels, filenames, package metadata, vendor deployment documentation, and a disconnected test on representative hardware. Obtain files from a publisher-controlled domain, its documented release repository, app store, CDN, or distribution host; do not assume an unrelated mirror is authoritative.
2 Step 2 — Verify integrity and signature before it leaves the internet
Perform verification on the connected staging machine while the publisher's reference material is available. If the publisher supplies a SHA-256 value, obtain it through an authenticated publisher channel, calculate the local digest, and compare the complete values. On Windows, Microsoft's Get-FileHash reference documents one way to calculate that digest. If the package is signed, inspect the signer, certificate status, or signing-key fingerprint and compare it with the publisher's documentation. The guide to SHA-256 and signature checks covers additional commands and their limits.
Record a locally calculated file hash alongside the approved package so the offline side can detect changes during transfer. That comparison does not authenticate the original package unless its expected value came through an authenticated publisher channel. A matching hash or valid signature is useful evidence, but neither guarantees that software is safe; preserve source provenance and follow the organization's malware-scanning and approval controls too.
3 Step 3 — Transfer through an approved mechanism
Move the verified installer only through a transfer mechanism permitted by the security boundary, such as dedicated removable media, an approved transfer station, or an authorized one-way gateway. NIST's SP 1334 describes procedural, physical, and technical controls for portable media in operational-technology environments; use its relevant considerations within your own risk assessment rather than treating one control as universal. Reserve removable media for the approved workflow, protect it from unauthorized writes, and scan or inspect it at the stages required by policy—not only on the connected side. Re-compute the recorded hash on the air-gapped side to confirm that the transferred bytes match the approved staging copy. If you deploy regularly, use a documented depot structure so transfers remain predictable and auditable.
4 Step 4 — Install, ideally unattended
On the target, run the package using the publisher's documented procedure. For several machines, use unattended switches only when the package vendor or installer framework documents them and after testing the exact build. Microsoft's msiexec reference documents msiexec /i app.msi /qn as a Windows Installer pattern; EXE behavior varies by wrapper, macOS packages can use documented installer workflows, and Linux packages may require locally staged dependencies as well as the package file. Capture the exact command, context, return-code interpretation, and test result in a runbook rather than assuming one framework's defaults apply to every vendor package.
5 Step 5 — Handle dependencies and runtimes
A common failure mode is a missing dependency that was already present on a connected test machine or was retrieved silently: Visual C++ Redistributables and .NET runtimes on Windows, shared libraries on Linux, or a specific framework version. Identify prerequisites from the package and system requirements, obtain each one through its own publisher-documented source, preserve its provenance and available integrity evidence, and test the complete set on a representative disconnected target.
6 Step 6 — Plan for updates
An air-gapped machine cannot reach public update services, so its software ages unless administrators import updates through an approved path. Build a cadence: review vendor notices on the connected side, obtain current supported packages, repeat the available provenance and integrity checks, and redeploy through the controlled-media process. Keep an inventory of installed versions and test each changed package before transfer. Treat the offline package depot as a maintained system, not a one-time copy.
Frequently Asked Questions
What is an air-gapped machine?
It is a computer or network deliberately isolated from public or less-trusted networks according to a defined security boundary. Software and updates cross that boundary only through an approved transfer process, which may include reusable packages, dependencies, internal repositories, licenses, and configuration material.
Why do normal installers fail on offline machines?
A web bootstrapper cannot retrieve its main payload when its required endpoint is unreachable. Prefer a publisher-documented reusable package, then stage any separate prerequisites, activation material, trust data, or optional components. A label such as full, standalone, or offline does not prove that one file contains everything the target needs.
How do I verify an installer is safe before transferring it?
On the connected staging machine, preserve the publisher source record. Compare SHA-256 when the publisher provides an authenticated reference, and inspect a platform signature when the package has one; connect the displayed signer to publisher documentation. Record your own approved-package hash so the offline side can detect transfer changes. These checks provide evidence, not a guarantee of safety.
How do I keep air-gapped software up to date?
Set a recurring schedule to re-download the current installer on a connected machine, re-verify it, and re-deploy through the approved transfer process. Keep an inventory of installed versions so you know what needs refreshing.
Conclusion
Deploying to air-gapped machines depends on a documented chain: obtain a publisher-documented package, authenticate its source and available verification material, transfer it through an approved mechanism, stage its prerequisites, test the installation method, and schedule later updates. Each application can add exceptions such as activation, device drivers, certificate validation, or separately distributed components, so preserve those limitations in the runbook. This directory records candidate publisher and distribution sources; it does not replace package testing or an organization's approval process.
