Antivirus licensing for air-gapped environments: what to consider

Why antivirus causes problems in an air-gapped environment

An air-gapped environment is a network or segment without direct Internet access, often with restrictions on removable media. This mode increases security but changes the usual antivirus operation: what is automatic on a connected network becomes a separate process here, with people, procedures and checkpoints.

Problems most often start from differing expectations between InfoSec and IT. InfoSec expects up-to-date databases, clear reports and confirmation that all nodes are protected. IT sees an active license and assumes “if it’s bought, it works.” As a result, the license exists but updates don't arrive, the management console doesn't see some machines, and during an audit it turns out no one collected evidence.

Updates are a separate pain point. In an isolated environment, not only the frequency but the delivery method matters: via a dedicated transfer gateway, an offline repository, approved media or through a DMZ. If the scheme is poorly chosen, vulnerability windows appear: signatures become outdated, new threats go undetected, and staff begin to bypass rules to “fix it faster.”

Before purchasing, it's useful to clarify several questions. Otherwise antivirus licensing for air-gapped environments will quickly become a constant source of conflict between InfoSec, IT and procurement:

• how you will obtain, verify and import updates (who, from where, how often, with what validation);
• where the offline update repository will be stored and who is responsible for its integrity;
• how the license is counted: by devices, servers, virtual machines or cores;
• which reports InfoSec needs (coverage, currency, incidents, exceptions) and in what form;
• what counts as a violation: “no updates for 7 days,” “no console connection for 24 hours,” etc.

In practice, system integrators, including GSE.kz, often see the same picture: technically the antivirus is installed, but the process is not organizationally fixed. In a closed network, process determines outcome.

Licensing models: what actually works without the Internet

In an isolated network, the key question is not “which antivirus is best” but whether you can prove the right to use it and receive updates without constant vendor connectivity. When choosing a model, think immediately about accounting, license transfer and how it will look on an audit.

By devices, servers or users: what’s simpler offline

For a closed environment, licensing by devices (endpoints) and by servers is usually more convenient: they are easier to count in an inventory and tie to specific nodes. The “per-user” model in offline setups often leads to disputes: people change, accounts are duplicated, and proving who actually used a PC is difficult.

A practical approach is to fix rules in advance for what is considered a licensable object (physical PC, VM, terminal server, dedicated update server) and maintain a single asset list.

Before buying, check vendor details on counting:

• whether a physical PC and a virtual machine are counted separately;
• whether the management server and offline repository require separate licenses or are included;
• whether terminal servers are counted “per server” or “per session/user”;
• whether license transfer is allowed on hardware replacement and how it is confirmed.

Subscription vs perpetual license: where the risk hides

A subscription usually makes lifecycle control easier: the period is clear and the feature set is fixed. But updates are typically legal only with an active subscription. For offline environments this means you need a stable process to regularly obtain update packages and documents proving the right (license files, keys, entitlements) and move them into the environment.

A perpetual license seems more reassuring, but update rights are often purchased separately (support/maintenance). If maintenance ends, the product may continue to run, but without fresh databases and without reports on protection currency. For InfoSec this is usually unacceptable.

Also clarify module licensing in advance. EDR, device control, encryption, mail or web protection are often sold separately and under different metrics. In isolation this is critical: a module may be technically enabled but you may not be able to legally prove its use via reports.

Also find out how license checks work without Internet: local license file, offline activation by key, grace period or manual reconciliation. This determines which exports and documents you must keep with reports.

Updates without Internet: how to plan the process and frequency

In an air-gapped environment there is no direct access to the vendor cloud, so updates must be brought in and controlled. If you don't plan this before purchase, the product will be bought but current protection and reports will be missing.

There are usually several types of updates, each with its own frequency and risks: signature databases and reputation lists, engine and scanning component updates, module updates (mail, web control, DLP agents, exploit protection), and policy/configuration changes.

Frequency depends on contour criticality and allowable downtime. For segments with personal data or access to financial systems, daily or several-times-a-week delivery of databases is typical, while engine and module updates are rarer and applied after testing. For training labs or testbeds a less frequent rhythm may be acceptable, but with a fixed schedule and controls so backlog doesn't accumulate for months.

Define maintenance windows and fix them in the regulations. The document should state what is updated, who performs it, how to verify results, and what counts as success (for example, all nodes moved to the required version, and no false blocks of business applications occurred).

If updates are allowed only via a “sanitary gateway,” plan the process as a chain with checks:

1. download update packages in an external zone;
2. antivirus scanning and integrity checks on the gateway;
3. transfer by media or dedicated channel to a buffer zone;
4. test on a reference group (several PCs and one server);
5. roll-out into the environment and record the update for InfoSec.

Offline update repository: architecture options

Decide in advance how databases and modules will get into the network. The offline repository architecture affects risks, effort and whether you can present clear audit reporting.

