Always-on connectivity is often inherited rather than justified. A cable remains connected because installation was easy, a firewall rule remains open after commissioning, or occasional maintenance is treated as if it were a continuous business process. For critical systems, that default deserves review.
On-demand connectivity reverses the assumption. The path is unavailable during normal operation and created only for an approved purpose such as a backup, update, diagnostic session or controlled data exchange. This can reduce exposure, but only when the system can tolerate disconnection and the workflow remains usable under real operating conditions.
Key takeaways
The short version
- Connectivity should have an explicit business and technical purpose, not exist by default.
- On-demand access is best for predictable, low-frequency tasks with clear owners.
- The connection window needs authentication, restrictions, monitoring and a reliable close condition.
- Continuous telemetry and safety-critical communication require different patterns.
Challenge the always-on assumption
For each network path, ask what breaks if the connection is unavailable for an hour, a day or a week. Some paths carry essential real-time data. Others support a monthly service visit or an update that could be scheduled. Treating both categories alike creates avoidable reachability.
Measure actual use where possible. Flow logs, maintenance records and application owners can reveal connections that are idle most of the time. Confirm hidden dependencies before changing them, particularly name resolution, time services, licensing and monitoring.
Define the on-demand model
A connection window needs a trigger, authoriser, duration, permitted path and completion signal. The strongest design does not merely schedule a firewall rule; it verifies that the physical or logical state changed as intended and closes access when the task finishes or the maximum duration expires.
Different tasks may need different windows. A backup job can be automated and predictable, while vendor maintenance may require two-person approval. Document each use case instead of creating one broad button that exposes every protected system.
Security and operational benefits
Reducing connected time can reduce opportunities for scanning, exploitation and lateral movement across the controlled path. It can also improve governance by recording why and when a critical system became reachable. This evidence supports reviews and incident investigations.
The model can simplify the normal state: disconnected. Instead of maintaining a complex rule that must deny every unwanted flow, the network path is absent. During the connected state, however, normal complexity returns and must be managed with firewalls, identity, endpoint controls and monitoring.
Availability and usability tradeoffs
On-demand connectivity can delay urgent work if approval is slow or the control service is unavailable. It can also interrupt jobs when windows are too short. Design sensible defaults, warnings and emergency procedures, then test them with the technicians who will use the system.
Do not apply the model to a path whose interruption creates an unsafe condition or prevents required real-time control. One-way monitoring, replicated data, local operations or resilient store-and-forward designs may reduce connectivity without creating operational fragility.
Implementing a physical connection window
AIRGAPNET is designed to place a hardware-enforced state in an Ethernet path: physically interrupted by default and connected for an authorised period. A separate cellular channel controls that state independently from the protected Ethernet network.
Deployment still begins with architecture. Identify the exact cable path, ensure there are no bypass routes, define users and approval, and apply traffic restrictions while connected. The device makes the physical state enforceable; the surrounding process determines whether the access is appropriate.
Define operating measures before automation
Choose measures that show whether the model is working: total connected hours, windows opened outside schedule, extensions, failed jobs, emergency access and attempts to bypass the boundary. Review them with both security and operations. A falling exposure window is useful only if required tasks still complete reliably.
Set notification thresholds for connections that remain active near their maximum duration and require a reason for extension. Confirm closure through the observed physical state. Periodically compare authorised windows with network telemetry so a cabling change, secondary interface or unmanaged access point does not silently defeat the intended boundary.
Finally, assign service ownership. Someone must maintain accounts, replace hardware, test alerts and update the model when business needs change. Disconnected by default should be a managed operating state, not a one-time installation choice.
Report both security and service outcomes. Connecting hours, successful jobs, delayed tasks and emergency openings reveal whether the design is reducing reachability without shifting unacceptable cost or downtime to operations. Adjust the window design when those outcomes diverge.
Decision checklist
Questions to resolve before implementation
- Measure how often each critical-system connection is genuinely used.
- Identify real-time, safety, licensing and monitoring dependencies.
- Define separate windows and permissions for each maintenance or transfer task.
- Set a maximum duration and a verifiable closing condition.
- Protect the connected state with segmentation, identity and monitoring.
- Test normal, failed and emergency access with operational staff.
Common questions
Questions teams ask first
Does a shorter connection window automatically mean lower risk?
It reduces time available through that path, but risk also depends on exposed services, endpoint state, privileges and alternate routes. A compromised endpoint may act quickly, so connected-state controls remain essential.
Can on-demand connectivity be automated?
Yes, for predictable jobs with strong controls and reliable completion checks. Higher-risk maintenance may require explicit human approval. Automation should not allow the protected network to authorise its own exposure without an independent trust decision.
Which systems are poor candidates?
Systems requiring continuous control, safety communication, high-frequency replication or real-time telemetry may not tolerate a disconnected path. Consider segmentation, one-way transfer or local processing instead.
Official references