NIS2 Directive Explained: Requirements, Scope, and Who Must Comply in 2026

The ever-expanding attack surface in critical infrastructure and industrial environments necessitates ongoing regulatory evolution. The original NIS Directive (Directive on Security of Network and Information Systems, adopted in 2016) was a ground-breaking step for cybersecurity in the European Union, but experience revealed its limitations. The NIS2 Directive—entering force in October 2024 with full compliance expected by 17 October 2026—represents both an evolution and an expansion, imposing stricter requirements on a wider range of organizations. This post provides a granular exploration of NIS2’s requirements, categorization of sectors, practical implications for IT and OT professionals, and notes on how compliance effort in 2026 will differ from its predecessor.

Historical Context: From NIS to NIS2

The original NIS Directive (EU 2016/1148) broke new ground by introducing binding cybersecurity requirements across operators of essential services (OES) and digital service providers (DSPs). However, it left loopholes: inconsistent application across EU countries, modest enforcement, and unclear sectoral scope—especially as the IT/OT convergence and digital transformation continued unimpeded.

NIS2 (EU 2022/2555) seeks to harmonize baseline security across the European market, responding to rising threats targeting everything from power grids to public administration. It expands the sectoral scope, tightens incident notification rules, and vests competent authorities with wider investigative and enforcement powers.

Quick Comparative Table: NIS vs. NIS2

Who Must Comply? Understanding Scope and Categorization

The NIS2 Directive has replaced the operator status concept with a more fine-grained approach, categorizing entities as either Essential Entities (EE) or Important Entities (IE). Compliance is no longer triggered solely by sector inclusion but also by size:

As a baseline: All entities with >250 employees and/or >€50m turnover in specific sectors are in scope—unless expanding sectoral inclusion applies, or special criticality/impact justifies inclusion for smaller entities.

Sectors (Expanded Under NIS2)

• Essential Sectors: energy, transport, banking, financial market infrastructures, health (including medical devices), drinking water, wastewater, digital infrastructure (including DNS service providers, TLD registries, cloud services), ICT service providers, space, public administration, critical manufacturing (chemical, food, medical device, machinery, electronics).

• Important Sectors: postal and courier, waste management, manufacture and distribution of chemicals, food production and processing, digital providers (online marketplaces, search engines, social platforms), research organizations.

The intention is for NIS2 to have direct impact on the smallest number of entities possible, while maximizing coverage. Exception: If an incident could cause significant societal or economic impact, smaller organizations can still fall within scope.

Key Takeaway for Network and OT Professionals

If your operation falls within one of the outlined sectors and meets the size threshold—or is explicitly designated as critical by national authorities—it is prudent to begin preparing for compliance now.

Core Security Requirements in NIS2

NIS2 pushes beyond abstract “appropriate and proportionate technical and organizational measures.” Articles 21 and 23 of the Directive make security duties prescriptive, with an eye on the practical realities of IT/OT architectures:

• Risk Analysis and Policies:

  Security programs must encompass documented risk assessment, regular review, clear security policies, and accountability at board level for cybersecurity posture. This is a shift: senior management can be held liable for failing to monitor and approve cyber risk procedure.

• Supply Chain Security:

  Critically, the Directive mandates real focus on supply chain management, extending to technology providers and managed services. Expect scrutiny of both IT and OT vendor risk management processes, contract language, and due diligence practices.

• Incident Handling:

  Entities must deploy robust incident detection and response mechanisms across both IT and OT infrastructures, with tested processes for incident classification, escalation, containment, and notification.

• Business Continuity:

  Disaster recovery, backup, and IT/OT system resilience (spanning energy loss, cyberattack, or supply chain disruption) require both planning and documentation.

• Minimum Technical Baselines:

  The Directive highlights cryptography, secure voice/data comms, access control, and asset inventory/tracking—including physical security perimeter protection. These echo well-known frameworks (e.g., IEC 62443, ISO/IEC 27001) but are now regulatory obligations.

Annotation: Why This Matters More for OT

In OT-heavy environments—think process automation, SCADA, distributed energy resources—NIS2’s language on asset inventory, access management, and incident detection raises the bar. Here, legacy gear, “air-gapped” fallacies, and minimal downtime windows collide with strict compliance mandates.

