SolarWinds NPM alternative for air-gapped and OT networks

Why SolarWinds NPM is hard to run on an isolated network, and what replaces it

Network teams monitoring air-gapped or OT environments need a monitoring server that can be installed, updated and operated without reaching the internet. SolarWinds itself advises keeping Orion off the internet, so the practical question is whether a self-hosted tool can be built, patched and run entirely on infrastructure you control. This page covers two candidates: Zabbix and LibreNMS. Both are self-hosted open-source platforms that run on servers in your own network, so no polling data or device inventory has to leave the isolated boundary. This page does not claim a vendor certification or validation for either tool in your regulatory context. Confirm that with the vendor, your assessor and your own environment.

Moving Orion's model onto an isolated network raises three practical problems. The first is software delivery: every package, container image and rule set must be fetched on an connected staging system, checked for integrity and authenticity, and carried across the boundary. For utilities, NERC CIP-013-2 expects supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches, so that transfer step needs a documented owner. The second is polling across segments, where collectors must reach devices behind boundaries without opening the monitoring server to them. The third is the monitoring server itself, which holds credentials for every network device and therefore needs the same hardening as any other privileged system.

Decide early which deployment pattern fits each zone. Zabbix proxies and LibreNMS distributed pollers both let a central server receive data from collectors placed inside each segment, which is where the isolated-network design usually starts. Ask each candidate's maintainers and your integrator to confirm which packages, container images and vulnerability or rule data must be mirrored for offline use, and how those artifacts are refreshed. Then record who approves each transfer and how the monitoring server's access is logged. Those decisions, not the choice of tool alone, determine whether the deployment stays within your boundary rules.

What isolation and OT rules require from the monitoring server

A monitoring server in an isolated plant, utility or classified network sits inside the same compliance boundary as the systems it watches. The controls below describe what that boundary usually asks of the server, and each one changes how Zabbix or LibreNMS is installed, updated and reached. Whether any of them applies depends on your classification, your regulator and your contracts, so confirm the governing rules before you design the deployment.

Controlled vendor remote access

NERC CIP-005-7 requires that Interactive Remote Access to high and medium impact BES Cyber Systems pass through an Intermediate System, use encryption and multi-factor authentication, and include methods to detect and disable active vendor sessions. For a monitoring server, this means vendor support for Zabbix or LibreNMS should enter through a jump host you control, not a direct VPN into the poller. Confirm with your regulator and compliance lead whether the monitoring server falls within the scope of CIP-005-7 at all.

Verified software integrity at the boundary

NERC CIP-013-2 addresses supply chain procurement, including verification of software integrity and authenticity for vendor software and patches. Every package, container image, template and Zabbix or LibreNMS update carried across an isolated boundary should have its checksum or signature verified and recorded before installation. Keep a dated register of what was imported, from which source and by whom. Ask your supplier how they publish hashes and signatures for offline bundles.

Monitoring segmented by zone

Place one or more Zabbix proxies or LibreNMS distributed pollers inside each security zone, so polling traffic never has to cross a boundary that the rules do not permit. The central server then receives only the data it needs. Zabbix 7.0 and later can use proxy groups to reassign hosts when a proxy goes offline, which matters when a zone is intermittently connected. Document which zone each proxy serves and which firewall rules permit its SNMP, agent and database traffic.

Separation of monitoring from control networks

NIST SP 800-82 Rev. 3 is the NIST guide to operational technology security. It describes OT architectures in which monitoring and data collection are kept distinct from control functions, so that an observation platform cannot change a controller's behavior. Treat the monitoring server as a read-only consumer of OT data: SNMP and agent polling should be read-only, and no write community strings or control commands should be configured. Confirm the segmentation model with your OT security team.

Hardening the monitoring server itself

The monitoring server holds credentials for many devices, so it becomes a high-value target. Restrict administrative access to named accounts, use the authentication options in the Zabbix frontend or LibreNMS, store SNMP and database secrets in a controlled location, and limit inbound ports to what each zone needs. Plan for patching through your offline update process and record the baseline configuration after each change. Ask the vendor or integrator which hardening guide they follow and what logs the server produces for audit.

