NIS2 compliance checklist for OT networks – are your switches secure?

In 2026, the question “are our OT switches secure?” is no longer just a technical matter. For many organisations, it is now a question of NIS2 compliance, operational resilience and the ability to prove during an audit that industrial network security goes far beyond a default admin password and a few VLANs.

The NIS2 Directive establishes a common cybersecurity framework for critical and important sectors across the European Union and places stronger emphasis on risk management, accountability, incident reporting and supply chain security. In practice, this means OT environments must be assessed not only for availability and process continuity, but also for how well they are protected against cyber threats, misconfiguration and unauthorised access.

It is important to clarify one point at the start: NIS2 does not certify a single industrial switch as “NIS2 compliant”. The directive does not say that a particular model automatically makes your OT network compliant. What it requires is that organisations implement appropriate and proportionate technical, operational and organisational measures to manage risk, prevent incidents and reduce their impact. In other words, your switch is only one part of a larger cybersecurity posture that must be designed, maintained and documented properly.

This distinction matters even more in 2026, because alongside NIS2 the market is also preparing for the practical impact of the Cyber Resilience Act. While NIS2 focuses on the operator and the security of essential services, CRA is aimed more directly at manufacturers of products with digital elements. For OT buyers and system integrators, this means the evaluation of switches, routers and gateways should include not only current technical features, but also lifecycle support, vulnerability handling, firmware maintenance and vendor transparency.

What does NIS2 really mean for OT networks?

In OT, NIS2 means that network security can no longer be treated as an optional add-on to an automation project. The directive expects organisations to address risk assessment, incident handling, business continuity, backup strategies, secure acquisition and maintenance of systems, supply chain security, access control, cyber hygiene and the use of strong authentication where appropriate.

For industrial switches, this changes the purchasing and deployment logic. A switch should not be evaluated only by port count, PoE support, temperature range or DIN rail mounting. It should also be assessed for its role in network segmentation, secure administration, logging, firmware management, redundancy, configuration backup and the ability to support a defendable OT architecture.

NIS2 checklist for OT switches and industrial network infrastructure.

1. Do you have a complete inventory of switches and their role in the OT architecture?

The first compliance test is simple: do you know which switches you have, where they are installed, which firmware versions they run, who manages them and which network zones they connect? Without that, there is no reliable risk assessment, no meaningful monitoring and no realistic incident response plan. In OT, undocumented infrastructure is one of the fastest ways to lose control over both security and operational continuity.

2. Is there real segmentation between IT and OT?

One of the most common weaknesses in industrial environments is the illusion of separation. On paper, IT and OT may appear to be isolated, while in practice traffic still flows too freely between office systems, SCADA, remote access tools and industrial controllers. A secure OT switch should support an architecture in which segmentation is not theoretical, but enforced through VLAN design, ACLs, managed uplinks, monitored interconnections and clearly defined zones. In many environments, a proper OT DMZ is just as important as the switching hardware itself.

3. Is administrative access to switches restricted and accountable?

Shared administrator credentials, undocumented service accounts and permanent remote access are all serious red flags. For NIS2 readiness, administrative access should be limited to authorised personnel only, separated from standard user access and logged in a way that allows full accountability. Where justified, multi-factor authentication should be used for remote administration. A switch that can be managed by too many people, in too many ways, is not a secure OT asset.

4. Is remote access controlled, temporary and justified?

Integrators, maintenance teams and vendors often need remote access to industrial infrastructure, but this should never become an always-on backdoor into OT. Good practice is to make remote access temporary, approved, monitored and limited to the exact task required. Access should not bypass safety, change control or network segregation policies. In many audits, poorly governed remote access is one of the first areas that exposes weak OT security maturity.

5. Have you disabled unused ports, services and insecure management methods?

This is one of the simplest controls, but also one of the most frequently neglected. Unused switch ports, legacy services and weak management protocols increase the attack surface without adding operational value. In OT, every enabled service should have a reason to exist. If a port, web interface, discovery mechanism or management protocol is not required, it should be disabled after verifying that the change will not affect the process or the connected equipment.

6. Do your switches generate logs and does anyone actually review them?

Logging is not just a technical feature. It is evidence. If your switches do not record login attempts, configuration changes, reboots, port events or anomalies, you lose both visibility and traceability. Just as important, logs should be centralised, retained and reviewed. A security audit will not stop at the question “does the switch support syslog?” but will quickly move to “where do the logs go, how long are they stored and who analyses them?”

