What this article covers, and what it does not claim
This article maps the technical measures in NIS2 Article 21(2) onto the connectivity layer of an IoT or OT estate. It sets out what the measure asks for, where a connectivity architecture contributes, and what stays with your organisation.
It does not claim that any connectivity product makes you NIS2-compliant. No product does. NIS2 is transposed into national law market by market, and the scope, thresholds and reporting duties that apply to your organisation are a legal question for your own compliance function. Read this as an architecture document, not as a compliance opinion.
The question your customers are already asking
If you operate EV charging, water, energy, transport, manufacturing or waste infrastructure in the EU, someone in your supply chain has sent you a security questionnaire in the last year. Somewhere in it is a question about network segmentation, and somewhere else a question about who has remote access to your devices and how that access is logged.
Those questions are hard to answer for IT and much harder to answer for IoT. Your laptops run an agent that reports on itself. Your chargers, meters, sensors and controllers do not. They have no operating system worth the name, no memory to spare, and no capacity to run a security client. If your evidence depends on device-side software, the estate that most concerns an auditor is the one you have least to say about.
NIS2 raises the stakes on that gap in two ways. It widens the sectors in scope, pulling in operators who were outside NIS1. And it places accountability at management level, so the answer to "who signed off on this risk" is a named person rather than a department.
Why IoT lands differently from IT
Three structural differences change what the same measure asks of you.
Devices cannot defend themselves. A headless device has no host firewall, no endpoint detection, and no way to flag its own anomalous behaviour. Every control has to be applied around it rather than on it.
The devices are physically exposed. A charger on a forecourt or a controller in a substation sits where anybody reaches it. Physical access to the unit becomes network access if the network path trusts the device by default.
Third parties operate the hardware. Hardware vendors, installers and maintenance contractors need access to their own units. In most estates that access arrives as a VPN credential into the network, which is exactly the supply chain risk NIS2 asks you to manage.
Article 21(2) measure by measure
Risk analysis and information system security policies
What the measure asks for. A documented view of the risks to your networks and information systems, with policies that respond to them.
Where connectivity contributes. An accurate inventory. You cannot assess risk across an estate you cannot enumerate. Real-time fleet data gives you every device, its status, its location and its traffic pattern as a factual input to the assessment rather than a spreadsheet maintained by hand.
What stays yours. The risk methodology, the assessment itself, the policy documents, and the sign-off. IXT contributes evidence, not judgement.
Incident handling
What the measure asks for. Detection, response and reporting of incidents, within reporting deadlines set by your national transposition.
Where connectivity contributes. Detection at the network layer.IXT Zero Trust Visualisation maps traffic across every connected device and flags anomalous behaviour, which for a headless estate is where detection has to happen. Real-time data matters here for a practical reason: most platforms report usage and status on a 24 to 48 hour delay, and a reporting deadline measured in hours does not survive a detection delay measured in days.
What stays yours. The incident response plan, the decision to declare an incident, the notification to your national authority, and the post-incident review. Zero Trust does not replace a SIEM, a SOC, or an on-call function.
Business continuity and crisis management
What the measure asks for. Backup management, disaster recovery, and continuity of the service you provide.
Where connectivity contributes. Connectivity resilience is part of service continuity when the service depends on remote devices. Multi-network access across 600+ mobile networks means a device is not tied to one operator's outage. A shared data pool means one device exhausting an allocation does not take a site offline. Private routing to your data centre or to AWS, Azure, GCP or Alibaba removes the public internet from the path your continuity depends on.
What stays yours. The continuity plan, the recovery time objectives, the backups, and the exercise programme that proves any of it works.
Supply chain security
What the measure asks for. Security in the relationships with your direct suppliers and service providers, including the access those suppliers hold.
Where connectivity contributes. This is the measure where the connectivity layer changes the answer most. Privileged Remote Access gives a vendor a browser session to one device, time-limited, recorded and co-viewable, initiated from the Zero Trust Exchange. No client to install on the vendor laptop, no IP conflicts between vendors, and no network access beyond the device they are there to service.
Consider an operator running eight hardware vendors across a charging estate. Under a VPN model, each vendor holds a credential into the network and the audit trail stops at the tunnel. Under session-level access, each vendor reaches their own units, and every action is attributable to a named person on a specific device at a specific time.
What stays yours. The supplier governance framework, contractual security requirements, vendor assessments, and the decision about which vendors get which access.
Security in acquisition, development and maintenance, including vulnerability handling
What the measure asks for. Security across the lifecycle of your systems, and a process for handling and disclosing vulnerabilities.
Where connectivity contributes. A reliable path for firmware and software updates. An update that does not complete is an unpatched device, and cross-border fleets fail updates for reasons that have nothing to do with your build pipeline: throttled roaming, a market that stopped accepting the SIM identity, a data allocation exhausted mid-download.
What stays yours. Secure development, the vulnerability handling process, coordinated disclosure, and the patches themselves.
Policies to assess the effectiveness of the measures
What the measure asks for. Evidence that your controls work, not a statement that you have them.
Where connectivity contributes. An audit trail of every device, every user and every third-party contractor that accessed a device, and what actions they took. Traffic maps show what the segmentation policy actually permits rather than what the policy document says it permits.
What stays yours. The assurance programme, internal audit, and the interpretation of what "effective" means for your risk appetite.
Cyber hygiene and training
What the measure asks for. Basic practices and security awareness across staff.
Where connectivity contributes. Very little, and claiming otherwise would be dishonest. Removing device-side clients and VPN credentials takes some human error out of the path. Training is yours.
Cryptography and encryption
What the measure asks for. Policies on the use of cryptography, and encryption where appropriate.
Where connectivity contributes. Private APN and network slicing keep device traffic off the public internet entirely, with IPSec tunnels to your environment where encrypted transit is required. A private APN hides traffic but does not defend it, so treat isolation and encryption as separate answers to separate questions.
What stays yours. Key management, application-layer encryption, and the cryptographic policy.
Human resources security, access control and asset management
What the measure asks for. Control over who and what reaches which systems.
Where connectivity contributes. Least privileged access at device level. The SIM identifies the device. SecureNet keeps the traffic off the public internet. The Zero Trust layer checks every session before a connection opens, and policy-based segmentation contains a compromised device rather than letting it move sideways across the fleet.
What stays yours. Identity governance for your staff, joiner and leaver processes, and asset ownership records.
Multi-factor authentication and secured communications
What the measure asks for. Multi-factor or continuous authentication, and secured voice, video and text communications.
Where connectivity contributes. Continuous authentication of sessions rather than one-time authentication of a tunnel. Every session is checked, and a device that authenticated an hour ago holds no standing trust.
What stays yours. MFA for your own workforce systems and your internal communications platforms.
What EV charging networks need in practice
Charging operators sit at the sharp end of this because the estate is geographically distributed, physically exposed, multi-vendor and, in most member states, in scope.
Four architectural requirements follow from the measures above. Chargers reach the back office and nothing else, so a compromised unit has nowhere to go. Vendor access happens per session and per device rather than per network. Traffic is visible in real time, because a distributed estate produces the anomalies you learn from. And the connectivity holds across borders without a technician, because a charger shipped to Poland or Turkey that loses its network becomes a site visit rather than a support ticket.
How this sits alongside the Cyber Resilience Act
NIS2 applies to you as an operator. The Cyber Resilience Act applies to the product you place on the market. If you manufacture the devices as well as operate them, both land on the same estate from different directions.
The overlap is useful rather than duplicative. Secure-by-default configuration, no exposed ports, a working update path and an auditable access model support CRA readiness and answer NIS2 measures at the same time. IXT supports manufacturers preparing for the Cyber Resilience Act. Conformity assessment, technical documentation and the vulnerability reporting process remain the manufacturer's obligations.
FAQ
Does NIS2 apply to us?
Scope is set by sector, size and the national transposition in each member state you operate in, and essential and important entities carry different duties. Your legal function answers this. Sector alone is not the test.
Does IXT Zero Trust make us NIS2-compliant?
No. IXT Zero Trust addresses NIS2 Article 21(2) technical controls: access control, network segmentation, incident detection, supply chain access, audit trail, and continuous authentication. Your compliance posture stays yours, including risk documentation, incident response plans, staff training and supplier governance.
Is a private APN enough for the segmentation measure?
A private APN isolates traffic from the public internet and leaves a flat network behind it, where every device reaches every other device. Segmentation in the sense the measure asks for means policy between devices, which needs an enforcement layer above the APN.
Our devices cannot run security software. What are our options?
Move enforcement off the device. Standard Zero Trust assumes an agent on the endpoint, which rules out most IoT hardware. Delivering Zero Trust through the SIM and the network puts the control where the device has no capability, with nothing to install on the hardware.
How do we give hardware vendors access without a VPN?
Session-level privileged remote access through a browser: time-limited, recorded, scoped to specific devices, initiated from inside your environment so no inbound port is exposed. That model also produces the attributable audit trail the effectiveness measure asks for.
What evidence will an auditor want about connectivity?
A device inventory that matches reality, an access log showing who reached which device and what they did, segmentation policy with proof of what it permits in practice, and a record of how connectivity incidents were detected and handled. Ask your provider which of those they produce as standard.
Where does responsibility sit between us and our connectivity provider?
Your provider supplies technical controls and the evidence they generate. You own risk assessment, policy, incident response, training, supplier governance and reporting. Any provider claiming more than that is selling you a compliance risk rather than reducing one.
Next step
Before including any of this in a tender response or compliance documentation, verify the claims against your legal and compliance team's interpretation of the transposed national legislation in your jurisdiction.
If you want to see what the controls look like on a real estate, ask us to walk through traffic mapping and vendor session access on a fleet like yours. Book a demo at ixt.io.
