Beyond traditional connectivity: managing smart products and machines in air-gapped and offline environments

Where connectivity ends, the challenge begins

Despite the ubiquity of connectivity, not every device operates with a stable, externally accessible internet connection. Many of the most critical, and by extension, most consequential, applications of smart IoT solutions work in environments where connectivity is intermittent at best, and absent at worst.

Today, smart machines operate in environments, at efficiencies, and in methods humans cannot. An autonomous drilling machine mines deep underground, hundreds of meters below the surface. An unmanned aerial system conducts surveys in a desolate desert. Smart monitoring systems watch for wildfires across remote mountain ranges. These are not edge cases; they are increasingly common deployment environments for some of the most advanced smart systems in the connected world.

Geography aside, smart machines also operate in industrial sites, offshore platforms, and at sea. Cellular or satellite coverage may be unreliable, and in some sectors, disconnection is a deliberate security strategy.

Air-gapped environments are standard practice in many sectors, including hospitals and critical infrastructure industries. Power generation, industrial automation, and defense operations often exist within air-gapped environments. An air-gapped system is physically or logically isolated from unsecured external networks. The logic is that a system cannot be externally compromised if the outside world cannot access it, and it cannot access the outside world. It is one of the oldest and most effective security postures in operational technology, predating modern cybersecurity frameworks by decades. Long before the first ransomware attack on an ICS network, industrial safety regulations demanded that control systems be isolated.

The air-gapped strategy has since been modernized and extended by today's practice of zero-trust security principles. Rather than assuming that anything within a network perimeter is safe by default, zero-trust demands verification of every device, connection, and update regardless of origin. In industrial and safety-critical contexts, zero-trust security strategies make authenticated, controlled software delivery an operational requirement.

Mining and heavy industrial operations, maritime and shipping, aerospace and defense, energy infrastructure, and hospitals – the need to manage smart machines beyond traditional connectivity impacts a wide range of industries. And, the operational reality is that these smart systems, which cannot reliably connect to an external server, still rely on software that must be kept up to date.

The growing stakes of software-defined machines

The case for deploying connected, intelligent machines in harsh and hazardous environments is compelling. Autonomous machines replace human workers in dangerous zones, preserving safety. For example, autonomous haulage systems in mining reduce site accidents by up to 50%.1 Self-driving vehicles and robotic drilling systems operate continuously without fatigue or shift changes. These statistics support the growth of autonomous systems in safety-critical environments. IoT spending across the mining sector alone is expected to grow from $5.8 billion in 2025 to $8.2 billion by 2027 — a compound annual growth rate of over 17%.2

The possibilities go even further. As artificial intelligence becomes embedded in these systems, the machines themselves can make better decisions: identifying where to drill based on geological data, optimizing energy use based on load, or predicting mechanical failures before they occur. The efficiency gains are real and measurable. Mining operations using autonomous equipment report productivity improvements of 15% to 30%, with some fully automated facilities operating around the clock at efficiency levels significantly higher than conventional sites.²

However, the potential value of smart machines rests on the quality and effectiveness of the software. The systems are only as smart as the software running on them. And software must evolve, continuously and without disruption.

Security vulnerabilities emerge. Performance improvements develop. Regulatory requirements change. AI models retrain. Unpatched vulnerabilities, for example, ultimately affect compliance and long-term performance. In 2025, the US Cybersecurity Infrastructure Security Agency (CISA) published a record 508 ICS/OT advisories, with an average CVSS severity score of 8.07 — the highest to date and indicative of the extent to which operational risk now resides in industrial device software.³ If the systems cannot receive updates, the gap between what the software should be and what it is grows wider over time.

This is a large-scale operational problem. And the problem compounds as smart systems grow in size and prominence across legacy industries that cannot afford to stand still.

Updating unreachable devices

Ultimately, how do you update a smart device without a persistent connection to your management server? This core challenge seems deceptively simple to state.

Waiting for the machine to come back online is one answer, but often an insufficient one. A vessel in port for 36 hours every two weeks,4 a drill rig surfaced once per annual maintenance cycle, a remote sensor that connects intermittently via satellite – in each case, the window for software updates is narrow, unpredictable, easily missed, and in some cases, impossible.

Manual updates carried out by a technician with a USB drive or laptop are a traditional option. But this approach breaks down quickly at scale. It is slow, inconsistent, and introduces its own security risks. A USB device brought into an air-gapped environment is one of the most common vectors for introducing malware into isolated systems. Manual processes also fail to maintain a reliable software inventory. Organizations that rely on manual processes often struggle to verify what version of software is running on which device at any given moment. Furthermore, a software bill of materials (SBOM) – which provides a record of software versions – is increasingly required for compulsory compliance mandates such as the EU Cyber Resilience Act (CRA).

