Airgapped security tool evaluation checklist

Most security tools were designed to phone home, and “we support airgapped deployments” is applied to architectures that need internet access weekly. This checklist is what to ask before you trust a tool in a network where connectivity is restricted, monitored, or absent. Work through it with every vendor; the answers sort the genuine from the retrofitted quickly.

Use it in a proof-of-concept, not just a briefing - claims are cheap, and several of these can only be answered by trying to run the tool with the network unplugged.

Deployment and data residency

• Where does the analysis actually execute? If any code, artifact, or finding transits vendor infrastructure, the tool is disqualified for a restricted network before any feature comparison.
• Is the product a single self-contained binary or install, or does it require a fleet of services and a control plane?
• Does anything about the deployment assume a reachable cloud endpoint at install, activation, or runtime?
• Can the entire product run with the network physically disconnected, and did you verify this in a test rather than accept it as a claim?

Licensing

• What happens to licensing after a year with zero connectivity? Acceptable answers are “nothing” or a specific, plannable expiry mechanism.
• Are there license checks that call vendor servers, and can they be disabled or are they simply absent?
• Is there a documented, offline license-activation and renewal process?

Data updates

• How does vulnerability and detection data arrive in the network, and is it a signed bundle you import on your own schedule?
• Is the bundle’s signature verified cryptographically on import?
• Does every result record which data-bundle version it was evaluated against, so past scans are reproducible and auditable?
• Can you control exactly when data changes, rather than having it shift under you mid-cycle?

Determinism and reproducibility

• Does the same input produce the same output on any hardware, every time? Run the same scan twice on two machines and diff the results.
• Are findings identified by stable, content-based fingerprints, so triage decisions survive rescans and refactors?
• If an analysis cannot complete within available resources, does the tool report it loudly rather than return a quietly smaller result?

Telemetry and egress

• What telemetry exists? “Disabled by default” means the transmit path exists; “absent” means it was never built. These are different assurances.
• Is there any egress path - crash reporting, usage analytics, update checks - that could carry information out of the network?
• Can you demonstrate, at the network level, that the tool makes no outbound connections during a scan?

Coverage and output

• Are the offline results identical to a connected deployment, or is the offline version a reduced product wearing the same name?
• Does the tool emit standard, machine-readable output (SARIF, CycloneDX) that your other systems can consume without bespoke parsers?
• Does it cover the surfaces you actually need, or would full coverage require several separate products and consoles?
• Can findings be correlated with the rest of your security data inside your network, or does correlation require a cloud service?

How to read the results

A tool that answers all of these cleanly is rare, because true offline-first operation constrains a vendor’s entire architecture rather than adding a flag. If a product’s airgap story survives every question - especially the ones you verified by pulling the network cable - you have found the genuine article.

The reasoning behind these questions is in what airgapped actually means, and if you would like to run the questions against a platform built offline-first from the start, a live demo is the fastest way - the first command it teaches you is the one that proves the network is not required.