The simplest option is a central update server inside the environment. All workstations and servers point to it so packages are not distributed to each machine. Pros: single point of control, identical database versions, fewer manual operations. Cons: it's a critical node requiring redundancy, storage for packages and clear maintenance rules.

If updates are moved via media (USB drives, external disks), two things matter: verification and logging. The media should be checked on the external side (scanning, hash verification, sealing according to organizational rules), and inside the environment the import event must be recorded: who, when and exactly what was loaded and from which source.

Staging zone

Practically it's convenient to split the process into two parts: the external environment where updates are downloaded and the internal environment where they are distributed. Between them place a “staging zone” — a separate machine or segment where updates arrive first and are additionally verified. Then packages are imported to the internal update server (often a dedicated server node in the rack).

Storage and rollback

Keep several versions of updates so you can quickly roll back if false positives or performance degradation occur after import. Usually 2–4 snapshots are enough: the last working one, the previous and 1–2 spares.

The regulations should state how many versions to keep and for how long, where to store them (on the update server and in a backup), who is allowed to roll back, and how reasons and outcomes are recorded (for audit).

Management and logging infrastructure in a closed network

Without a management center, antivirus in an air-gapped environment quickly becomes a set of disjoint installations: updates are not applied everywhere, policies diverge, and proving to an auditor that “everything is under control” becomes hard. Therefore, plan a managed infrastructure, not just agents on endpoints.

Management console: where and how to place it

The console is not just ornamental. It enforces unified policies, shows coverage across nodes, monitors database currency and produces reports for InfoSec. In closed networks the console is usually installed on a dedicated server inside the environment or on a separate VM in the segment with the most clients.

Store logs and events centrally or you'll lose history when a node is rebuilt or a local disk fills. A practical option is an events and logs database on a separate server in the environment, with a retention period (for example, 90–180 days) and backups. For small contours it's acceptable to keep logs on the console server, but only with space monitoring and regular backups.

Segmentation often breaks the “ideal” setup. If there are multiple subnets, branches or separate domains, plan how clients will find the management server (DNS, static addresses, firewall rules), whether distribution points are needed inside segments, and whether to have one common management server or several with separate policies and reports.

Roles and access: the minimum before chaos

Divide accesses from the start so administration, control and audit are not mixed. Usually four roles are enough:

• antivirus administrator (policies, deployment, updates);
• InfoSec specialist (incident control, reports, approval of exceptions);
• auditor (read-only and report extraction);
• backup responsible person (for vacations or incidents).

This closes responsibility questions in advance, ensures action logging in the console and readiness for inspections.

Asset accounting and license quantity calculation

Accurate license calculation in a closed environment begins with a clear asset list. If you miss even one device class (for example, test servers or VDI), you will quickly face “urgent purchases.”

First determine what the vendor counts as a licensable object: node, server, VM or session. In isolated networks it's often easiest to count by specific nodes because it's simple to reconcile with inventory.

Typically include desktop PCs and all-in-ones (including standby and spare units), physical servers and critical roles (AD, file, mail), virtual machines (if licensed per VM rather than per host), VDI and terminal farms (often counted by concurrent users or by hosts), test benches and sandboxes if they contain production data or have access to the environment.

Budget a reserve for growth and replacements. Often 10–20% is used, but tie it to planned changes: new workstations, server upgrades, pilot services. For example, if there are 50 workstations and 10 servers, and you replace 2–3 PCs quarterly, a reserve of 8–12 licenses looks reasonable.

Decide separately on temporary nodes and contractors. It's safer to keep a small license pool for laptops during work and record timeframes. Otherwise you can exceed limits unnoticed when an implementation team enters the environment.

Inventory should be simple but complete. Minimum fields: hostname, role (PC, server, VDI, test), location (site, rack, room), owner (department, responsible person), status (in service, spare, temporary, decommissioned).

Reporting for InfoSec and audit: what to collect in advance

In an air-gapped environment, antivirus is checked by traces: what is installed, how updates were applied, what was detected and who confirmed it. If you plan InfoSec reporting in advance, procurement and renewal discussions go more smoothly.

InfoSec usually asks four questions: is there protection, is it current, were there incidents, where are exceptions. To answer, regularly produce:

• coverage: how many nodes are managed, how many lack an agent, how many have errors;
• currency of databases and modules: versions, dates, percentage of devices overdue;
• incidents: detections, quarantines, operator actions, response time;
• exceptions: list, approver, expiry, reason;
• policy status: what is enabled and what is forbidden to change locally.

The main offline difficulty is proving update currency. A trio of artifacts usually works: package date, integrity check and transfer log. For each package record version number, export date, hash sums and who/when moved the media between zones. If using an offline repository, add a sync log and a list of nodes that successfully pulled the update.

Also agree who signs reports: administrator (prepares), system owner or head of InfoSec (approves), contour responsible person (confirms transfer and media storage). Store materials where changes are controlled. Set retention periods in the regulations.

Step-by-step: how to deploy antivirus in an air-gapped environment

