{"id":9009,"date":"2026-09-23T13:46:14","date_gmt":"2026-09-23T08:16:14","guid":{"rendered":"https:\/\/www.anakage.com\/blog\/?p=9009"},"modified":"2026-09-23T13:46:14","modified_gmt":"2026-09-23T08:16:14","slug":"third-party-patching-air-gapped-networks","status":"publish","type":"post","link":"https:\/\/www.anakage.com\/blog\/third-party-patching-air-gapped-networks\/","title":{"rendered":"How to Do Third-Party Patching on Air-Gapped Networks (2026)"},"content":{"rendered":"

Publish the third-party updates to an internet-connected WSUS server first, then export the catalogue and content and carry both across the air gap to your offline WSUS server. Your endpoints scan against the offline server and install from it. The step most guides skip is the signing certificate, which must be trusted on every client before any of this works.<\/p>\n

Air-gapped network \u2014 a network physically isolated from the internet and all external connections.<\/p>\n

This guide covers applications like Chrome, Adobe Reader, Java and 7-Zip. For Windows server patching on the same kind of network, see our step-by-step guide to patching Windows servers on an air-gapped network<\/a>.<\/p>\n

Why Third-Party Patching Is Harder Than Windows Patching<\/h2>\n

WSUS was never built for this. Third-party patching is technically possible through local publishing, but Microsoft’s own documentation describes it as best performed by organisations with dedicated development and testing resources. (Source: Automox<\/a>, January 2026)<\/em><\/p>\n

That is a polite way of saying it is a project, not a setting.<\/p>\n

Three things make it harder than Windows updates:<\/p>\n

    \n
  1. Microsoft signs Windows updates. You must sign third-party ones yourself.<\/li>\n
  2. There is no catalogue to sync from. You build the packages.<\/li>\n
  3. Every application has its own installer behaviour and command-line switches.<\/li>\n<\/ol>\n

    Where WSUS Stands in 2026<\/h2>\n

    Microsoft deprecated WSUS on 20 September 2024. It receives no new features, but it still ships in Windows Server 2025 and remains supported for that lifecycle, to roughly 2035. (Source: InventiveHQ<\/a>, July 2026)<\/em><\/p>\n

    Air-gapped networks are one of the few cases where WSUS remains the right answer. Disconnected environments that cannot reach the internet require on-premises solutions, and WSUS handles offline update distribution. (Source: Automox<\/a>, January 2026)<\/em><\/p>\n

    Microsoft also reversed course on a related deprecation. Driver synchronisation was due to end in April 2025, but Microsoft postponed removal indefinitely, citing customer feedback on disconnected scenarios including air-gapped manufacturing networks and classified government environments. (Source: miloch.dev<\/a>, June 2026)<\/em><\/p>\n

    So you can build on WSUS today. Plan for a longer-term alternative anyway.<\/p>\n

    The Full Process, Step by Step<\/h2>\n

    You need two WSUS servers. One connected to the internet, one inside the air gap.<\/p>\n

    Step 1 \u2014 Set Up the Connected Publishing Server<\/h3>\n

    Stand up a WSUS server outside the air gap. This server never manages production endpoints. Its only job is to build and hold the update catalogue.<\/p>\n

    Install your third-party publishing tool here. Patch My PC and similar tools publish into WSUS through the same local publishing mechanism.<\/p>\n

    Step 2 \u2014 Sort Out the Signing Certificate First<\/h3>\n

    This is the step that breaks most deployments, so do it before anything else.<\/p>\n

    Third-party updates need a code signing certificate. That certificate must be trusted on every client in the air-gapped network, in both the Trusted Publishers and Trusted Root stores.<\/p>\n

    Deploy it by Group Policy before you publish a single update. If a client does not trust the certificate, the update appears in the catalogue and silently fails to install.<\/p>\n

    One known limitation: if your environments require different WSUS signing certificates, you may need a separate WSUS server for each. (Source: Patch My PC<\/a>)<\/em><\/p>\n

    Step 3 \u2014 Publish the Updates You Need<\/h3>\n

    Publish only the applications actually installed in your environment. Every published update adds to the export size, and you will be carrying that size across the gap by hand.<\/p>\n

    Start with your highest-risk applications. Browsers, PDF readers and Java are the usual priorities.<\/p>\n

    Step 4 \u2014 Export the Catalogue<\/h3>\n

    Run the export from the WSUS tools directory on the connected server:<\/p>\n

    \n
    \n
    cd \"C:\\Program Files\\Update Services\\Tools\"\r\nwsusutil.exe export C:\\WSUSExport\\export.xml.gz C:\\WSUSExport\\export.log<\/code><\/pre>\n<\/div>\n<\/div>\n
    Here is the trap. The export moves metadata only. It does not move the update files or your approvals. (Source: Anakage<\/a>, August 2026)<\/em><\/p>\n
    You must copy the WsusContent folder separately.<\/p>\n
    One more gap specific to third-party updates. The export carries the metadata clients need to detect and install updates, but it does not transfer the locally published Software Distribution Package. If you plan to modify published updates on the offline server, you need to preserve the SDP separately. (Source: Patch My PC<\/a>)<\/em><\/p>\n
    Step 5 \u2014 Scan the Media Before It Crosses<\/h3>\n
    Your removable drive is now the only path into an isolated network. Treat it accordingly.<\/p>\n
    Scan it on a dedicated malware-scanning station before it touches the offline side. Many teams use a tool such as OPSWAT for this step. (Source: Anakage<\/a>, August 2026)<\/em><\/p>\n
    Log every transfer. Your auditor will ask who carried what, and when.<\/p>\n
    Step 6 \u2014 Import on the Offline Server<\/h3>\n
    Copy the WsusContent files into the matching path on the offline server first. Then import the metadata:<\/p>\n
    \n
    \n
    cd \"C:\\Program Files\\Update Services\\Tools\"\r\nwsusutil.exe import C:\\WSUSImport\\export.xml.gz C:\\WSUSImport\\import.log<\/code><\/pre>\n<\/div>\n<\/div>\n
    Order matters. Importing metadata before the content is in place leaves clients detecting updates they cannot download.<\/p>\n
    Step 7 \u2014 Approve and Point Clients<\/h3>\n
    Approvals do not travel with the export. Approve the updates again on the offline server.<\/p>\n
    Point your air-gapped endpoints at the offline WSUS server through Group Policy. This method needs no third-party transfer tools and keeps the air gap intact. (Source: Microsoft Q&A<\/a>, April 2026)<\/em><\/p>\n
    Four Things That Break Offline Patch Cycles<\/h2>\n
    Untrusted signing certificate.<\/strong> The most common failure, and the hardest to diagnose, because nothing errors loudly.<\/p>\n
    Content copied after metadata.<\/strong> Clients detect the update, try to download, and fail.<\/p>\n
    Approvals forgotten.<\/strong> The update sits in the catalogue and never deploys.<\/p>\n
    Export size growth.<\/strong> Publish narrowly. A catalogue covering every application you have ever installed becomes impractical to carry.<\/p>\n
    How Often to Run the Cycle<\/h2>\n
    Set a fixed cadence rather than reacting to each release. Monthly works for most environments, aligned to Patch Tuesday.<\/p>\n
    Keep an out-of-band path for critical vulnerabilities. Agree in advance who can authorise an unscheduled transfer, because that conversation during an active exploit wastes days.<\/p>\n
    When WSUS Local Publishing Is Not Workable<\/h2>\n
    Local publishing needs packaging skill, certificate management and a person who owns the process. Smaller teams often cannot sustain it.<\/p>\n
    Two alternatives:<\/p>\n
    Pre-packaged software libraries.<\/strong> Some endpoint platforms ship ready-made application packages, so you deploy without building or signing anything yourself.<\/p>\n
    Agent-side installation.<\/strong> An agent that holds the installer locally and runs it on the endpoint removes the catalogue and approval layer entirely. This works where agents operate fully offline.<\/p>\n
    Anakage takes the second approach, shipping ready-to-go software packages that install without SCCM packaging, with agents that run fully offline. (Source: Anakage competitor analysis)<\/em><\/p>\n
    Evaluate it against your actual constraint. If you already have WSUS running smoothly and someone who owns it, the process above is cheaper.<\/p>\n
    FAQ<\/h2>\n
    Q: Can WSUS patch third-party applications?<\/strong> A: Only through local publishing, where you package and sign the updates yourself. Microsoft’s documentation states this is best handled by organisations with dedicated development and testing resources. It is not a built-in catalogue like Windows updates.<\/p>\n
    Q: How do you update Chrome on an air-gapped network?<\/strong> A: Publish the Chrome update to a connected WSUS server using a third-party publishing tool, export the catalogue and content, carry both across the gap, then import and approve on the offline server. Alternatively, deploy the installer directly through an agent that works offline.<\/p>\n
    Q: Does wsusutil export include the update files?<\/strong> A: No. The export contains metadata only. You must copy the WsusContent folder separately, and your approvals do not transfer either. This catches most teams on their first cycle.<\/p>\n
    Q: Is WSUS still supported after deprecation?<\/strong> A: Yes. Microsoft deprecated WSUS in September 2024, meaning no new features, but it still ships in Windows Server 2025 and remains supported for that lifecycle. Air-gapped environments remain one of its valid use cases.<\/p>\n
    Q: Do I need a signing certificate for third-party updates?<\/strong> A: Yes. Third-party updates must be signed, and the certificate must be trusted on every client in both the Trusted Publishers and Trusted Root stores. Deploy it by Group Policy before publishing anything.<\/p>\n
    Q: How often should I run an offline patch cycle?<\/strong> A: Monthly suits most environments, aligned to Patch Tuesday. Agree an out-of-band process for critical vulnerabilities before you need it.<\/p>\n
    Q: What if I cannot use WSUS at all?<\/strong> A: Look at agent-based deployment, where the installer runs locally on the endpoint without a catalogue or approval workflow. Pre-packaged software libraries also remove the packaging and signing burden.<\/p>\n
    Closing<\/h2>\n
    Third-party patching on air-gapped networks is a process problem more than a technical one. The mechanics take a day to learn; the certificate, the content copy and the approvals are what cost teams weeks.<\/p>\n
    If your team cannot sustain a packaging and signing workflow, agent-based deployment removes most of it. The Anakage team runs a 30 minute walkthrough for offline environments at anakage.com\/book-a-demo<\/a>.<\/p>\n
    Sources<\/h2>\n