📋 Table of Contents
Air-gapped lab networks, secure facilities, freshly imaged laptops without network drivers, and metered field sites often need or benefit from software staged elsewhere.
An offline software kit is a controlled collection of packages, dependencies, source records, and tested commands carried on approved media or staged on an internal share. Its usefulness is limited to the operating systems, architectures, prerequisites, licenses, and scenarios you tested. This guide shows how to assemble and maintain that evidence rather than promising that one folder works on every disconnected machine.
1 Stage reusable packages and their prerequisites
A web bootstrapper that retrieves its main payload at run time is a poor fit for an air-gapped target. Prefer a publisher-documented reusable package whose main payload can be retained, but do not assume a file labeled full, offline, standalone, or enterprise contains every prerequisite. Activation material, drivers, language packs, runtimes, certificate updates, or optional features may still be separate.
Record the exact artifact, architecture, operating-system support, dependencies, licensing requirements, and expected network behavior. Our availability notes can identify candidate sources, but the publisher's current documentation and a representative disconnected test determine whether a package belongs in your kit.
2 What belongs in a baseline kit
Build the baseline from the target role and approved support plan rather than a universal checklist. A developer workstation may need an editor, Git, and specific runtimes from the Developer Tools catalogue, while a kiosk or lab image may allow a much smaller set. Include only software your organization is prepared to license, configure, patch, and support.
- 1
Archiver — an approved tool for the archive formats present in your workflow.
- 2
Browser — a publisher-documented reusable package, plus its policy and update plan.
- 3
Media playback — an approved player and any separately required codecs for your formats.
- 4
Runtimes — the dependencies other apps assume are present, like the DirectX runtime and the Visual C++ redistributables.
- 5
Support tooling — only tools approved for the target role and security boundary; do not put an air-gapped target online merely to enable remote support.
- 6
Security and recovery — organization-approved offline-capable scanning or recovery tooling, with current definitions, controlled update media, and a documented response process.
3 Record the strongest verification evidence available
Treat an offline kit as part of a software supply chain. NIST's cybersecurity supply-chain risk-management guidance describes managing risk across acquisition, deployment, use, and maintenance; tailor that organizational guidance to the kit's scope and risk. Preserve the publisher landing page, final source URL, filename, version, architecture, retrieval date, and review result for every artifact. If the publisher supplies a SHA-256 value through an authenticated channel, calculate the local digest with Get-FileHash .\setup.exe -Algorithm SHA256 and compare the complete values; Microsoft documents the cmdlet in its Get-FileHash reference. If the package is Authenticode-signed, inspect Get-AuthenticodeSignature .\setup.exe and connect the displayed signer and trust result to the publisher's documentation. Some formats and publishers provide only one of those forms of evidence, and neither establishes safety by itself. Follow the fuller checklist on verifying installer safety and your organization's scanning and approval controls.
💡 Tip: Record unavailable evidence as unavailable instead of inventing it. An unexplained checksum mismatch, invalid signature, or signer mismatch should stop the package from entering the kit until it is resolved.
4 Organise it so it is usable under pressure
A collection of unexplained EXE files is not a controlled kit. Structure it around the named target, documented deployment phases, and evidence available for each artifact so operators can distinguish publisher records from locally generated checks.
- 1
Group folders by the target's tested deployment phases—for example prerequisites, applications, and approved support or security tooling—rather than assuming one universal product order.
- 2
Keep a locally generated _checksums.txt to detect later storage or transfer changes; retain authenticated publisher checksums separately and label their source.
- 3
Keep a _manifest.md listing each app, its version, source URL, and the date you added it.
5 Keep it current without re-downloading everything
Packages age, and security-sensitive applications may receive urgent fixes between scheduled reviews. Set a maximum review interval that matches organizational policy and subscribe to vendor security notices; a monthly review may be a starting point for some kits, not a guarantee of acceptable exposure. Compare the manifest with supported releases, advisories, revoked certificates, changed dependencies, and licensing requirements. Re-test every artifact that changes, including utilities that appear stable.
Frequently Asked Questions
What is the difference between an offline installer and a web installer?
A web installer retrieves some or all of its payload during setup. A package labeled offline, standalone, full, or enterprise usually carries more of the main payload locally, but may still depend on prerequisites, activation, certificate checks, or optional downloads. Publisher documentation plus a representative disconnected test is stronger evidence than the label.
How do I verify an installer is safe before adding it to my kit?
Preserve source provenance first. Compare a local SHA-256 digest when the publisher supplies an authenticated reference, and inspect a platform signature when the package has one. A match and valid signature provide useful integrity and signer evidence, but they do not independently prove that the package is safe or that the signer is the publisher you intended; connect the reference and signer to publisher documentation.
What should go in a basic offline kit?
There is no universal minimum. Define the target role, approved applications, operating systems, architectures, prerequisites, licensing material, recovery tools, and patch process. A browser, archiver, media player, runtime, support tool, or scanning tool belongs only when that role needs it, the security boundary permits it, and your organization can maintain it.
How often should I refresh an offline software kit?
Set the maximum age from organizational policy, vendor support cycles, and the risk of the included software. Monitor vendor security notices between reviews and rebuild sooner for an urgent fix, revocation, or dependency change. Track exact versions and review dates in the manifest, then re-test changed artifacts.
Can I run an offline kit from a USB drive?
A USB drive can carry the kit if removable media is allowed by policy. NIST's OT-focused SP 1334 describes portable-media risks and layered controls that may inform the organization's assessment. Test the exact packages, dependencies, licenses, and commands on representative compatible systems, protect the drive from unauthorized writes, and do not assume every installation or first-run feature is network-independent.
Conclusion
Build the kit for named target configurations and keep it on a documented review schedule. Retain publisher-documented packages with their dependencies, source records, available checksum or signature evidence, test results, commands, and a version manifest. Because not every publisher or format supplies both hashes and signatures, record which checks were possible and route missing or conflicting evidence through your approval process before deployment.
