The camera watching the door is a better route into the network than the door. IP cameras, network video recorders, and access control systems now rank among the riskiest device types on enterprise networks, and the hardware installed to protect a site is a documented way into it.
This article does not claim that any connectivity product makes an organisation NIS2-compliant, and it does not tell you whether you are in scope. Risk documentation, incident response planning, staff training, supplier governance, CRA conformity assessment, and vulnerability reporting remain your responsibility throughout.
Forescout's Riskiest Connected Devices 2026 report, published in March 2026, ranks physical access control systems second among OT device types by risk, up from fourth the year before. Network video recorders topped its IoT ranking in 2025 and sat in fourth place in 2026. Forescout's researchers name routers and IP cameras specifically as devices ransomware operators use to gain a foothold.
The reasons are not exotic. Security devices run embedded firmware on long replacement cycles. Their management interfaces get less scrutiny than a server does. Default credentials survive commissioning more than anyone admits. Forescout also recorded Telnet exposure rising across most sectors it analysed, which tells you what kind of management access is still in the field.
Palo Alto Networks' 2025 Device Security Threat Report puts a figure on the wider problem: 21% of IoT devices carry at least one known vulnerability, and 48.2% of enterprise connections originate from devices the report classes as high-risk.
The most common pattern is a device reachable from the public internet. A camera on a public IP with a port forwarded for remote viewing is discoverable by anyone running a scan, and footage and alarm signalling cross infrastructure nobody in the chain controls.
The second is a flat network behind a private APN. Isolating traffic from the public internet is a real improvement, and it is also where most deployments stop. A private APN hides traffic but does not defend it. Every device inside it reaches every other device inside it, so one compromised camera reaches the NVR, the access controller, and whatever else shares the APN. We wrote about that gap in Why private APNs fall short for global industrial IoT.
The third is vendor VPNs stacked on top of each other. A site with cameras from one manufacturer, an access control system from another, and an intruder panel from a third ends up with 3 vendors needing remote access. VPN gives each of them a route onto the network instead of a route to their own equipment. One compromised vendor laptop is one compromised network.
Security devices need 4 distinct things. Treating them as one product is how gaps get missed.
The SIM identifies the device to the network. Identity starts at the point of attachment, not at the application.
IXT SecureNet routes device traffic through a private APN and dedicated tunnels directly to your systems or cloud environment, with static or dynamic private IPs, dual IPSec VPN tunnels, and direct connections to AWS, Azure, GCP, and Alibaba. Footage and alarm signals never touch the public internet.
Enforcement happens in the network and in the cloud, not on the SIM and not on the device. IXT Zero Trust delivers Zscaler ZTNA through the connectivity layer, so devices initiate outbound traffic only, no ports are exposed, and no client software goes on the camera. Illumio provides real-time traffic mapping across every IXT-connected device, automatic anomaly detection, and policy-based segmentation. Segmentation contains a compromise to a single device instead of letting it move across the estate.
The IXT CMP shows every SIM in real time, with session logs and API access. Traffic mapping and anomaly detection come from the Zero Trust layer, not from CMP.
Zero Trust is IXT's standard security offering. SecureNet on its own is the lighter option for deployments that choose not to take it.
Standard Zero Trust assumes an agent on the endpoint. A camera has no operating system worth the name, no spare memory, and no update path you control. The agent model breaks on first contact with the hardware.
Moving enforcement into the network removes that dependency. The device initiates outbound connections to a broker, the Zero Trust Exchange, which validates each session against policy before anything opens. No inbound ports. No listener. Nothing to scan. You cannot attack what you cannot see. There is more detail in What is Zero Trust for headless IoT devices.
Least privileged access is the operating principle. A camera reaches the video management system and nothing else. An access controller reaches its own management platform and nothing else. When one device is compromised, the blast radius is that device.
This is where most security estates leak.
Privileged Remote Access replaces the vendor VPN with a browser session. The engineer authenticates, gets a clientless SSH, VNC, or RDP session to one specific device, and the session is time-limited and recorded. Nothing is installed on the engineer's machine. Nothing is installed on the camera. No IP conflicts between vendor networks, because there is no vendor network.
An example from an adjacent market shows the shape of it. A European EV charging operator working with 8 hardware vendors needed each vendor to reach their own chargers without VPN conflicts and without network-wide access. Each vendor got a browser session, time-limited to business hours, session-recorded, brokered through the Zero Trust Exchange.
Swap chargers for cameras and the problem is the same one. How to grant OT vendor access without VPNs in 2026 walks through the mechanics.
The by-product matters as much as the control. You get a full audit trail of every device, every user, and every third-party contractor that accessed that device, and what actions they took. That record is what an auditor asks for. VPN-based vendor access does not produce it.
Whether a security operator or installer is directly in scope of NIS2 depends on the services it provides and how the directive has been transposed in its own jurisdiction. That is a question for your legal team, not for a connectivity vendor.
The indirect route is not in doubt. Clients in energy, transport, water, digital infrastructure, health, public administration, and manufacturing are in scope, and Article 21(2)(d) requires them to manage the security of their direct suppliers and service providers. If you install and remotely service devices on a regulated site, you are that supplier. The obligation reaches you through your client's audit, and it lands as a supplier security questionnaire with a deadline you did not set. The same dynamic plays out in other service markets, which we set out in Your vending fleet is a supply chain risk on someone else's NIS2 audit.
Article 21(2) contains 3 technical measures that land directly on the connectivity layer.
What it requires: controls over who and what reaches which systems.
Where IXT contributes: SIM-level device identity, per-session validation, and least privileged access so a device reaches one application and not a network.
What stays yours: your own identity governance, joiner and leaver processes, and the policy defining who is entitled to reach what.
What it requires: limiting the spread of a compromise.
Where IXT contributes: private routing that keeps device traffic off the public internet, plus policy-based segmentation and real-time traffic mapping that contain a breach to a single device.
What stays yours: segmentation of everything outside the IXT-connected estate. Traffic mapping covers IXT-connected devices only.
What it requires: managing security risk in supplier relationships.
Where IXT contributes: brokered, clientless, time-limited, session-recorded vendor access with a full audit trail per device and per
user.
What stays yours: the supplier governance framework, contractual security requirements, and vendor risk assessments.
Manufacturers of cameras, panels, and controllers sold into the EU carry a second obligation under the Cyber Resilience Act, which puts security requirements on the product itself. The full Article 21 mapping and the CRA picture are in IXT Zero Trust and EU compliance: NIS2 and the Cyber Resilience Act.
Being explicit here is worth more than another claim.
IXT Zero Trust is not a SIEM, a SOC, or an incident response function. It does not patch firmware and it does not manage devices. Illumio traffic mapping covers IXT-connected devices, so anything on another network stays invisible to it. Not every device type and protocol is supported without a technical assessment first. No connectivity product certifies NIS2 compliance, and any claim that a specific deployment meets Article 21 needs checking against your legal and compliance team's reading of the transposed national legislation in your jurisdiction.
IP cameras are considered high-risk because they run embedded firmware on long replacement cycles, ship with default credentials that survive commissioning, expose management interfaces that get little scrutiny, and sit on networks alongside more valuable systems. Forescout's 2026 Riskiest Connected Devices report names IP cameras and routers as devices ransomware operators use to gain a foothold, and ranks physical access control systems second among OT device types by risk.
A private APN removes external discovery and interception by keeping traffic off the public internet, and it does not secure the surveillance system on its own. It gives no segmentation between the devices inside it and no visibility into what each device communicates with. A private APN hides traffic but does not defend it. Segmentation, traffic mapping, and per-session enforcement need a Zero Trust layer on top.
Enforcement moves off the device and into the network. The device initiates outbound sessions to a broker that validates each one against policy before a connection opens, so no inbound ports are exposed and no software is installed on the camera. In IXT's model that means SIM identity, SecureNet private routing, and a Zero Trust layer enforced in the network and cloud.
Through brokered, clientless sessions scoped to individual devices, not a VPN onto the customer network. Privileged Remote Access gives a browser-based SSH, VNC, or RDP session, time-limited and recorded, with no client on the engineer's machine and none on the device. Each vendor reaches only their own equipment, and every session is logged against the device and the user.
That depends on the services the installer provides and on how NIS2 has been transposed in its jurisdiction, so it is a question for legal advice. The indirect obligation is clearer: clients in energy, transport, water, digital infrastructure, health, public administration, and manufacturing are in scope, and Article 21(2)(d) requires them to manage supplier and service provider risk. Installers servicing those sites answer for their security posture through the client contract.
SecureNet is private networking: a private APN, private IPs, dual IPSec tunnels, and direct cloud connections that keep device traffic off the public internet. Zero Trust is the enforcement and visibility layer: per-session validation through Zscaler ZTNA, real-time traffic mapping and policy-based segmentation through Illumio, and clientless privileged remote access. Zero Trust is IXT's standard security offering and runs on SecureNet underneath.
Session validation happens when a connection is established, not on every packet. Steady-state throughput for a given deployment depends on device type, bitrate, and destination, which a technical assessment establishes before rollout. Ask for the assessment before committing a video estate to any architecture, IXT's included.
Running several hundred security devices or more across sites in a regulated sector, with vendors needing remote access to them, is the point where the vendor access question lands on your desk before you go looking for it.
Book a meeting with IXT and we will map it against your own deployment.