How Zabbix and LibreNMS fit an isolated network

Zabbix is usually the first candidate for isolated networks because its server, proxies, database and web frontend are all self-hosted components with no required external service. Installation packages, templates and the frontend can be staged on an internal mirror and carried across the boundary as signed media, then updated the same way. Polling of isolated segments is handled by proxies placed inside each zone, which collect data locally and send it back to the central server over a channel you define.

Offline operation: Packages and dependencies are mirrored internally and applied from transfer media. Confirm the exact package list for your OS with Zabbix before you build the offline repository.
License: Zabbix 7.0 and later are AGPL-3.0. Versions up to 6.4 remain GPL-2.0. Check which license applies to the version you select, especially if you modify the code.
High availability and proxies: Zabbix server supports a native HA cluster sharing one database, with failover after a configurable delay. Proxy groups from Zabbix 7.0 onward redistribute hosts when a proxy goes offline.
Supported platforms: Zabbix 7.4 supports MySQL or Percona, MariaDB, PostgreSQL with TimescaleDB, and SQLite for proxies only. Check the requirements page for the database versions your release accepts.
Trade-offs: Zabbix covers SNMP and agent monitoring well, but it does not provide NetPath-style path analysis, so path troubleshooting must be built or handled by other tools. Plan for staff who can maintain templates, upgrades and the database.

Before you commit, confirm the Zabbix support tier you need, since offline environments depend on vendor support during outages.

Deploying Zabbix or LibreNMS offline, step by step

This sequence takes a monitoring server from an internet-connected staging host to a working, locked-down deployment inside an isolated network, with every package and image verified before it crosses the boundary. The result is a monitoring platform that polls each segment through local proxies or pollers and can be updated on a planned cycle.

Build a staging host outside the boundary
The client's platform team prepares a clean Linux host on the connected side that matches the target operating system and architecture of the isolated server. This host downloads everything the offline install needs: the Zabbix or LibreNMS packages for the chosen operating system, the database and web server packages with their dependencies, and, for LibreNMS, the librenms/librenms Docker image if the team deploys containers. Confirm the supported operating systems and PHP or database versions in the install guide for the release you select, because the staging host must match them. Done means every package and image is listed in a manifest with its version and checksum, and a second host can install from that set with no outbound network access.
Verify packages and images before transfer
Before anything crosses the boundary, the security team checks the integrity and authenticity of each artifact against the publisher's published checksums or signatures, and records the results. This is the control that NERC CIP-013-2 describes for verifying software integrity and authenticity of vendor software and patches, so utilities and other regulated operators should align the check with their own supply chain procedure. Scan the packages with the scanner approved for the enclave, and keep the signed manifest with the media. Done means each item in the manifest has a recorded verification result, and any failure is held for review rather than carried across.
Transfer media through the approved process
Move the verified bundle into the isolated network using the media process the site already requires, such as a controlled removable device with logging and a designated custodian, or a one-way transfer appliance. The transfer procedure belongs to the client, and the client's security and operations leads should confirm who approves each transfer and how it is logged. Done means the receiving host holds a copy of the bundle, the manifest checksums match after transfer, and the transfer record is filed with the change.
Install Zabbix or LibreNMS from the local repository
Installation runs from the local package repository or the transferred files on the isolated server, with no outbound calls. For Zabbix, the team installs the server, frontend and database from local packages, and for LibreNMS it installs the PHP, MariaDB, NGINX or Apache, and Python dependencies or loads the Docker image. Confirm that the database versions used match the Zabbix requirements for the chosen release, and that the LibreNMS prerequisites match its install guide. Done means the web interface loads on the internal address, the server or poller service runs, and the install log shows no attempts to reach external hosts.
Deploy proxies or pollers in each segment
The team places a Zabbix proxy or a LibreNMS distributed poller in each isolated segment so that SNMP polling stays local and only the required data returns to the central server. Zabbix 7.0 and later can group proxies so that hosts are redistributed when a proxy goes offline, which matters where a segment has more than one collector. Confirm with the OT or plant owner which firewall rules allow the proxy-to-server path, and keep that path to the minimum ports the design requires. Done means each segment's collector reports data to the central server, and a test device in each segment appears with current values.
Configure SNMP discovery by segment
Operators create discovery rules for each segment with the SNMP community or SNMPv3 credentials approved for that zone, and they limit each rule to the address ranges that belong to it. Prefer SNMPv3 with authentication and privacy where devices support it, and confirm the credential approach with the asset owner, since OT devices may restrict the protocols they accept. LibreNMS discovers devices by SNMP, collects STP, OSPF, BGP, VLAN, ARP and FDB data, and can use its API for inventory checks. Done means discovered devices match the approved asset list for each segment, and any unexpected device is raised to the owner rather than added automatically.
Harden the server and web interface
The security engineer restricts administrative access to a named group, removes default accounts and passwords, and sets the Zabbix authentication method the client has chosen, such as internal or an approved external directory. Apply least privilege to user groups and host permissions, limit the database account to the schema it needs, and expose the web interface only on the internal management network through NGINX or Apache with TLS. NERC CIP-005-7 requires Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication, so confirm that design with the compliance owner. Done means a permission review shows that each account can reach only its own hosts and that the web interface answers only on the approved interface.
Plan offline update cycles
The operations team builds a recurring update calendar around the Zabbix release model. Standard releases come out every 6 months and are supported for 12 months, while LTS releases come out every 1.5 years and are supported for 5 years, with full support for three years and limited support for two. Zabbix 7.0 LTS has full support until 30 June 2027 and limited support until 30 June 2029, so the team should choose its track and schedule upgrades before support tapers. For LibreNMS, track its published releases and repeat the same staging, verification and transfer steps for each update. Done means a written update plan names the track, the staging owner, the verification step and the change window, and the client has confirmed it with its change board.

