42 Days to Detection, 24 Hours to Report: NIS2 and the Reality of OT Environments

Jaguar Land Rover lost five weeks of production and around £50 million a week when a ransomware attack in September 2025 shut down plants in the UK, Slovakia, and Brazil. The attackers never touched a single machine on the shop floor. They only had to encrypt the IT systems that carried production planning, component orders, and supplier communication. The lines stopped because without that data there was nothing to build and nothing to build it from. JLR at least knew immediately: production halted the same day. Most intrusions into industrial environments announce themselves far later, and that is where the reporting obligations under NIS2 become difficult in a way the text of the directive does not suggest.

Most manufacturers accept the point and still put the work off, because implementing NIS2 means inventorying hundreds of devices, rebuilding network architecture, and having a separate conversation with every vendor and integrator involved. This is not carelessness. It is a realistic estimate of effort, in which compliance loses to running production until it collides with a deadline or an incident.

In short: NIS2 asks for risk management, incident reporting, segmentation, supply chain security, and board-level accountability. Understanding the requirements takes an afternoon. The difficulty starts with the first device on the list: the controller supervising pasteurisation, running software the vendor stopped maintaining six years ago. It cannot be updated without vendor approval, integrator support, and a revalidation of the process, and that validation covers the parameters that determine whether the product is safe to eat. The next window for that work falls in November.

The regulation is not the difficult part

NIS2 sets out ten risk-management measures and a reporting cadence. Read them once and the intent is clear, because they are the same principles any security team would recognise. The complication is the environment they land in.

Corporate IT can patch a server on Tuesday evening, push an agent to every laptop, and retire unsupported hardware on a refresh cycle. A production environment offers none of those options on demand, which is why an IT security playbook applied directly to OT tends to stall in the first week: a network scan raises an alarm on a controller, an EDR agent blocks the control application, and a forced-update policy collides with equipment certification. The requirements are sound. Getting to them runs through changes to the plant’s architecture, and those belong to your digital manufacturing programme rather than to a separate compliance project running alongside production.

Five things that turn a requirement into an operational decision 

1. Devices that cannot be patched this quarter. The controller vendor has released the fix, but installing it means stopping the line, an OEM engineer on site, and a full regression test of the control logic. On validated equipment, add process requalification. Industrial hardware runs three to four times longer than IT hardware, so some vulnerabilities stay with you for years, whatever the patching policy says on paper. 

2. No single picture of what is connected. Controllers, industrial PCs, switches, HMIs, engineering stations, contractor laptops, remote service links. Few plants can produce one reliable list, because data from machines of different makes never reached a common place. That is why building an industrial connectivity layer and working on OT security keep turning out to be the same project. 

3. Maintenance windows that come once a quarter. The device carrying your most serious vulnerability may only be reachable during a planned shutdown. Until then the vulnerability exists, and someone has to consciously decide you are living with it. 

4. Distributed sites and vendor dependencies. Different plants, different integrators, different architectures, and OEM contracts that require remote access to keep warranties valid. 

5. Three teams that need each other. IT security and the CISO know what the directive requires. OT security knows how to deliver it inside a control system without creating operational risk. Automation engineers know the process. None of the three can size the risk alone, and IT security delivering OT security on its own produces measures the plant later works around. 

Another security technology will not solve these problems. What will help is visibility and a shared risk model. As long as security and maintenance are looking at two different lists of devices, every decision to patch, isolate, or replace is a negotiation without common data.

Start with understanding what is actually running

An OT asset inventory is not administrative housekeeping. It is the foundation everything else rests on. A useful inventory records what is connected, which process it supports, how critical that process is, how the device communicates, where IT and OT meet, who can reach it, and what happens if it stops. Compiling that by hand takes weeks and is out of date before it is finished. A usable inventory has to be maintained centrally, supported by automated discovery tools and by a policy that makes keeping it current someone’s responsibility. No tool will find everything, because the mix of device types, network designs, and undocumented connections is too varied for that, so the tooling closes most of the gap and the process closes the rest.

Without it, a vulnerability list is just a list. The same flaw on a test bench and on the station controlling the line that sets the pace of the whole plant are two different problems, and one maintenance window will only solve one of them. Which devices fall into the second category is visible in production data you already collect: OEE monitoring shows where downtime costs the most.

What follows: segmentation, monitoring, and a realistic patching policy

