A permanent air gap is the strongest form of isolation and also the hardest to live with. Real operations need to move data, run backups, apply updates and support devices, and each of those needs reintroduces connectivity.
Scheduled network disconnection keeps the asset disconnected by default and reconnects it only for defined windows. The asset is reachable when it must be and physically separated the rest of the time, which shrinks the attack window to the few periods that are actually needed.
01Key takeaways
- 01
A permanent air gap maximizes isolation but is operationally costly; a time-based air gap keeps most of the benefit while remaining workable.
- 02
Disconnection can be scheduled, on-demand or event-triggered, depending on the workflow.
- 03
Controlling the disconnect through an out-of-band channel keeps the control path off the network being protected.
- 04
Time-based disconnection fits backups, out-of-band management and maintenance windows particularly well.
- 05
Auditability matters: every connect and disconnect should be logged so the operating model can be proven.
02Permanent air gap vs time-based disconnection
A permanent air gap means a system is never connected to other networks. It is powerful, but it forces every data exchange into manual processes, which is why true air gaps are rare outside high-assurance environments and why even those are often eroded over time.
Time-based disconnection accepts that an asset needs occasional connectivity and controls when that connectivity exists. Instead of choosing between always-on and never-on, the asset is offline by default and online only for approved windows.
The shift is from "isolated forever" to "disconnected by default, connected on purpose."
03Three models: scheduled, on-demand, event-triggered
- Scheduled
- The asset connects on a fixed schedule, for example a nightly backup window, and disconnects automatically afterward.
- On-demand
- An operator opens a connection for a specific approved task, such as maintenance, and closes it when the task is complete.
- Event-triggered
- A defined event opens or closes the connection, allowing connectivity to follow operational conditions rather than the clock.
Most environments use a mix. Backups suit a schedule, vendor maintenance suits on-demand, and certain operational flows suit event-triggered control.
04Why the control path should be out-of-band
If the mechanism that connects and disconnects an asset is reachable over the same network being protected, it becomes a target. An attacker who can reach the control plane can simply tell the asset to stay connected.
Keeping the control channel out-of-band addresses this. An AIRGAPNET controlled disconnection device drives a physical Ethernet break through an independent channel, so the decision to connect or disconnect does not depend on, and is not reachable from, the production network.
The principle is general: the path that enforces disconnection should not be exposed to the systems it is protecting.
05Where time-based disconnection fits
- Backup repositories that should receive data only during the backup window and be physically unreachable otherwise.
- Out-of-band management interfaces that are needed occasionally but dangerous when always reachable.
- Maintenance and update endpoints that should be online only for the duration of a planned task.
- Critical devices that need intermittent data exchange but no continuous connectivity.
- Segments that must be demonstrably offline outside defined operating periods.
06Auditability and proving the model
A disconnection model is only as credible as the evidence behind it. Each connect and disconnect should produce a record that can be tied to a reason and an approver.
- Log every connect and disconnect with a timestamp and the triggering schedule, task or event.
- Tie connection windows to approved tickets so connectivity always has a documented reason.
- Make the disconnected state verifiable, not assumed, so audits can confirm it physically held.
- Review the logs to confirm that windows match policy and that no window stayed open longer than intended.
07What time-based disconnection does not do
- It does not protect the asset during the windows it is connected; other controls still apply then.
- It does not help with assets that genuinely need continuous real-time connectivity.
- It does not replace segmentation, patching, identity or monitoring.
- It does not secure removable media or local physical access.
Its value is specific: it removes the hours of exposure that exist only because disconnecting was inconvenient.
08Closing thought
Time-based disconnection takes the core idea of an air gap and makes it operable. The asset is separated by default and connected only when there is a reason, which is exactly the behavior most teams want but rarely achieve with manual process alone.
Decide which assets do not need to be online continuously, choose the disconnection model that fits each workflow, and keep the control path out of band. The attack window shrinks to the windows you actually use.
FAQFrequently asked questions
What is scheduled network disconnection?
Scheduled network disconnection keeps an asset physically disconnected by default and reconnects it only for defined windows, such as a nightly backup. The asset is reachable when needed and separated the rest of the time.
How is a time-based air gap different from a permanent air gap?
A permanent air gap is never connected, which maximizes isolation but forces all data exchange into manual processes. A time-based air gap is offline by default and online only for approved windows, keeping most of the benefit while remaining operable.
Why should the disconnection control be out-of-band?
If the connect and disconnect mechanism is reachable over the protected network, an attacker who reaches it can keep the asset connected. An out-of-band control channel keeps that decision off the network being protected.
What workflows suit time-based disconnection?
Backups suit a fixed schedule, vendor maintenance suits on-demand connection, and certain operational flows suit event-triggered control. Out-of-band management interfaces and update endpoints are also good candidates.
Does scheduled disconnection replace other controls?
No. It does not protect the asset during connected windows and does not replace segmentation, patching, identity or monitoring. It removes exposure that exists only because disconnecting manually was inconvenient.
SRCSources of record
Disconnected by default
Connect on purpose, not by habit.
Keep high-consequence assets physically disconnected by default and reconnect them only for approved windows, with the control path kept out of band.