How proxies and pollers reach devices across isolated segments

The core design decision for an isolated network is where the polling happens. In a Zabbix deployment, a Zabbix proxy placed inside each segment collects data from the devices on that segment and forwards it to the central server, so the only traffic that must cross a boundary is the proxy-to-server path. The server never needs direct reachability to SNMP agents, switches or PLCs-adjacent gateways in a zone that the firewall policy keeps closed. Confirm the exact port and direction your policy permits for that path, and confirm whether the proxy initiates the connection or whether your boundary rules require the reverse, because many OT firewalls only allow outbound sessions from the zone.

Zabbix 7.0 and later support proxy groups, which redistribute monitored hosts between proxies automatically for load balancing and high availability when a proxy goes offline. For a plant or utility network, this matters most where two proxies can reach the same segment through different paths. Test the failover before you rely on it: take one proxy offline in a maintenance window, confirm that its hosts move to the surviving proxy, and check that the surviving proxy can actually reach those devices from its own position. A group only helps if each proxy has a valid route to the hosts it may inherit.

LibreNMS handles the same problem with distributed polling, where additional polling nodes are attached to a central instance and poll devices in their area. The exact setup, database access and queue requirements are covered in its documentation, so confirm them against your version before you design the zones. Each approach trades off the same things. A single central server is simpler to back up, patch and audit, and it has one place to hold credentials, but every zone depends on a link to it and on its capacity. Per-zone servers keep polling local and survive a WAN or boundary outage, but multiply the systems you must harden, update offline and monitor. Whichever model you choose, document every allowed flow in writing and have the network and security owners sign it off before you open any rule.

Evidence an auditor or regulator will ask you for

An assessor reviewing an isolated Zabbix or LibreNMS deployment will look for a chain of records: what is installed, how it was configured, how packages crossed the boundary, who could reach it, and whether it can be restored. The cards below list those records and what to check in each. DeployOpen prepares this evidence as part of implementation, but independent auditors and certification bodies issue any audit report or certification.

Asset inventory exported from the server

