Most organizations working toward NIS2 compliance have done the obvious things. They've updated their IT security policies. They've reviewed access controls for user accounts. They've briefed their boards on the new executive accountability requirements.
What they haven't done is look at the SIM cards running inside their industrial sensors, remote monitoring units, and OT devices in the field.
That oversight is exactly where compliance programs fail. And it's exactly where regulators will look next.
NIS2 expanded the scope of cybersecurity obligations significantly. It now covers operators of essential services across energy, transport, manufacturing, health, water, and digital infrastructure. For those organizations, the directive requires proportionate technical and organizational security measures across all network and information systems that support critical services.
That phrase matters: all network and information systems.
Your IoT and OT devices are network systems. The SIM-based cellular connections they run on are network infrastructure. If those devices handle operational data, connect to control systems, or enable third-party access to your facilities, they fall within scope.
NIS2 requires organizations to be able to do four things for every system in scope:
prevent incidents, detect anomalies, limit the impact of compromises, and demonstrate control. Most IoT and OT environments fail on all four.
Here's the myth: if your devices connect over a private APN or a VPN, you're covered. It sounds reasonable. Your devices are off the public internet. Traffic is isolated. What's the risk?
Marius Holmsen, CTO of Shift Security, puts it plainly:
"We need to stop assuming anything is secure, whether inside or outside the network. Every device, every connection must be validated."
That's the gap. APN and VPN isolate traffic. They don't show you what devices are doing inside that isolation. They don't limit the blast radius when one device or one credential is compromised. They don't give you an audit trail that proves you had control.
NIS2 doesn't require isolation. It requires demonstrable control. Those are different things.
The challenge with IoT and OT environments is structural. These devices weren't designed with security architecture in mind. Most of them are headless. They run no agent software. They operate in environments where adding client-side security tools isn't viable.
Traditional Zero Trust approaches were built for IT. They require endpoint agents. They assume the devices connecting to the network are computers running modern operating systems. A pressure sensor or a remote terminal unit doesn't qualify.
So organizations face a choice: accept that their IoT and OT devices are outside their security perimeter, or find an architecture that closes that gap without requiring changes to the devices themselves.
That gap is where most NIS2 compliance programs currently sit: IoT and OT devices acknowledged as in-scope, but not meaningfully secured.
The architectural answer is to enforce Zero Trust at the network level, not at the device level. Instead of installing security software on each device, the network itself enforces the controls.
This means every device communicates only through a private infrastructure where all traffic is inspected. No ports are exposed inward. Traffic is device-initiated only. There is no inbound attack surface by design.
Privileged Remote Access replaces the VPN for third-party vendors and service technicians. Instead of distributing VPN credentials that grant broad network access, technicians authenticate through a browser-based portal and reach only the specific equipment they're authorized to access, for a defined window of time. Sessions are recorded. Co-viewing is available. No VPN client needs to be installed or managed on the vendor side.
Traffic mapping gives you real-time visibility into what every device is communicating with. Green lines show normal communication patterns. Anomaly alerts fire when a device starts talking to an unexpected destination.
When a device in a water treatment facility starts sending data somewhere it never has before, you know within minutes, not days. This is the architecture NIS2 requires. Not more complexity, better control.
NIS2 places accountability at the executive level. This isn't a technical compliance task that IT and security teams own independently. Directors and senior management are now personally accountable for ensuring their organization meets its obligations, including breach notification within 24 hours of a significant incident.
That accountability changes the conversation. When a CTO or CIO asks whether IoT devices are within scope of NIS2, the answer isn't a technical judgment call. It's a governance question with legal weight behind it.
As Henning Solberg, CTO of IXT, puts it:
"IoT is not experimental anymore. It is infrastructure. Regulators have caught up to what the industry knew years ago. Infrastructure needs real protection."
The organizations getting this right are those where technical and executive teams are aligned on what systems are in scope, what controls are in place, and what the audit trail looks like if they're ever asked to demonstrate compliance.
Most IoT environments aren't ready for that conversation yet.
If your organization experienced an incident through a connected IoT or OT device tomorrow, what would your audit trail show?
What evidence do you have that you were monitoring device behavior, controlling third-party access, and limiting the blast radius if something went wrong?
If the honest answer is "not much," that's the gap NIS2 is designed to address, and the gap that Zero Trust architecture closes.
Go Deeper in our webinar We're running a webinar specifically for technical and compliance leaders who need to close the IoT and OT security gap under NIS2. We'll cover how Zero Trust architecture maps to NIS2 requirements, what privileged remote access looks like in practice, and how organizations in energy, manufacturing, and critical infrastructure are approaching this now.