Since 15 August 2026 the Dutch Cybersecurity Act (Cbw) and the Critical Entities Resilience Act (Wwke) have been in force, without a transition period. The Cbw is the Dutch implementation of the European NIS2 directive and replaces the Network and Information Systems Security Act (Wbni). The act affects an estimated more than 8,000 organisations in eighteen sectors — from energy and drinking water to digital infrastructure, healthcare, government and transport. For OT environments in the energy sector this is not an abstract legal development: it is a statutory duty of care that now also explicitly applies to control systems, not only to office IT.
This article does not make a legal file of the Cybersecurity Act, but builds the bridge that is relevant to this platform: what does the act broadly require, and which IEC 62443 measures help to demonstrably comply with it?
What does the Cybersecurity Act require?
The act has three main obligations:
- Registration duty — organisations covered by the act register in the national entity register via mijn.ncsc.nl.
- Duty of care — carry out a risk analysis and, on that basis, take appropriate and proportionate technical, operational and organisational measures to manage risks to network and information systems.
- Reporting duty — report a serious incident as soon as possible, and in any case within 24 hours, to the CSIRT and the supervisory authority.
The act distinguishes between essential entities (including energy, drinking water and digital infrastructure) and important entities (including organisations with more than 50 employees or an annual turnover/balance sheet total above 10 million euros). Energy grid operators and many of their suppliers generally fall under the stricter essential regime.
Important to keep clear: the Cybersecurity Act does not prescribe a specific standard or certification. The act formulates an obligation of result (demonstrably appropriate measures), not an obligation to apply IEC 62443. In practice, however, IEC 62443 is one of the most common frames of reference for making that duty of care concrete and demonstrable in an OT environment — hence the link in this article.
What does this mean specifically for OT?
The duty of care applies to "network and information systems" — a description that does not exclude control systems, PLCs, RTUs, HMIs and the networks between them. For a grid operator this means that a substation or control centre does not fall outside the scope of the act because it is "OT and not IT". A number of practical consequences:
- OT asset owners must be able to show a current risk analysis that actually includes the OT environment, not only the office environment.
- The 24-hour reporting duty requires detection and escalation capacity that also signals OT incidents in time — see FR6, Timely response to events.
- Suppliers of OT components and services (system integrators, product suppliers) are also indirectly affected via the supply chain security requirement of the act, even if they do not fall directly under the Cbw themselves.
The ten duty-of-care measures and their IEC 62443 counterpart
Article 21(2) of the NIS2 directive — the basis of the Dutch duty of care — lists ten categories of risk management measures. The overview below links each category to the IEC 62443 part that comes closest to it in an OT environment.
| NIS2 measure (Art. 21(2)) | IEC 62443 anchor point |
|---|---|
| a. Risk analysis and security policy | 62443-2-1 (security programme) + 62443-3-2 (risk assessment of zones/conduits) |
| b. Incident handling | FR6 — Timely response to events |
| c. Business continuity and crisis management | FR7 — Resource availability |
| d. Supply chain security | 62443-2-4 (requirements for service providers) |
| e. Security in acquisition, development and maintenance (incl. vulnerability response) | 62443-4-1 (secure product development lifecycle) — direct overlap with CVE, KEV and advisory follow-up |
| f. Assessing the effectiveness of risk management | 62443-2-1 (periodic evaluation of the security programme) |
| g. Cyber hygiene and awareness/training | 62443-2-1 (organisational, roles and training) |
| h. Cryptography and encryption policy | FR4 — Data confidentiality |
| i. Personnel, access policy and asset management | FR1 — Identification and authentication control, FR2 — Use control |
| j. Multi-factor authentication and secured communication | FR1 and FR4, plus 62443-3-3 (system security requirements) |
This mapping is a practical aid, not an official equivalence table: the legislator has not designated IEC 62443 as the mandatory way to comply, and an auditor or supervisory authority may ask for additional or different substantiation.
Reporting duty: what must you be able to do within 24 hours?
The 24-hour reporting deadline is short, especially in an OT environment where a deviation sometimes only becomes visible through secondary signals. This places concrete demands on FR6 implementation: monitoring that actually looks at the OT network (not only at the IT layer), a defined escalation path from engineer to security officer to CSIRT report, and practised roles so that the first report is not delayed by uncertainty about who is responsible for what. A zones-and-conduits layout also helps here: by knowing which zone has a Security Level Target and which conduits lie between them, it is faster to determine whether and how serious a deviation is, and who needs to be alerted.
Practical example
A grid operator completes a risk analysis for the OT environment of ten substations and finds that the central engineering workstation (SL-T 3) is accessible from the office network without multi-factor authentication. This is linked to NIS2 measure i/j (access policy, MFA) and FR1. The measure taken — MFA on the remote access gateway and withdrawing direct access from office IT — is documented with a reference to both the risk analysis and the FR1 substantiation, so that this is demonstrable in an audit or after an incident.
Common mistake
Treating the Cybersecurity Act as an IT-only compliance track, filled in by a central security team without the involvement of OT asset owners and engineers. A risk analysis and package of measures that does not substantively include the OT environment does not meet the duty of care for those systems — not even if the IT environment is in perfect order.