Network and IT/OT Architecture Implications

Asset and Network Segmentation

Deep asset identification and tight network segmentation, including zones and conduits (IEC 62443 style), become regulatory must-haves. This may require an upgrade from flat VLANs or ad hoc firewall rules to a formal zoning policy, with documented data flows and separation between business IT and industrial OT.

In practice, this means:

• Deploying next-generation firewalls and/or data diodes between enterprise and plant networks

• Enforcing least-privilege and just-in-time access to critical controllers and HMIs

• Implementing robust, monitored remote access tools for OT vendor/service access, replacing “dial-in” and RDP jump boxes with identity-aware proxies

• Maintaining a living inventory of ALL devices—networked or interfaced directly—across IT and OT (from PLCs to Windows workstations, HMIs, IIoT sensors, etc.)

Incident Reporting Architecture & Automation

Under NIS2, notification requirements are not optional and deadlines are tough. This points to:

• Automated incident detection and correlation across IT/OT (SIEM, EDR, NDR, and industrial anomaly detection platforms)

• SOC and OT-SOC collaboration procedures, with clear escalation workflows

• Tabletop exercises integrated into business continuity drills, including communication with authorities and partners

• Data collection and logging architectures capable of evidencing compliance post-incident

IT/OT Collaboration: A Regulatory Obligation

NIS2 effectively forces the hand of organizations that have historically maintained a fence between IT and OT. It is no longer viable to treat ICS and industrial infrastructure as “someone else’s problem.” Tangible steps include:

• Shared governance boards for cyber across IT/OT, including incident response integration and asset management harmonization

• Unified security policies—covering both Windows endpoints and programmable logic controllers, for example

• Joint vendor risk management and due diligence for all technology procurement, not just traditional IT purchases

Challenges in Deployment: What Will Be Hard?

• Legacy Technology and “Technical Debt”:

  Many OT systems predate modern authentication, encryption, and logging expectations. Re-engineering or risk-acceptance documentation (with clear compensating controls) must be addressed—not ignored.

• Asset Inventory Gaps:

  A frequent pain point: lack of centralized, up-to-date inventory of devices, firmware, and software—especially in segmented/disconnected OT environments.

• Supply Chain Complexity:

  Multi-tier vendors, inherited systems, and “shadow IT” complicate risk mapping. You cannot outsource liability under NIS2.

• Board-Level Accountability and Culture Change:

  NIS2 makes explicit demands at the executive/board level, not just the technical trenches. CISOs and network leads must raise the bar in reporting, documentation, and, most crucially, education of business leadership.

Honest Advice for 2024–2026 Compliance Preparation

• Don’t Underestimate Inventory Complexity:

  Industrial environments are notorious for rogue devices and “unknown unknowns.” Begin with asset discovery and network mapping—no compliance effort can succeed without it.

• Map Data Flows:

  Not just the “happy path,” but all inter-network and inter-organizational communications, including remote operators, vendor maintenance, and supply chain interfaces.

• Prioritize OT Segmentation:

  Treat the segmentation between business, IT, and production systems as a must. Even imperfect isolation buys time and reduces blast radius.

• Engage Legal and DPOs Early:

  NIS2 links with GDPR and other critical regulations. You may find overlaps and conflicting demands in incident reporting—a joint approach is essential.

• Practice, Don’t Just Document: Incident reporting, business continuity, and joint IT/OT tabletop drills matter. Competent authorities will expect evidence of practiced readiness, not shelf-ware documents.

Further Reading and Directives (For the Diligent Engineer)

• Full NIS2 Text (EU Official Journal)

• ENISA Guidance on NIS2 Implementation (ENISA NIS2 Portal)

• IEC 62443 Industrial Security Standards (IEC 62443 Overview)

• EU NIS 2 scope FAQs (EU Commission NIS2 Policies)

Summary

NIS2’s passage marks a firm turn in the regulatory evolution for industrial, public, and digital infrastructure operators in the EU. The bar is higher: more sectors, more entities, deeper prescriptiveness, and direct liability for leadership, not just IT departments. The technical challenges are surmountable with rigorous asset management, correct segmentation, and a culture of cross-domain collaboration. But the lazy “checklist” days are over—2026 is closer than it appears, and early action is the only reliable path to compliance (and, more importantly, resilience).