The challenge expands further when security is factored into the equation. Even when a service window exists, organizations operating under zero-trust principles cannot simply update a device without first authenticating the update package, the device receiving it, and the delivery mechanism. An unauthenticated update is a potential attack vector. Within a zero-trust architecture, this is manageable. The update server may still be externally accessible; it simply requires that every element of the update process be verified before anything is delivered. Designed correctly, zero-trust and OTA updates are compatible.

Air-gapped and intermittent or no-connectivity environments, with or without zero-trust architecture, pose a different challenge. By definition, an external management server is not available or readily accessible, regardless of how robust the authentication model is. One common approach to managing devices in air-gapped environments is to deploy a dedicated update server within each isolated environment. Updates are applied, inventory is recorded, and everything stays within the network.

The security model holds, but the operational model fractures. An organization with multiple air-gapped sites now manages multiple independent software management servers, each holding a partial picture of the fleet. Each holds its own SBOM, update history, and compliance records. There is no single, unified view of what software is running across the operation, no consistent vulnerability tracking, and no centralized compliance record. Deploying updates this way is possible, but maintaining oversight becomes its own problem that scales poorly as the number of sites grows.

For teams responsible for the fleet-wide security posture, fragmentation is a serious problem. What organizations actually need is the ability to update devices within an air-gapped or disconnected environment and still surface that data — update status, software inventory, device state — into a single central server. Not separate systems per environment. One source of truth, regardless of where each device lives.

A smarter architecture for managing disconnected smart machines

The answer is not to force connectivity where it does not exist. It is to design a software management architecture that accounts for its absence.

The approach centers on creating a trusted intermediary that operates as the connection point between the offline device and the central update management server. The process begins at the device itself: the trusted intermediary connects locally, reads the device's identity, and impersonates the device. The trusted intermediary returns to the central management server existing in a connected environment, and acting as the device, authenticates with the server on the device's behalf. The server recognizes the device, determines that an update is available, and makes it ready for retrieval. The trusted intermediary pulls the update down — along with the verification metadata needed to confirm its integrity — and returns to the offline device to deliver the update. In the event the trusted intermediary is lost or stolen, the device trust can be revoked, losing its ability to reconnect to the central server.

During the update, the trusted intermediary records the outcome: what was installed, any inventory data the device reports, and a timestamped log of the process. When the trusted intermediary regains connectivity, it reports the software data to the central management server. The server receives a complete, auditable record of the update: who authorized it, what was delivered, and what the device's current state is — even though the device itself never connected directly.

Then the trusted intermediary repeats the process with the next offline device.

This architecture preserves the security properties that air-gapped and zero-trust environments require. Each device retains its own unique cryptographic identity. Updates are signed and verified before installation. The trusted intermediary authenticates each step as the device would behave if connected. Nothing is trusted implicitly, and no ports are opened unnecessarily. 

What this makes possible

Organizations must build authenticated, auditable update workflows that work within their security and connectivity constraints, not against them. When OEMs can reliably and securely update smart machines in disconnected environments, the operational benefits extend well beyond security patches.

Real-time visibility becomes achievable, even in intermittent connectivity and disconnected contexts. Organizations can maintain an accurate, current software inventory across their entire fleet, regardless of where each device is deployed or how often it connects to a network. Inventory is the foundation of effective vulnerability management; to put it simply, you cannot protect what you cannot see.

AI-driven capabilities stay up to date. The intelligent systems that optimize performance, predict equipment failures, or adapt to changing conditions can be continuously updated and improved, rather than frozen at the version that shipped with the hardware.

Security posture improves measurably. Rather than relying on manual processes or waiting for infrequent service windows, organizations can deliver authenticated, verified updates on a controlled schedule. The risk of unpatched vulnerabilities accumulating over time decreases. Compliance with industry standards and emerging regulations — including the EU CRA, which explicitly addresses software update obligations for connected systems — becomes easier to demonstrate and maintain.

Perhaps most importantly, the economics of operating smart machines improve. Less reliance on manual intervention, fewer costly service visits, and longer operational lifespans for systems that stay secure and perform optimally over time.

See how it works

To understand the technical implementation in depth — from API-based update retrieval and standalone client modes to inventory reporting and authentication flows — the full technical details are available on Mender Hub.

Explore the technical implementation on Mender Hub 

^Resources

1. ^{https://discoveryalert.com.au/revolutionizing-mining-autonomous-technologies-2025-safety-productivity/}
2. ^{https://www.globaldata.com/store/report/iot-in-mining-theme-analysis/#:~:text=According%20to%20a%20GlobalData%20ICT,use%20cases%20to%20remain%20competitive.}
3. ^{https://industrialcyber.co/threats-attacks/forescout-flags-spike-in-high-severity-ot-ics-flaws-exposing-visibility-gaps-that-leave-critical-infrastructure-at-risk/#:~:text=In%20the%20first%20full%20year,number%20jumps%20to%2082%25.%E2%80%9D}
4. ^{https://unctad.org/topic/transport-and-trade-logistics/review-of-maritime-transport}