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.
In force across EU
Regulated sectors
Max penalty (essential)
Core technical requirements
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.
Essential vs. Important entities: NIS2 creates two tiers. Essential entities (energy, transport, water, banking, health, digital infrastructure) face stricter supervisory requirements and higher maximum penalties — up to €10 million or 2% of global turnover. Important entities (postal services, waste management, chemicals, food, manufacturing, digital providers) face lighter supervision but identical technical requirements under Article 21.
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.
Essential entities: up to €10M or 2% of global annual turnover (whichever is higher). Important entities: up to €7M or 1.4% of global turnover. Plus personal liability for management and the right for national authorities to temporarily prohibit individuals from exercising management functions.
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 NERC CIP 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)(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, the Digital Kill Switch isolates compromised segments in milliseconds without shutting down the entire OT network — surrounding systems continue operating while the threat is contained.
Full Coverage
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.
Full Coverage
Art. 21(2)(e)
Security in Network Acquisition & Development
Security measures covering acquisition, development, and maintenance of network and information systems
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)
Vulnerability Management
Policies for vulnerability handling and disclosure; addressing identified vulnerabilities without undue delay
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.
Full Coverage
Art. 21(2)(i)
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 encrypted peer-to-peer tunnels. This applies even to legacy OT protocols (Modbus, DNP3, Telnet) that transmit in clear text — BlastShield's Protocol Cloaking encapsulates their traffic in encrypted tunnels without requiring changes to endpoint devices. Even physical access to a network switch yields no readable traffic.
Full Coverage
Art. 21(2)(j)
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.
Full Coverage
Art. 21(2)(k)
Multi-Factor Authentication & Secured Communications
MFA or continuous authentication; secured voice, video, and text communications; secured emergency systems
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.
Full Coverage
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: BlastShield's Digital Kill Switch enables instant segment isolation — revoking access for a compromised zone, site, or user group within milliseconds. 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.
.svg)
Privacy Policy | Cookie Policy | © 2025 BlastWave, Inc. All Rights Reserved
This website uses cookies to ensure you get the best experience. More Info