You cannot patch a tunnel the way you patch a web server
Speed is a major objective in conventional IT security patching. Detect, test, deploy, move on, and put mean time to patch on a slide at the end of the quarter.
Control systems change the arithmetic. The vulnerability still matters. So does the chance that fixing it drops the operator interface mid-shift. In a live tunnel control environment, the consequence and the recovery constraints are very different from those of a typical web estate.
What sits behind the operator interface
We integrated the supervisory and control systems for the M85 Vienna-hill (Bécsi-domb) tunnel complex in Hungary, commissioned in December 2024. Fourteen subsystems sit behind a single operator interface: fire detection, ventilation, lighting, traffic control, video, emergency communication, energy monitoring, uninterruptible power and the rest.
Consolidating them is the point of the platform. It is also what makes a restart expensive. Lose that interface mid-shift and the operator loses the ability to see and act across every subsystem at once, while traffic keeps moving through a tunnel that will not wait for a service to come back up.
There is a standard for exactly this problem
Patching operational technology has its own document in the IEC 62443 series. IEC TR 62443-2-3:2015, Patch management in the IACS environment, was published by IEC technical committee 65 and addresses patch-management responsibilities for both IACS asset owners and product suppliers.
It is specific: responsibilities on both sides, a defined lifecycle state model for a patch, and a recommended format for exchanging patch information between product suppliers and asset owners. It also addresses how patch management can affect the reliability and operability of the control system.
So patching in this environment is a documented discipline with a shape somebody has already agreed. A supplier should be able to explain what patch information they provide, when they provide it, and what they expect the asset owner to do with it.
What happens before a patch exists
The scope notes in IEC TR 62443-2-3 carry the line that matters most.
The report does not provide guidance on mitigation during the period between discovery of a vulnerability and creation of the patch that resolves it. Instead, it points to compensating countermeasures elsewhere in the patch-management and IACS security framework. The annexes it points to cover backup and restoration infrastructure, product-supplier procurement guidelines and security hardening.
That period is where the operational problem starts. Disclosure may arrive before a deployable patch exists; the supplier then needs time to produce and validate a patch for the supported configuration, and the operator still has to schedule deployment. The exposure window opens before the patch does.
A tender should ask what the architecture does during that period, and who records the decision to carry the residual risk in the meantime. How quickly patches arrive is the easier half of the question.
Windows are scarcer than engineering hours
Ask how long a patch takes to apply and the answer comes back in hours. Applying it across an estate runs on a different clock.
Every change needs a window agreed with the operator, and windows on live infrastructure are scarce, seasonal and contested by other work. We made the same point about cryptographic migration. The UK NCSC guidance for post-quantum migration tells organisations with operational technology or extensive physical infrastructure to pay particular attention to constraints imposed by infrequent replacement cycles, and to align physical-infrastructure changes with other maintenance and improvement work where possible.
So count them. The number of usable windows between now and the end of your compliance horizon is knowable, and it can become a binding schedule constraint for any programme that touches the live control layer.
What one change actually requires
A patch on a tunnel control system never travels alone.
It needs a maintenance window agreed with the operator, with the tunnel held in a defined state throughout. A rollback path someone has actually run, rather than a paragraph describing one. A safety impact assessment where the change can affect safety-relevant functions, covering what it touches and what it must leave unchanged. Verification afterwards that the system is running what it is supposed to be running, which is a separate exercise from having deployed it. Then an auditor can follow a record months later.
IEC TR 62443-2-3 expects much of this discipline. Its asset-owner guidance calls for patch testing that reflects the production environment closely enough to establish that reliability and operability will not be adversely affected. It also calls for authorised patches to be scheduled within the constraints of system design, including redundancy, fault tolerance and safety, and operational requirements such as planned or unplanned outages.
Most of that has appeared here before, in verifying deployed configuration against the approved baseline and who may change what, and how it is recorded. A security patch inherits all of it and adds external urgency: disclosure, exploitation and supplier advisories can force a change schedule to react to events the organisation does not control.
What an audit examines
For road authorities responsible for traffic management control and operators of Intelligent Transport Systems that fall within its scope, NIS2 brings cybersecurity risk-management and incident-reporting obligations.
You do not discharge obligations of this kind by buying a product. You discharge them by showing operational discipline: who approved the change, what was tested, how it could be reversed, what evidence survives. A software inventory shows what may need patching. The change record shows how the organisation controls what happens next.
The question worth asking a supplier
Ask about the last vulnerability that hit a system like yours. Most suppliers have a patch policy, and it will read well. What you want is the instance: when the disclosure arrived, what they did before a patch existed, how long the patch itself took, what the customer had to arrange, and what the record looks like today.
A real example should produce dates, decisions, mitigations and evidence. A patch policy on its own cannot show how the process behaves under pressure.
Lillyneir designs, integrates and maintains tunnel supervisory and control systems for motorway operators and road authorities, including the M85 Vienna-hill (Bécsi-domb) tunnel complex in Hungary. If you are scoping the patch and change regime for a control estate, we are glad to walk through how it works in practice.
