NIS2 Compliance: A Practical Guide to Meeting Article 21 Security Obligations
Ensure NIS2 Article 21 compliance with our practical industrial cybersecurity guide. Learn risk assessment, network segmentation, incident handling, and more.
📖 Estimated Reading Time: 3 minutes
Article
NIS2 Compliance: A Practical Guide to Meeting Article 21 Security Obligations
The NIS2 Directive—formally, the EU Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union—introduces updated and expanded obligations for operators and digital service providers in essential and important sectors. Article 21 stands as the technical and operational cornerstone, requiring organizations to implement a comprehensive set of cybersecurity measures. The practicalities of “putting NIS2 Article 21 into action” go far beyond a new suite of policies or an annual Pentest report. For CISOs, IT Directors, and hands-on engineers in industrial contexts, NIS2 is likely a watershed in how security, visibility, and resilience are achieved—not merely legislated.
Historical Context: NIS1 to NIS2 and the Expanding OT-IT Frontier
The original NIS Directive (2016/1148/EU) was primarily focused on operators of essential services—think energy, transport, water, and health. Its implementation trajectory, however, revealed fragmentation: inconsistent adoption, widely varying definitions of “essential”, disparate reporting requirements, and—critically—an underwhelming impact on the Operational Technology (OT) that underpins European industry.
NIS2 explicitly addresses these deficiencies. It covers a broader scope of sectors, brings in more rigorous supply chain scrutiny, and raises the bar on reporting, security controls, and risk management. For practitioners in industrial and critical environments, this shift means the OT “island” is—by regulation—now subject to the same rigor as IT, even as the two technical domains famously differ in priorities and tolerances.
Dissecting Article 21: The Core Security Obligations
Article 21 is less about precise technical specification (“use this technology”) and more about outcome-oriented requirements. Among the obligations, the following preside:
Risk analysis and information system security policies
Incident handling
Business continuity, such as backup management and disaster recovery
Supply chain security
Security in network and information systems acquisition, development, and maintenance
Policies and procedures to assess the effectiveness of measures
Use of cryptography and encryption
In essence: if you touch critical infrastructure, you’re now obligated to deploy a fit-for-purpose, evolving security program. Let’s explore what that means in the real world.
The Realities of Article 21 in Industrial Settings
Risk Analysis in "Brownfield" Environments: Older industrial plants typically sport networks that “just grew”—Bolted-on PLCs, proprietary fieldbuses, and direct serial links that were never designed with IP threats in mind. Running a meaningful risk analysis (not just a perfunctory Excel sheet) requires asset discovery and segmentation—often for the first time. Tools such as passive network monitoring (a technology tracing its roots to the early days of IDS systems like Snort, but now tailored for ICS protocols such as Modbus or DNP3) are essential here.
Incident Handling: Beyond the SOC: While IT may boast mature Security Operations Centers weaving together SIEM, SOAR, and endpoint protection telemetry, OT typically lacks even basic logging, let alone centralized detection. Bridging this gap remains technical (can the RTU speak syslog?) and operational (engineers distrust noisy alerts). A pragmatic practice: Adopt a “minimum viable SOC” model in OT—start by centralizing event logs from gateways, edge firewalls, and domain controllers in environments where possible.
Business Continuity and Disaster Recovery: In enterprise IT, restore-from-backup is a daily occurrence. In OT, many operators have never, or very rarely, tested the restoration of PLC programming or SCADA configuration. Worst-case: backups sit unverified on deprecated hardware. The NIS2 mandate means regular, formalized testing—including downtime scenarios, staged failovers, and artifact integrity checks. For many, this requires a culture shift.
Supply Chain Security: Practical Scrutiny: It’s not unusual for OT vendors to ship systems running years-old operating systems, with patching governed by warranty agreements instead of CVE feeds. Under NIS2, organizations are accountable not just for first-party assets, but also for the vulnerabilities, processes, and configurations their suppliers inherit and operate. Contracts must be tightened; SLA metrics should integrate security patch responsiveness as part of ongoing vendor qualification.
Lifecycle Security in Acquisitions, Development, Maintenance: Decades ago, “security by obscurity” was tacitly believed to suffice at Layer 1 or 2 of industrial networks. Today’s attackers know better. All new systems—whether PLCs, RTUs, or network control centers—require threat modeling, secure-by-default configurations (no more ‘admin:admin’), and routine hardening during their operational lifetime. A practical starting point is adopting the IEC 62443 family of standards for secure development and deployment in industrial automation.
Policy: Don't File-and-Forget: Security policies must be living documents—subject to periodic review, tested against actual incidents, and constantly adjusted as new threats emerge. It’s easy to fall into compliance theater; organizations need active measures for validation.
Modern Cryptography and Its Discontents: Encryption in the OT world isn’t universally feasible—latency and processing overhead can break deterministic control loops. Where possible, start with protecting critical data in motion via TLS, IPsec, or (where mandates allow) network segmentation. For legacy devices, look into tunneling or mediation gateways to provide crypto overlays.
Network Architecture: Segmentation and Visibility
Decades ago, “air gapping” was the holy grail for keeping industrial networks safe. As anyone maintaining a plant network in the 21st century knows, that era is over: patch management, IIoT gateways, predictive maintenance vendors, and remote integrators have created persistent connectivity requirements. The challenge now: minimize blast radius without impeding operational performance.
Segmentation: VLANs, Firewalls, and the Purdue Model
The Purdue Enterprise Reference Architecture, dating to the 1990s, remains influential; its Level 0 (field), Level 1 (basic control), Level 2 (supervisory), Level 3 (operations management), and Level 4 (enterprise) structure forms the backbone for countless segmentation projects. In practice, this often means:
Isolating machine networks at Level 1/2 from enterprise IT (Level 4) using Layer 3 firewalls, with DMZs mediating cross-domain flows.
Employing VLANs—while acknowledging VLAN hopping risks if not paired with robust ACLs and port security—and restricting east-west traffic.
Using deep packet inspection (DPI) firewalls and industrial gateways capable of protocol-aware filtering (e.g., filtering by S7 function codes, not just port/protocol).
For legacy deployments, “virtual patching” via network controls may be the only realistic option for insecure endpoints that cannot be replaced or updated.
Visibility: Network Monitoring and Asset Inventory
"You can’t protect what you can’t see" is brutally true in OT. Historically, asset management was a spreadsheet afterthought—now, discoverability and fingerprinting are essential. The use of passive network monitoring (think modern Zeek/Bro, or OT-specific tools like Claroty/Nozomi), ARP scanning, and periodic walkdowns establishes a living asset inventory.
Operators must also baseline “normal” traffic patterns to detect anomalies—this is not theoretical: case studies from post-2015 Ukraine grid attacks to more recent ransomware outbreaks consistently highlight attacker dwell times measured in weeks, undetected in part due to a lack of visibility.
IT/OT Collaboration: The Cultural and Technical Divide
Historically, IT and OT teams operated in silos. IT was about confidentiality; OT about availability. While NIS2 legally mandates better cooperation, technical and cultural rifts remain:
IT terms like “endpoint protection” don’t directly translate to PLCs or field controllers—the latter often lack the necessary CPU/memory.
OT maintenance windows are measured in annual outages, if at all. IT patches quarterly, monthly, or even daily.
Protocols differ: OT relies on unique stacks (PROFINET, EtherNet/IP, DNP3); IT protocols don’t fit well.
Progress is possible, but only through deep cross-training and governance. IT staff must learn OT system constraints (safety, determinism, compliance with standards like IEC 62443); OT must embrace IT best practices for access control, logging, and network security. Practical steps:
Create cross-functional incident response teams—run tabletop exercises involving both IT and OT personnel.
Unify asset management systems so both teams share a single source of truth.
Regularly review and update user access rights and authentication credentials across both IT and OT environments.
Deploying Secure Connectivity: Practical Considerations and Pitfalls
NIS2 does not prescribe security products but does require enforceable architecture. Here’s what matters in deployment:
Zero Trust, Realistically: The current buzzword, “zero trust,” is laudable but requires contextual adaptation. For instance, microsegmentation per workload makes sense for cloud, but is infeasible for hard-wired PLC racks. Prioritize enforcing least privilege between trust zones, strong authentication for critical control functions, and logging of remote access.
Remote Access: Vendors and maintainers require access; uncontrolled TeamViewer or VPNs are disasters waiting to happen. Adopt brokered access (jump servers, multi-factor), session recording, and explicitly time-bound authorization.
Patch Management: Where devices can be patched, automate; where they can’t, fallback to tight segmentation, strict firewall policies, and host/network anomaly detection.
Legacy Migration Paths: For systems that cannot meet modern requirements, develop and document an explicit migration/retirement plan. Accepting and insuring risk may be necessary—just don’t ignore it.
Key Steps for Article 21 Compliance in Industrial Environments
Undertake a full asset discovery and risk assessment cycle, leveraging both passive and active tools. Validate findings with operational teams.
Segment networks in accordance with function and risk—don’t shoehorn every asset into a single “trusted” network.
Implement minimum viable monitoring (logging, event correlation, anomaly detection) for both IT and OT.
Establish clear, workable incident response plans spanning both disciplines—run drills focused on realistic IT/OT scenarios.
Put formal contracts and risk controls in place with all suppliers—require regular risk disclosure and vulnerability notification.
Create a roadmap for plugging legacy gaps—define compensating controls where full compliance is not yet feasible.
Document, review, and test all critical procedures regularly, with continuous improvement cycles.
Conclusion
NIS2 compliance—and the Article 21 obligations—are far from a checkbox exercise. If anything, this is a call for technical rigor and cross-functional discipline. For CISOs and engineers on the ground, the key is realism: evaluate what’s possible given your architecture, resource constraints, and legacy landscape, but set a continuous improvement path. Always remember: threats move quickly—regulations set the “what”, but technical teams must define “how”, iteratively, honestly, and with deep understanding of their own unique operating environments.
Further Reading
About the Author: [Your Name] is an experienced security architect with deep expertise in both corporate IT and industrial OT environments, and has advised on NIS implementation since its inception.
