NIS2 mandates specific cybersecurity risk-management measures for essential and important entities across 18 EU sectors — including multi-factor authentication, encryption, network security, and supply chain controls. BlastShield addresses all of these for your OT and ICS infrastructure.
Regulated sectors
Max penalty (essential)
Core technical requirements
BlastWave publishes compliance mappings. BlastWave is not certified or accredited to any regulatory framework, and no vendor product confers compliance on an operator. This page describes how BlastShield controls support specific required outcomes under the NIS2 Directive. It supports, but does not replace, an operator's own implementation plan, assessment plan, and formal determination by the applicable national competent authority.
Directive (EU) 2022/2555 — known as NIS2 — is the European Union's mandatory cybersecurity framework for operators of essential and critical services. It replaced the original NIS Directive in October 2024, dramatically expanding scope, adding new technical requirements, and introducing meaningful enforcement mechanisms including personal liability for management bodies.
For operators of OT and ICS infrastructure — energy, transport, water, manufacturing — NIS2 is not primarily an IT compliance exercise. The directive explicitly covers network and information systems that underpin essential service delivery, which includes the industrial control systems that run power grids, pipelines, water treatment plants, and rail networks.
The headline technical requirements in Article 21 map directly to what BlastShield does: multi-factor authentication, encryption, network segmentation and access control, supply chain security, and business continuity. The challenge for most OT operators is implementing these on legacy infrastructure without disrupting operations.
NIS2 is a Directive, so it reaches entities through national transposing law rather than directly. Member States were required to transpose by 17 October 2024. Transposition is not complete. In July 2026 the European Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice for failing to transpose. The Netherlands has since transposed, in force 15 August 2026. Verify your own national position before committing to a date.
Essential vs. Important entities: Article 34 attaches administrative fines to infringements of Article 21 or 23 and sets floors on what national law must allow. For essential entities the figure is a maximum of at least EUR 10 000 000 or 2% of total worldwide annual turnover, whichever is higher. For important entities it is a maximum of at least EUR 7 000 000 or 1.4%, whichever is higher.
Management liability: NIS2 introduces personal liability for management bodies of essential entities. Senior executives can be held personally responsible for compliance failures — making this a boardroom issue, not just an IT concern.
Two points are routinely misreported. "A maximum of at least" sets a floor, so national maxima may be higher and "up to EUR 10 million" understates the exposure. And the turnover is that of the undertaking to which the entity belongs, not the entity alone, so a small in-scope subsidiary of a large group is exposed to a percentage of the group's worldwide turnover.
NIS2 covers 18 sectors. If you operate critical or important infrastructure in the EU, you are almost certainly in scope — and your OT systems are explicitly included.
The table below maps key NIS2 requirements to specific BlastShield capabilities. Use this as the starting point for your compliance documentation.
Article 21(2)
Mandatory Measure
What NIS2 Requires
How BlastShield Delivers
Coverage
Art. 21(2)(a)
Risk Analysis & Security Policies
Documented policies for risk assessment and information system security
Establish and maintain policies for conducting risk assessments, identifying vulnerabilities, and implementing security controls proportionate to risk.
The BlastShield Orchestrator provides a centralized, auditable repository of all access policies across the OT estate — documenting who can access what, under what conditions, and via which authentication method. This forms the policy baseline that NIS2 risk assessments require. Policy changes are version-controlled and timestamped.
Supports
Art. 21(2)(b)
Incident Handling
any actions and procedures aiming to prevent, detect, analyse, and contain or to respond to and recover from an incident.
Article 6(8) defines incident handling as "any actions and procedures aiming to prevent, detect, analyse, and contain or to respond to and recover from an incident." Six activities, and a measure covers all of them.
Contributes to two. Prevent: assets that do not answer unauthorized scans are not reachable by an exploit targeting a service on them. Contain: isolation is a policy change rather than a cable pull, and policy activation is seconds, often under one second. Where connection logging is enabled, which is off by default, logs of permitted and denied access attempts and configuration changes are available to your analysis. BlastShield does not detect, does not analyse, and does not recover. The procedures, the roles, and the response process are yours.
Supports
Art. 21(2)(c)
Business Continuity
Backup management, disaster recovery, and crisis management ensuring service continuity
Implement measures to ensure continuity of essential services following a cyber incident. Includes backup management and disaster recovery plans.
BlastShield deploys as a software overlay on existing OT infrastructure — no single hardware dependency. The Orchestrator can run on-premises or in the cloud. In the event of an incident, an operator can manually terminate a live session. Deleting an entity in the Orchestrator revokes its access within seconds and terminates its active sessions, and the deletion is recorded in the configuration change log with the acting user and a timestamp.
Supports
Art. 21(2)(d)
Supply Chain Security
Security of supply chain including relationships with direct suppliers and service providers
Address cybersecurity risks in the supply chain, including third-party vendors and service providers who have access to the organization's systems.
BlastAccess provides dedicated, scope-limited, session-recorded remote access channels for third-party OEM engineers and service providers. Vendors are authenticated with phishing-resistant MFA, can only reach the specific systems they maintain, and every session is recorded for compliance evidence. Access is revocable instantly from the Orchestrator.
Directly addresses third-party remote access control
Art. 21(2)(e)
Security in Network Acquisition & Development
Security in acquisition, development and maintenance, including vulnerability handling and disclosure
Apply security considerations to the full lifecycle of network and information systems, including development and maintenance practices.
BlastShield's software-defined architecture provides a security layer that can be applied to existing OT systems without modification — satisfying the maintenance security requirement without requiring costly system replacement or modification. The API-first Orchestrator enables security to be programmed into network changes rather than retrofitted afterward.
Partial
Art. 21(2)(f)
Assess Risk-Management
Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
Implement processes to identify, assess, and remediate vulnerabilities. Coordinate vulnerability disclosure. Apply patches or compensating controls in a timely manner.
For OT systems that cannot be patched — PLCs, RTUs, embedded controllers — BlastShield's Network Cloaking and microsegmentation serve as documented compensating controls. Vulnerable assets are isolated behind a cryptographic boundary; the CVE exists but cannot be reached by any unauthorized party. This is explicitly recognized as a valid compensating control approach under NIS2 guidance.
Provides evidence for
Art. 21(2)(g)
Cybersecurity Training
Basic cyber hygiene practices and cybersecurity training
A baseline set of practices and a training program. Recital 49 names the baseline as software and hardware updates, password changes, the management of new installs, the limitation of administrator-level access accounts, and the backing-up of data.
BlastShield does not deliver this measure. One adjacent point, stated so you are not misled by it: passwordless MFA removes the memorized secret from BlastShield-mediated access, so password rotation does not apply there. That is one practice on one access path, not coverage of the measure. On the limitation of administrator-level accounts BlastShield is weak, not strong: it has two roles, read and read-write, applied network-wide, with no role scoping. Updates, new installs, backups, and all training are yours.
Out of scope
Art. 21(2)(h)
Cryptography and Encryption
Policies on the use of cryptography and, where appropriate, encryption
Protect confidentiality and integrity of data in transit and at rest through appropriate encryption policies and implementation.
All BlastShield communications travel through AES-256-GCM encrypted peer-to-peer tunnels. This applies even to legacy OT protocols (Modbus, DNP3, Telnet) that transmit in clear text — Unauthenticated packets are silently dropped. Not refused, not reset, not returned with an error. Nothing is sent back, so a scanner cannot distinguish a protected address from empty address space.
Directly addresses the technical control
Art. 21(2)(i)
Access Control & Asset Management
Human resources security, access control policies, and asset management
Implement controls ensuring that only authorized personnel have access to systems and data. Apply least-privilege principles. Manage access across the full personnel lifecycle including onboarding and offboarding.
The BlastShield Orchestrator enforces least-privilege access at the application and device level across all OT assets. Each user is granted access only to the specific systems their role requires. Access revocation is immediate and centralized — removing a user from the Orchestrator simultaneously revokes access to all systems, no per-device credential cleanup required. Full access logs support HR security audits.
Directly addresses the access control element
Art. 21(2)(j)
Secured Communications
Use of MFA authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems, where appropriate
Use MFA or continuous authentication for access to network and information systems. Secure internal communications channels. This is one of the most explicitly technical requirements in Article 21.
The BlastShield Authenticator provides phishing-resistant passwordless MFA — combining biometric verification, QR challenge-response, and device keystore cryptography. There are no passwords to phish, steal, or reuse. All communications are encrypted end-to-end. The system is designed for OT operational environments where fast authentication matters, including support for hardware tokens (FIDO2/YubiKey) for environments where mobile biometrics are impractical.
Directly addresses the multi-factor authentication element
Article 21 is the measures article. Two others decide who is accountable for those measures and what happens when an incident occurs. Both reach your organization directly and neither is something a vendor can discharge for you.
Article 20: your board approves the measures, and can be held liable
Article 20(1) requires Member States to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken to comply with Article 21, oversee its implementation, and can be held liable for infringements by the entity of that Article.
Article 20(2) requires members of those management bodies to follow training, and encourages entities to offer similar training to their employees regularly, so they gain sufficient knowledge and skills to identify risks and assess cybersecurity risk-management practices.
The Article 21 measures stop being an engineering decision recorded in an engineering system. They become a board-approved position your management body oversees and answers for personally. Whatever you deploy, someone at management-body level signs off on the reasoning and has to be able to describe it.
Where enforcement measures under Article 32(4)(a) to (d) and (f) have proved ineffective and a deadline to remedy has passed, a competent authority may request that the relevant bodies, courts, or tribunals temporarily prohibit a person responsible for discharging managerial responsibilities at chief executive officer or legal representative level from exercising managerial functions in that entity. The authority requests it. It does not impose it directly.
Three limits travel with that power. It reaches essential entities, not important entities. The prohibition applies only until the entity remedies the deficiency. And it does not apply to public administration entities subject to the Directive, which matters if you are a public body.
Article 32(4)(g) separately allows an authority to designate a monitoring officer, with well-defined tasks for a determined period, to oversee your compliance with Articles 21 and 23.
What BlastShield contributes. Nothing a vendor sells discharges an Article 20 duty. What BlastShield offers your management body is evidence it can show: an exportable policy configuration stating which systems may reach which, a configuration change log, and, where connection logging is enabled, which is off by default, logs of both permitted and denied access attempts. Approval, oversight, liability, and the training obligation are yours and remain so.
Article 23(1) requires essential and important entities to notify their CSIRT or, where applicable, their competent authority, without undue delay, of any incident having a significant impact on the provision of their services. Article 23(1) also records that the mere act of notification does not subject the notifying entity to increased liability.
Article 23(3): an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
Article 23(4) sets out five submissions.
Early warning, without undue delay and in any event within 24 hours of becoming aware, indicating where applicable whether the incident is suspected of being caused by unlawful or malicious acts or could have cross-border impact.
Incident notification, without undue delay and in any event within 72 hours of becoming aware, updating the early warning, giving an initial assessment including severity and impact, and where available the indicators of compromise.
Intermediate report, on request of the CSIRT or competent authority.
Final report, no later than one month after submission of the 72-hour notification, with a detailed description including severity and impact, the type of threat or root cause likely to have triggered it, applied and ongoing mitigation measures, and where applicable the cross-border impact.
Where the incident is still ongoing when the final report falls due, a progress report at that time and a final report within one month of the incident being handled.
The clock runs from becoming aware of the incident, not from when it occurred. That distinction decides whether the 24-hour obligation is met.
What BlastShield contributes. Configuration changes are recorded, and where connection logging is enabled, which is off by default and set per policy at deployment, BlastShield logs both failed and permitted access attempts and, where session recording is enabled, BlastAccess records remote sessions. Those records support the initial assessment required at 72 hours and the root cause and mitigation description required in the final report. Logs are written locally and rotate on available storage, so exporting to your SIEM is what retains them.
BlastShield does not start your clock. It is not a detection product. Meeting the 24-hour early warning is a monitoring and detection question. Detection finds it. BlastWave makes it unreachable. What determines whether you become aware inside 24 hours is your monitoring and your people.
Most NIS2 compliance programs start with IT security — SIEM, EDR, PAM, identity governance. These tools work in IT environments. They routinely fail when applied to OT infrastructure.
NIS2 Article 21(2)(k) mandates MFA. But PLCs, RTUs, and most SCADA systems have no authentication layer at all — they accept connections from any device on the same network. Standard IT MFA tools have no mechanism to protect these assets.
Modbus, DNP3, IEC 60870-5-104, and other industrial protocols were designed decades before encryption was a consideration. They transmit operational commands and sensor data in clear text. NIS2's encryption requirement cannot be met by modifying these protocols.
Historical OT networks were built as flat Layer 2 environments — all devices on the same broadcast domain, all able to communicate with all others. Retroactively implementing segmentation with firewalls requires IP address changes and extended maintenance windows that critical infrastructure cannot afford.
BlastAccess records all remote desktop sessions with full fidelity — keystroke logging, screen capture, and protocol metadata. Every access event is logged with user identity, source, destination, and duration. Audit evidence is available for NERC auditors on demand, without relying on SIEM correlation.
NIS2 introduces strict incident notification timelines that require organizations to have real-time visibility into their OT networks — something most operators lack today.
Within 24 hours of becoming aware of a significant incident, essential and important entities must submit an early warning to their national CSIRT. Within 72 hours, a detailed incident notification must follow. A final report is required within one month.
Meeting these deadlines is impossible without visibility into OT network activity — who connected, from where, to what, and when. Most OT environments have no audit trail at all.
BlastShield's contribution: The BlastShield Orchestrator logs every access event — authentication attempt, successful connection, denied probe, session duration, session termination — with full user identity and timestamp. Every denied connection to a cloaked asset is a high-confidence security event: in a Zero Trust network, you cannot probe what you cannot see, so a probe attempt is unambiguous evidence of unauthorized activity. This audit trail is the foundation of NIS2 incident reporting.
Incident containment: An operator can manually terminate a live session. Deleting an entity in the Orchestrator revokes its access within seconds and terminates its active sessions, and the deletion is recorded in the configuration change log with the acting user and a timestamp. This limits the "significant incident" scope and demonstrates active containment capability to regulators, which NIS2 expects to see evidenced in incident notifications.
Our European compliance specialists help OT operators develop a defensible compensating control architecture that addresses both CRA and NIS2 — before enforcement deadlines arrive.
Our Privacy Policy applies.
.svg)
Privacy Policy | Cookie Policy | © 2026 BlastWave, Inc. All Rights Reserved
This website uses cookies to ensure you get the best experience. More Info