In a closed network the most important thing is to describe the rules in advance: how updates are brought in, who has access to media, and when transfers and checks may be performed. Without this, even a good product becomes a set of “manual exceptions.”

A working sequence looks like this:

• fix the contour boundaries and restrictions: segments, node counts, critical servers, rules for USB/media, transfer schedule, journal requirements;
• choose the licensing model and accounting metric: by device, by user, by server, whether VMs and test benches are counted separately;
• deploy management and updates: administration console inside the environment, offline repository, route for transferring packages (e.g., via a dedicated workstation in a buffer zone with media checks);
• configure policies: protection levels, scan schedules, updates from local repository, exceptions only by request, admin and operator privileges;
• enable control: regular reports, alerts for outdated databases, disabled protection checks, periodic reconciliations “actual vs inventory.”

Start with a pilot on a small group (for example, 20–30 workstations and 2–3 servers) before scaling. In hospitals or production this reduces the risk of scans hitting peak hours and disrupting operations.

Deliverables should include artifacts easy to show to InfoSec and auditors: the update transfer scheme and responsible roles, asset registry and license counting rule, approved policies and exceptions, check schedules and criteria for “contour in norm,” report templates and log retention periods.

Typical mistakes during procurement and operation

A common error happens at procurement: licenses are bought “just enough” for current nodes. In a closed environment you almost always need spare workstations, temporary test servers, and a testbed for update verification. If reserve isn't included, you quickly reach “nowhere to install the agent” and security relies on workarounds.

A second problem is no owner for the update process. Updates are brought in “when possible,” and when they aren't, it becomes visible only at audit or after infection. In a closed network responsibility must be assigned by name with a calendar and proof of update events.

Another class of mistakes relates to media transfer: media aren't checked, imports aren't logged, and who brought what is not recorded. InfoSec then cannot prove the supply chain and can’t quickly determine where a failure occurred.

Temporary measures often become permanent: exceptions added for a specific application are never reviewed. After six months exceptions accumulate and effective coverage drops.

Finally, reports are assembled manually from different consoles and spreadsheets and numbers don't match reality. For example, the report shows 500 protected nodes but the inventory lists 540 and some machines haven't been updated for a long time.

A short checklist before purchase and in the first months of operation helps:

• include a license reserve and a separate test bench;
• assign an update owner and define checkpoints and deadlines;
• describe media rules: verification, logging, responsible persons;
• set an exception lifetime and review schedule;
• automate reports and reconciliation with the asset registry where possible.

If you build a closed environment turnkey, ask to see not only the installation diagram but how daily update control and the monthly InfoSec report will look. GSE.kz, for example, combines server production and integration services, which is convenient when aligning hardware, deployment and InfoSec requirements in one plan.

Short checklist before purchase or renewal

Before signing the invoice, gather inputs on one page. In an isolated network mistakes usually appear later: updates don't arrive, reports don't match, licenses are missing or remain on decommissioned nodes.

Check five things:

• license metric and object list: workstations, servers, VDI, terminal servers, test benches; how offline nodes and virtualization are counted;
• update regulations: source of databases, frequency of import, who delivers (IT) and who enforces (InfoSec), and what to do in emergencies;
• offline repository scheme and version storage: how many generations kept, where the reference copy is, how integrity is verified;
• minimum reports: coverage, database and engine currency, incidents, exceptions (auditors often focus on exceptions);
• logging requirements: which events are logged (updates, detections, protection disablement, policy changes), where they are stored and for how long, whether there is enough space and who has access.

A simple test: imagine InfoSec asks you in 15 minutes to show a list of all nodes with outdated databases and explain the reason. If it's unclear which report this comes from and who signs it, clarify conditions before renewal.

Next steps: how to formalize requirements and organize rollout

Start with a short but precise contour description. The spec should state which segments are isolated, how data can be transferred in (media, gateway, dedicated window), and restrictions on software installation and admin access.

Then formalize InfoSec requirements for control and evidence. Inspectors need to see that databases are updated per regulations, protection is enabled, incidents are not lost, and configuration changes are recorded. Define which reports are needed weekly and monthly and where they will be stored in the closed network.

To avoid surprises after purchase, ask the vendor in advance for offline-mode details: how they confirm updates without Internet (logs, database versions, package signatures), how licenses are counted in isolation (by nodes, servers, cores, term, reserve), what happens if the repository is temporarily unavailable, platform/database/resource requirements for the management console, and how reports and logs are exported for audit.

Before scaling, plan a pilot with measurable acceptance criteria: updates delivered within N minutes, no disruption to business applications, coverage report available, events logged and transfer process documented.

Also decide where to deploy the console and offline repository: dedicated servers inside the environment or separate roles, with backups and enough storage for update history. If you also need servers and closed infrastructure design, a system integrator can help. For example, GSE.kz combines server manufacturing and integration services, which is useful when tying hardware, deployment and InfoSec requirements into one plan.