Keep a dated export of every monitored host, interface, proxy and monitoring server version, taken from the Zabbix or LibreNMS database or API on a fixed schedule. In an isolated plant or utility network, this inventory is the baseline that shows which devices the monitoring system can see and which segments are still unmonitored. Check that each proxy's assigned hosts add up to the total in the export, and that the export itself is stored inside the enclave with restricted access. Confirm the export format with your assessor before the first review.

Configuration baselines and change records

Record the approved configuration of the monitoring server, proxies, database and web frontend, including the zabbix_server.conf and zabbix_proxy.conf settings and the LibreNMS config.php values. Every change should carry a ticket reference, the person who approved it and the hash of any template or script imported. Compare the running configuration against the baseline on a set schedule so drift is caught before a review does. Ask your assessor which change-management evidence they expect for OT systems.

Package and image hash verification logs

Each transfer across the isolated boundary needs a log showing the file name, the published checksum or signature, the hash computed inside the enclave, the verifier and the date. This is the practical control behind the software integrity expectations in NERC CIP-013-2, which address verification of vendor software and patches. Store the source media record alongside the log, so a reviewer can trace each installed package back to where it came from. Confirm with the vendor where signed checksums are published for each release you carry in.

Access control and MFA configuration

Export the user, role and group definitions from the monitoring frontend, together with the authentication method configured for each. Show which accounts can change polling, triggers or proxy assignments, and which are read-only for operators. Where the requirement applies, document how multi-factor authentication is enforced for interactive access, since NERC CIP-005-7 expects it on Interactive Remote Access to high and medium impact systems. Review the export after every staffing change.

Remote session and vendor access records

Keep logs of every remote session into the monitoring environment, including who connected, through which intermediate system, when, and what was changed. Vendor access needs its own record: the approval, the scope granted, and the time the session was disabled. NERC CIP-005-7 expects methods to detect and disable active vendor remote access, so test that disconnection works and keep the result. Ask your assessor how long these logs must be retained for your sector.

Backup and restore test results

A backup that has never been restored is not evidence. Keep the backup schedule, the storage location inside the enclave, and dated restore tests that rebuild the monitoring server and database on separate hardware. Record how long the restore took, which items were missing and what was corrected. For Zabbix high availability, record the failover tests as well, including the failover delay setting in use. Agree the test frequency and acceptance criteria with the system owner in advance.

Questions buyers ask before running Zabbix or LibreNMS on an isolated network

What does it cost to run Zabbix or LibreNMS on an isolated network?

Open-source Zabbix and LibreNMS carry no license fee, so the cost is the work and the infrastructure around them. The recurring parts are monitoring staff time, servers or virtual machines for the server, database and proxies, storage for history, and any support subscription you choose to buy. Zabbix states its open source software has no license fee, no device limits and no feature gates. Paid Zabbix technical support comes in Silver, Gold, Platinum, Enterprise and Global tiers. Ask any quote to separate one-time build work from recurring operations, and to list hardware and virtualization costs separately so you can compare them with your current licensing.

How do Zabbix support tiers and response times differ?

Zabbix support tiers range from 8x5 coverage with a 1 day response at Silver and a 4 hour response at Gold, up to 24x7 coverage with a 2 hour response at Platinum, a 1.5 hour response at Enterprise and a 1 hour response at Global. Choose the tier by how fast your operators need a vendor response when a poller or proxy fails inside a plant or utility segment. Check the current terms on the Zabbix support page before you budget, because tier details can change between releases.

How long does an isolated-network deployment take?

Duration depends on scope: the number of segments, the device types behind each proxy, how many monitored items you need, how much existing monitoring you migrate, and how many approval steps your change process requires. Plan the timeline around change windows and site access, not only the build. DeployOpen works to a fixed scope agreed in writing before work starts, and the deliverables and timeline appear in that document. Ask for a timeline that lists each segment, its change window and its acceptance test.

What must our team supply before the work starts?

Plan to provide network diagrams showing every isolated segment, boundary and jump point, a device list with models, OS versions and SNMP or agent support, the expected polling volume, and the change windows for each site. You also need named contacts for operations and security, the approved software transfer method into the enclave, and your access and authentication rules. Missing diagrams and change windows are the most common reasons a schedule slips, so confirm them in the scope before work begins.

