Skip to main content
AirGapNetPhysical network isolation
← BlogField notesDecember 20256 min read

OT maintenance windows: closing is the hard part

Opening a maintenance window is easy. Closing it on time, every time, is the part incidents are made of. The pattern where the close runs on a timer, not on an operator remembering.

The hard part of maintenance windows is not opening them — it is closing them. The pattern that works is the one where the close happens without an operator action.

Section 01

Why 'close' is the hard step

Open is easy. There is a clear trigger — a vendor needs access, a backup job needs to start, a patch needs to deploy. The trigger arrives, someone opens the path, work happens.

Close is hard. The trigger that closed the maintenance window in theory — work finished, ticket resolved, vendor confirmed disconnect — is not a hard signal. It is a soft signal that someone has to act on. In retrospectives, the gap between the work ending and the path being closed is where most of the residual exposure lives.

Section 02

The pattern that works

The operational pattern that survives is one where the close is a property of the open command, not a follow-up action. The window has a duration when it opens. The relay's own timer counts down. When the timer expires, the line is mechanically broken — there is no operator step in between.

This means the open command needs to commit to a duration. 90 minutes for a routine vendor service call. Six hours for a quarterly maintenance day. Two hours for the nightly backup window. The exact numbers depend on the path; the design is that the number is fixed at open time, not negotiated at close time.

  • Ticket → schedule

    The maintenance request becomes a calendar entry with a committed duration before the window opens.

  • Schedule → SMS

    At the scheduled time, the scheduler emits the SMS that opens the relay for the documented duration.

  • Relay → log

    The relay records open, the elapsed time, and the close. The log is the auditable artefact.

  • Close happens regardless

    The timer expires whether the work finished or not. If it did not, schedule another window — do not extend the existing one in-band.

Section 03

What a week at a real site looks like

A typical mid-sized OT site running this pattern has somewhere between 5 and 15 controlled lines. Each line has its own schedule. A backup-target line opens nightly at 22:00 for 90 minutes. A vendor maintenance line for a PLC opens on the 1st Tuesday of the month for 6 hours. An update channel to a controller opens during the monthly patch window. An emergency line for one critical pump opens on-demand by the on-call operator's SMS, with a 2-hour cap.

Across all of these, the operator's interaction is the open command and the schedule definition. The close runs on the device. The auditor reads the device log against the schedule definition. The retrospective questions become 'was the schedule correct' rather than 'was the path cleaned up'.

Section 04

Where the pattern needs care

Two operational considerations. First, scheduling drift — if the routine vendor work is taking longer than the scheduled 90 minutes, the right response is to lengthen the schedule, not to extend the window in-band. Letting operators learn to call the relay-open during work normalises the soft close.

Second, emergency windows. Real environments need a way to open a maintenance window outside of schedule for genuinely urgent work. The right shape is a documented procedure that opens a time-capped emergency window — same physical mechanism, just initiated by the on-call's SMS instead of the scheduler. The log records the emergency open the same way it records a scheduled one.

Go from reading to running

See AirGapNet on your network.

We bring a real AGN1 to your bench and run one maintenance window on your equipment. 30 minutes on the call.