7. Do you have a safe firmware update and vulnerability management process?

OT does not work well with the simplistic rule “patch everything immediately.” Industrial environments need a controlled process: vulnerability identification, risk prioritisation, impact assessment, testing, maintenance windows, rollback planning and documentation. Secure switches are not just devices that can be updated; they are devices supported by a vendor with a clear policy for security advisories, patch availability and lifecycle communication. If no one knows when firmware was last updated or whether critical vulnerabilities were assessed, your OT network is exposed.

8. Are switch configurations backed up and recoverable?

Business continuity is a core part of NIS2, and for industrial switching infrastructure that means more than keeping spare hardware on a shelf. You should be able to restore configuration files quickly and reliably, including VLAN settings, ACLs, management parameters, redundancy settings and administrative controls. The real test is not whether a backup exists, but whether the organisation can restore a failed or compromised switch without improvisation during downtime.

9. Is redundancy in place where a switch failure would affect production or critical services?

In many OT networks, a single unmanaged point of failure can stop a production line, disconnect a building automation segment or interrupt an energy, water or process control function. Where availability is critical, redundancy should be designed into the switching layer through resilient topology, backup paths and failover planning. NIS2 is not only about preventing attacks; it is also about reducing the impact of failures and ensuring operational resilience under adverse conditions.

10. Do you assess vendor support, supply chain security and product lifecycle?

NIS2 explicitly highlights supply chain security, which makes vendor evaluation a compliance issue rather than just a purchasing preference. Before selecting industrial switches, organisations should ask practical questions: How long will firmware be supported? Does the vendor publish security advisories? Is there a responsible vulnerability disclosure process? Are software updates documented and accessible? A switch that looks technically strong today but has weak support and unclear product lifecycle policies may create long-term compliance and resilience problems.

11. Do you know when a switch-related OT incident must be escalated and reported?

NIS2 is not limited to preventive controls. It also introduces structured incident reporting. If a switch compromise, misconfiguration, outage or unauthorised access event has a significant impact on service continuity or security, the organisation must be able to classify the incident, escalate it internally and follow the required reporting path. That means your OT team, cybersecurity team and management must already know who decides, who documents and who communicates when a serious network incident occurs.

12. Does management understand OT cyber risk and take ownership of it?

One of the most important shifts under NIS2 is that cybersecurity is no longer treated as a technical side task delegated entirely to engineers or IT administrators. Leadership is expected to understand the risk, support the security programme and ensure that appropriate measures are implemented. In practice, this means decisions such as keeping obsolete, unsupported switches in a critical OT segment may become governance failures, not just engineering compromises.

Signs your OT switches are not yet ready for NIS2.

If your organisation does not have a reliable asset inventory, if IT and OT are only loosely separated, if shared admin accounts still exist, if remote access is permanent, if configuration backups are missing, if logs are not collected centrally or if industrial switches remain in service long after vendor support has ended, then your OT switching layer is not yet where it should be. That does not automatically mean formal non-compliance in a legal sense, but it does mean your ability to demonstrate appropriate and proportionate protection is much weaker.

What evidence should you prepare for an NIS2 audit?

In a real compliance review, declarations are never enough. You should be ready to show network zone diagrams, switch inventories with firmware versions, secure configuration standards, access control policies, remote access procedures, change logs, backup and restore procedures, incident escalation workflows, logging architecture and lifecycle decisions for legacy hardware. The stronger your evidence trail, the easier it becomes to prove that OT security is governed systematically rather than handled ad hoc.

Why this matters in 2026.

In 2026, OT cybersecurity is increasingly shaped by both regulation and operational pressure. Organisations are expected to move beyond general awareness and into measurable implementation. That means industrial switches should now be reviewed not only as network devices, but as security-relevant infrastructure components that must support segmentation, secure administration, observability, resilience and controlled lifecycle management.

The practical message is clear: NIS2 does not ask whether you bought a “secure switch” from a brochure. It asks whether your organisation can prove that the OT network has been designed, configured, maintained and governed in a way that is appropriate to the risk. A secure industrial switch, in this context, is one that supports the broader security architecture and is backed by documented processes, competent administration and operational discipline.

If you want to assess your OT switching infrastructure, industrial network segmentation or cybersecurity readiness for NIS2-driven projects, contact our team.