Can our own team run this without outside help?

Yes, many teams do, provided they have Linux administration, database, SNMP and network skills, and time for the build and the template or alert rebuild. Zabbix and LibreNMS both document installation on Linux, and LibreNMS supports Ubuntu 24.04 and 26.04, Debian 12 and 13, and RHEL derivatives. The honest test is whether you can staff the on-call and upgrade cycle after go-live. An outside partner can carry the build, hardening and documentation, while your team keeps ownership of daily operations.

How do updates and packages get to an offline monitoring server?

Updates arrive as packages you verify and carry across the boundary by an approved process, then install from a local repository or media. Keep a record of each package's source, hash and approval, because NERC CIP-013-2 requires supply chain processes that address verification of software integrity and authenticity of vendor software and patches. Plan for an offline mirror of OS packages, the Zabbix or LibreNMS release, and the database packages, and rehearse the process on a staging host before production. Confirm the exact mirror and transfer tooling with your security team and your vendor.

How is a support contract different from a deployment engagement?

A deployment engagement is fixed in scope: it covers agreed planning, build, integration, hardening, documentation and handover, with deliverables and timeline set in writing. A support contract is ongoing: it covers upgrades, backups, monitoring of the platform, incident response and continuous work, usually as a retainer. Ask which of the two a quote includes, and what happens at handover. You can also buy vendor support from Zabbix separately from any implementation partner, so decide which parts of operations you need from each party.

Licensing and support choices that matter for regulated buyers

The first licensing question for an isolated network is which Zabbix license applies to the version you install. Zabbix moved to AGPL-3.0 with Zabbix 7.0, while every release up to 6.4 remains under GPL-2.0. Zabbix states that its open source software carries no license fee, no device limits and no feature gates, so the cost of the core product does not change with the number of sensors or devices. Paid technical support is a separate contract with its own tiers, from Silver through Global, and response times differ by tier. Ask your legal and procurement teams whether AGPL-3.0 obligations apply to any modifications you make to the web interface or templates, and whether a support subscription is required to meet your operator's maintenance expectations.

LibreNMS is governed as a community project, and its maintainers set priorities based on the Debian Social Contract and take contributions through GitHub, the community forum and Discord. That model suits teams that can review code and follow releases themselves, but it means no single vendor is contractually committed to fix a defect on your timetable. Its license is GPLv3 with exceptions for bundled third-party packages, so review LICENSE.txt against the packages you actually ship across the boundary. Its API v1 is documented as beta, so do not build a long-lived integration with an OT historian or ticketing system on it without pinning versions and testing each upgrade.

Confirm version support windows against your own patch cycle before choosing a release line. Zabbix publishes separate full and limited support dates for each LTS line, and standard releases receive support for a shorter period than LTS releases, so a plant that patches once a year may need an LTS branch and a documented upgrade path. LibreNMS publishes frequent point releases, which helps when you need current fixes but adds validation work for each import into the isolated environment. Write down who receives release notes, who approves a version for the offline mirror and how long a version may stay in service after its support ends.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For monitoring of isolated plant, utility or classified segments, we start from the segment map and the change process, then build Zabbix or LibreNMS to fit it.

How we scope

Written scope lists each isolated segment, the device types to poll and the proxy placement for each zone
We confirm how packages, templates and vendor updates cross the boundary and who approves each transfer
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

Offline installation media and package sets are assembled and checked against the agreed software inventory
Zabbix proxies or LibreNMS distributed pollers are configured per segment with encrypted, authenticated paths
The monitoring server is hardened and its access controls, logging and backups are tested before cutover

How we hand over

Documentation covers the offline update procedure, proxy topology, credential handling and recovery steps
Evidence is prepared for your controls mapping, such as access and change records, for independent assessors to review
Operators are trained on alert handling and on running the offline update process in their own environment

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Each upgrade is staged through the same verified transfer process used for the initial build
We confirm the monitoring platform's current release and support dates with you before any change window