1. Segmentation limits how far an attacker can travel. According to the Dragos 2026 report, 81% of assessed industrial environments do not have it at an adequate level, making the move from the corporate network into control systems easier. It cannot be designed from an architecture diagram, because most plants carry undocumented connections accumulated over the years: a laptop bridging two zones, an ERP integration reaching further than anyone intended, a remote link added for a service visit in 2019 and never removed. Map the real traffic first. 

2. Monitoring tells you when normal behaviour changes, and the reporting timetable is why that matters. The NIS2 clock starts not at the breach, but when you become aware of one: 24 hours for an early warning, 72 hours for an impact assessment, one month for the final report. Put that next to the 42 days of undetected access the same report gives as the average ransomware dwell time in OT environments, and the problem becomes clear. Nothing in the directive is breached by those six weeks. The problem is what they leave you with: a period nobody was watching, so the evidence is missing, and the report comes down to reconstruction. If you already collect data from the plant, you are much closer than you think, because the reporting work turns into querying what you have rather than assembling it from scratch. If you collect nothing, you start from zero on the day the clock starts. And 42 days is the average, so plenty of cases run far longer. It is worth remembering that monitoring in OT has to be passive, because intrusive scanning and agents on legacy control systems create exactly the operational risk you were trying to avoid. 

3. Risk-based vulnerability management starts by accepting that not everything can be patched now, and by refusing to let that become an excuse. When the fix has to wait: 

• Restrict access. Control who can reach the device and from where. 

• Compensate at the network level. Tighter isolation of the device within the OT network, and hardening at the zone boundary. 

• Monitor it. Watch traffic to and from the device, so a change in its behaviour is visible. 

• Book the fix. Put the remediation into a shutdown that actually exists in the calendar. 

A supervisory authority is not looking for an empty patching report. It is looking for a documented, defensible risk decision. 

The technical detail behind all three is covered in NIS2 and OT Networks: What the Directive Really Means for Your Manufacturing Plant.

One workstation, two correct answers

An engineering workstation on the control network of a bottling line runs an unsupported version of Windows. The machine vendor connects to it remotely for diagnostics.

Security says: upgrade the OS, install protection, and cut the external connection.

Maintenance says: the control application is not validated on a newer OS, replacing the workstation needs vendor support and process requalification, an agent may interfere with the control software, and removing remote access means waiting for an engineer on site the next time the line stops.

Both are right about their own risk, and neither can decide alone. What resolves it is establishing how critical and how exposed the device is, cutting the connections it does not need, controlling and logging the vendor session, watching its traffic, and putting the replacement into the next planned maintenance window. That is compliance arriving as an operational risk decision rather than a parallel exercise imposed on the plant.

Someone still has to make that call. Under Article 20 the accountability sits with management, and in manufacturing that means OT security can no longer live entirely with IT or with the CISO.

Your deadline depends on where you manufacture

NIS2 is a directive, not a regulation, so the dates that apply to you come from your national transposition law.

Where you manufacture	What applies today
Germany	In force since 6 December 2025 with no transition period. The BSI registration deadline has passed and the BSI has moved from registering entities to auditing them.
Belgium	In force since October 2024. The first conformity deadline for essential entities passed in April 2026.
Italy	Phased rollout: incident reporting since January 2026, basic security measures due October 2026.
Netherlands	Cyberbeveiligingswet in force since 15 August 2026.
Austria	NISG adopted, applying from 1 October 2026.
France, Ireland, Spain	Still legislating. All three were referred to the CJEU in July 2026, with lump-sum and daily penalties requested.
UK, Norway, Switzerland	Outside NIS2, but meeting it through EU customers’ supply-chain obligations.

More than twenty countries are already enforcing. Full status by country, updated regularly. A group with plants in three countries is working to three different timetables, three registration routes, and three supervisory authorities, for the same directive. 

The question worth asking

The strongest programmes will not be the ones with the most policies, but the ones that leave the plant with better visibility, clear ownership of risk, and a real ability to contain disruption and recover from it. Getting there takes people who have commissioned controllers as well as people who have written security policy. That is how we work with clients at TT PSC: engineers who have connected and integrated plants across Europe, working alongside OT security specialists, assessing environments that cannot stop.

So, the useful question is not what you need to implement to comply with. It is what has to change in your operation so that resilience becomes part of how you run production. The answer starts with an honest assessment of where you stand, and that does not have to be a large project.