Safeguard
Application Security•

Air-gapped plants and mines: security scanning and AI with no internet

What stops working when a site has no internet, how to move vulnerability data and updates across the gap safely, and what CISA's December 2025 AI in OT guidance says about connectivity.

Safeguard Security Team
5 min read

Some sites cannot be online. A process plant, an underground mine, a substation or a defence facility may have a network that is deliberately cut off from the outside. That choice protects the process. It also breaks almost every tool that assumes a package registry, a vulnerability feed and a cloud API are one HTTPS call away.

On 3 December 2025, CISA and partner agencies from Australia, Canada, Germany, the Netherlands, New Zealand and the United Kingdom, with the NSA's AI Security Center and the FBI, published "Principles for the Secure Integration of Artificial Intelligence in Operational Technology." It speaks directly to the offline case, and this post builds on it.

Safeguard does not operate plant equipment. What it offers for these sites is the software supply chain side: scanning, SBOMs, policy gates and AI models that can run inside the environment.

What's affected

Every offline site hits the same five gaps.

  1. Vulnerability data. Scanners compare components to a feed of CVEs. No internet means the feed ages from the day you install.
  2. Packages and updates. Build tools and operating system updates normally come from public registries.
  3. AI models. Cloud hosted models are unreachable. If an AI assistant is part of your tooling, it has to run locally or not at all.
  4. Time and certificates. Signature checks and certificate validation rely on correct clocks and reachable revocation data.
  5. Evidence. Reports that say "scanned today" mean little if the data behind them is three months old.

How to check what you depend on

Run your scan tooling from a host with outbound traffic blocked and watch what fails. Then list each failure under the five headings above.

For the vulnerability data, the CISA Known Exploited Vulnerabilities catalog is a good test case, because it is a single JSON file you can carry across a boundary. The release dated 16 October 2026 held 1,748 entries. Its header tells you how old your copy is:

jq -r '.dateReleased, .count' kev.json

Put that date on every report you produce from the file. A scan result without the data date is hard to trust.

What to do now

Move data in one direction, through a checkpoint, and keep records of what crossed.

  1. Stage outside the zone. On an internet connected staging host, download the vulnerability data, the package set and any model snapshot. Compute hashes.
sha256sum bundle-2026-10-18.tar > bundle-2026-10-18.sha256
gpg --detach-sign bundle-2026-10-18.tar
  1. Carry the bundle across by an approved path. CISA's guidance says to "prefer push-based or brokered architectures that move required features or summaries out of OT without granting persistent inbound access," and that where data must cross, operators should "use one-way transfer patterns and audited staging buffers."
  2. Verify inside. Check the hash and signature before import. Reject anything that fails.
sha256sum -c bundle-2026-10-18.sha256
gpg --verify bundle-2026-10-18.tar.sig bundle-2026-10-18.tar
  1. Import into a local mirror. Packages go to an internal registry, vulnerability data to the local scanner, models to the local model server.
  2. Record the snapshot date of each data source in the scan report.
  3. Set a refresh rhythm and a rule for what happens when a KEV entry matters before the next bundle. A weekly bundle with an emergency path is a common starting point.
  4. Ask every vendor the connectivity question. CISA's guidance tells owners to ask "if vendors can operate on premises or without continuous access to the internet/vendor cloud" and to specify "conditions under which certain AI features can be disabled or enabled, with control given to the operator."

What this looks like with Safeguard

Safeguard deploys on premises and fully air-gapped, including the AI models running inside the customer environment, with signed offline snapshot delivery. There is also a Zero AI mode where the whole platform runs without any language model, so scanners and SBOM analysis work deterministically. The local runner keeps source code on the machine and sends only encrypted results to the platform, which suits sites that allow outbound HTTPS only. Ask for the current deployment specifics before you plan around them.

Why it matters

The guidance puts the problem plainly: connecting AI to OT can create "new, remotely accessible, internet-exposed attack paths," and some AI features in OT products "may require internet connectivity to function." A site that chose to be offline did so on purpose. A tool that quietly phones home undoes that decision.

The second risk is the opposite one. A site with no feed updates for a year is offline in the worst way: it feels safe because nothing is connected, and it cannot see new known exploited flaws in the software it runs. The answer is a disciplined, signed, one way supply of data and a visible snapshot date.

Quick check

What should every report from an offline scanner state?

The date of the vulnerability data it used. Without it, a reader cannot tell whether the result reflects this week or last quarter.

What does CISA's guidance prefer for moving data out of OT?

Push based or brokered architectures without persistent inbound access, and one way transfer patterns with audited staging buffers.

Why check a hash and a signature?

The hash proves the file was not changed in transit. The signature proves who produced it. Inside an air gap, a tampered bundle is a direct route to the process network.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.