The first post on this site was about automating a disconnected WSUS: an internet-connected exporter on EC2 that only runs during the monthly sync, feeding updates to an importer on a network with no internet access. It covered the how and skipped the why. This post is the why, and the parts of disconnected patching that matter more than the tooling.

Disconnected networks, the air-gapped and closed networks common in defense, industrial, and classified environments, are supposed to be safer because nothing can reach them from the internet. That’s true. But it moves the risk rather than removing it. Every update now has to physically cross a boundary, which makes patching slow and manual, which makes disconnected systems some of the furthest behind on patches of anything you’ll find. And whatever does cross the gap, usually removable media, becomes the threat vector. Stuxnet reached its target, an isolated network, on USB drives.

So disconnected patch management is really two problems: keeping patch latency down despite the gap, and making sure the only thing crossing the gap is what you meant to send.

The pipeline, end to end

Whatever the tooling, the workflow has the same stages.

1. Collect on the connected side. A staging system with internet access pulls updates from the vendors’ own sources: an upstream WSUS sync for Windows, a repository mirror (dnf reposync or similar) for Linux, vendor bundles for appliances and firmware. Pull from the official source and nowhere else. A convenient third-party mirror is a supply chain risk you’ve added for no reason.

2. Verify before you package. Vendors sign their updates: Microsoft updates carry Authenticode signatures, and RPM packages and repository metadata are GPG-signed. Check them on the connected side, then generate a hash manifest of exactly what you’re about to transfer. The manifest is what lets the disconnected side prove that what arrived is what left.

3. Transfer with chain of custody. Use dedicated, approved media that’s used for nothing else. Scan it on a standalone kiosk before it touches the disconnected network. Log every transfer: who carried it, when, what the manifest hash was, and who received it. Where the environment supports it, a one-way data diode replaces most of this with hardware that physically can’t send data back out.

4. Verify again and import. On the disconnected side, recompute the hashes and compare them to the manifest before importing anything. For WSUS, metadata moves with wsusutil export on the connected server and wsusutil import on the disconnected one, with the update content copied separately and approvals mirrored. For Linux, the verified packages become a local repository with createrepo_c, and hosts point at that instead of the internet.

5. Deploy in rings. A test ring that represents your real workloads goes first, then production in waves, inside approved maintenance windows and through normal change management. Disconnected environments usually can’t fail over to a cloud copy, so a bad patch hurts more there. Rings are cheap insurance.

6. Prove it worked. Scan after patching to confirm the vulnerabilities are actually gone.

That last step hides the most commonly missed piece of the whole process: the vulnerability scanner’s definitions have to cross the gap too. A scanner with three-month-old plugins will happily report a clean network that isn’t. Scanner updates belong in the same monthly transfer as the patches, with the same verification.

Cadence and prioritization

Microsoft releases on the second Tuesday of every month, and most vendors have a predictable rhythm of their own. A monthly transfer aligned to that schedule handles routine patching.

Routine isn’t enough for everything, though. CISA’s Known Exploited Vulnerabilities catalog lists vulnerabilities with confirmed active exploitation, and for federal agencies, Binding Operational Directive 22-01 sets remediation deadlines for them. A KEV-listed vulnerability on a disconnected system shouldn’t wait for the next monthly run just because transfers are inconvenient. The process needs a defined out-of-band path for emergencies, documented and rehearsed before it’s needed, not invented during the emergency.

Prioritize with context, too. A critical-severity finding on an isolated test box is less urgent than a medium on the domain controller everyone authenticates against. Severity scores are a starting point. Exposure, exploitability, and asset criticality decide the order.

When you can’t patch

Some systems can’t take a patch on schedule: a vendor hasn’t certified it yet, the system runs a process that can’t stop, or the fix breaks something critical. That’s normal, and it’s exactly what compensating controls and formal risk decisions are for:

• Reduce exposure. Disable the vulnerable service or feature if it isn’t needed. Segment the host so fewer systems can reach it.
• Restrict execution. Application allowlisting makes many exploits much harder to use, even on an unpatched host.
• Watch it more closely. Extra monitoring on the specific behavior the vulnerability enables.
• Document the decision. A POA&M entry or risk acceptance with an owner, the compensating controls, and a date to revisit. An unpatched system with a documented, approved risk decision is managed. One without it is just unpatched.

Measure the right things

Two numbers tell you whether the program is working. Patch latency is the time from vendor release to deployed in production, and on disconnected networks it’s the number that drifts. Coverage is the percentage of in-scope systems actually at the current patch level, verified by scan rather than by deployment tool reports, since a deployment tool only knows what it attempted.

Track failed installs as their own category. A host that fails the same update three months running is usually a broken update agent, and it’ll stay vulnerable until someone looks.

What’s worth automating

Even with a human carrying media across the gap, most of the work around the transfer can be scripted: the connected-side sync and export, signature checks, manifest generation, the disconnected-side verification and import, and the post-patch scan report. That’s what the original WSUS post was reaching for. The physical step is the bottleneck by design. Everything on either side of it should be push-button, so the only thing a person has to do is the part that can’t be automated: carrying a verified, logged, scanned package across a boundary on purpose.