The BlastShield Security Gateway is a hardware-independent software package that can be installed in a VM or container, or purchased as a pre-installed appliance from our partners (see the bottom section of the page for appliances). It delivers Network Cloaking, terminates Secure Remote Access connections, and uses software-defined segmentation to secure OT networks.
CRA entered into force
Incident reporting obligations apply
All product requirements apply
Prepare compensating controls for legacy devices
Regulation (EU) 2024/2847 — the Cyber Resilience Act — introduces mandatory cybersecurity requirements for any product with digital elements placed on the EU market. This includes hardware and software components in industrial automation and control systems: PLCs, RTUs, HMIs, sensors with digital interfaces, SCADA components, and network equipment used in OT environments.
The CRA applies primarily to manufacturers — the companies that design and sell these products — who must ensure their products are secure by design, ship with secure default configurations, have no known exploitable vulnerabilities at launch, include update mechanisms, and come with vulnerability disclosure obligations.
For OT operators, the CRA matters in two distinct ways: first, future product purchases will need to demonstrate CRA conformity. Second, and more immediately, the vast installed base of legacy OT equipment — most of which predates the CRA and will never be updated to meet its requirements — needs a risk management approach that satisfies both the CRA's intent and adjacent regulations like NIS2.
The legacy problem: The CRA applies to products placed on the market after its requirements take effect. Your existing fleet of PLCs, RTUs, and SCADA systems — installed over the past 10–20 years — will never be CRA-compliant. They may have known unpatched vulnerabilities, accept no authentication, transmit in plaintext, and have no update mechanism. The CRA does not require you to replace them. But NIS2 does require you to manage the risk they represent. BlastShield is that risk management layer.
CE marking under CRA: Products that comply with CRA essential requirements carry a CE mark indicating conformity. From December 2027, OT operators should give preference to CRA-compliant products in procurement. For existing non-compliant devices, documented compensating controls demonstrate due diligence to regulators.
The CRA categorizes products by risk level. Higher-risk categories require third-party conformity assessment. Most OT components fall into the default or important classes.
The majority of connected OT components. Manufacturers can self-certify compliance through internal conformity assessment.
Includes: most network equipment, standard sensors, general-purpose software
Higher-risk products where vulnerabilities could have significant impact. OT-relevant examples include industrial routers and switches, SCADA components.
Includes: industrial network devices, security products, remote access software
Products with more significant potential impact requiring stricter conformity assessment procedures.
Includes: industrial automation and control systems, PLCs in certain categories, OS for industrial devices
Highest-risk category including hardware devices with security boxes and critical infrastructure components. Strictest conformity requirements.
Includes: hardware security modules, smart meter gateways, safety-critical controllers
CRA compliance for OT operators has two distinct dimensions. BlastShield addresses both.
Your installed base of PLCs, RTUs, and legacy SCADA components will never achieve CRA compliance — they cannot be patched, updated, or reconfigured to meet the Annex I essential requirements. BlastShield acts as the architectural control layer that compensates for their non-compliance: cloaking them from unauthorized discovery, enforcing MFA at the network boundary before any packet reaches the device, and preventing lateral movement if an attacker does breach an adjacent system.
Regulators examining NIS2 Article 21(f) (vulnerability management) expect to see documented compensating controls for unpatchable assets. BlastShield's zero-trust overlay is exactly that documentation — and it's enforceable, not just theoretical.
As the CRA enforcement date approaches, OT operators will need to validate that the products they procure from manufacturers demonstrate CRA conformity. But vendor OEM engineers still need remote access to maintain existing equipment in the meantime. BlastShield manages this risk by controlling and auditing all vendor remote access — ensuring that even a vendor whose products may have CRA compliance questions cannot use remote access to introduce vulnerabilities or exfiltrate data.
BlastAccess creates a scope-limited, session-recorded, identity-verified maintenance channel. Vendors service only the specific devices they are authorized for. Every session is captured for compliance evidence.
CRA Annex I Section 1 defines the product security requirements. For legacy OT assets that cannot meet these natively, BlastShield provides the compensating control layer. For BlastShield itself as a product, these requirements are built into its design.
Annex I Requirement
What the CRA Requires of Products
BlastShield as Compensating Control for Legacy OT Assets
Coverage
Annex I §1(1)
No Known Exploitable Vulnerabilities
Products must be placed on market without known exploitable vulnerabilities
Legacy OT assets cannot satisfy this — they ship with known, unpatched CVEs that will never be addressed. BlastShield's Network Cloaking makes these vulnerabilities unreachable: the device is invisible to unauthorized scans, and no exploit can land on what cannot be discovered. The CVE exists; the attack path does not.
Compensating Control
Annex I §1(2)
Security by Default Configuration
Products must be delivered with a secure by default configuration, including the ability to reset to original state
BlastShield itself ships with a deny-by-default Zero Trust policy — nothing is permitted unless explicitly authorized. For legacy OT assets that shipped with no authentication and open access, BlastShield retrofits a secure default at the network boundary: access is denied until identity is verified, regardless of the device's native security configuration.
Compensating Control
Annex I §1(3)
Confidentiality, Integrity, and Availability Protection
Products must protect confidentiality, integrity, and availability of stored, transmitted, and processed data
All communications to and from BlastShield-protected OT assets travel through AES-256 encrypted peer-to-peer tunnels. Plaintext industrial protocols (Modbus, DNP3, etc.) are wrapped in encrypted transport — no attacker with physical access to the network can read operational commands or sensor data. Integrity and availability are maintained through segment isolation that prevents a breach from propagating.
Compensating Control
Annex I §1(4)
Minimal Attack Surface
Products must minimize their attack surface, including external interfaces
BlastShield's core capability is attack surface reduction. Protected OT assets are invisible to unauthorized endpoints — they do not respond to pings, scans, or connection attempts from non-authenticated sources. There are no exposed management ports, no open services visible to the network. The attack surface is functionally zero for anyone outside the authenticated overlay.
Compensating Control
Annex I §1(5)
Protection Against Unauthorized Access
Products must be designed to limit access to authorized users, processes, and services only
BlastShield enforces identity-based least-privilege access at every connection attempt. Users and devices must authenticate with phishing-resistant MFA before establishing any connection to an OT asset. Unauthorized parties cannot access what they cannot reach — and they cannot reach what is invisible.
Compensating Control
Annex I §1(8)
Security Logging
Products must record security-relevant events; logs must be available for investigation
The BlastShield Orchestrator logs all access events — authentication attempts, successful connections, denied probes, session duration and termination — with full user identity and timestamp. For legacy OT assets with no native logging capability, BlastShield provides the security event record that CRA and NIS2 both require. Logs export via Syslog to enterprise SIEM platforms.
Full Coverage
Annex I §1(9)
No Unauthorized Access Channels
Products must not contain undocumented access capabilities, functions, or backdoors
BlastShield's Software-Defined Perimeter ensures that all network access paths are explicitly defined, authenticated, and auditable. The Orchestrator maintains a complete, version-controlled record of all access policies. Any connection that has not been explicitly authorized through the policy system is structurally impossible — not just blocked by a rule that could be misconfigured.
Full Coverage
Annex I §2
Vulnerability Handling
Manufacturers must identify vulnerabilities, distribute security updates, and coordinate disclosure
For OT operators, this requirement on product manufacturers creates supply chain risk management obligations under NIS2. BlastShield addresses this by controlling and auditing all manufacturer/vendor remote access — ensuring vendor maintenance sessions cannot be used to introduce new vulnerabilities or exfiltrate operational data. BlastAccess session recording provides evidence of authorized vendor activity.
Supply Chain Control
Inventory Your OT Assets Against CRA Product Categories
Identify which OT components in your environment fall under CRA product categories — particularly Class II Important Products (industrial automation and control systems) and critical products. Document their current vulnerability status and whether any update path exists.
Deadline: Complete before Dec 2027 compliance date
Establish Compensating Controls for Legacy Assets
For assets that will never be CRA-compliant, implement and document compensating controls that achieve the security outcome the CRA requires. Network isolation, authenticated access boundaries, and encrypted communications satisfy regulatory due diligence — and BlastShield delivers all three without touching the legacy device.
Action: Deploy BlastShield before CRA reporting obligations begin Sep 2026
Tighten Vendor Remote Access Controls
CRA places vulnerability disclosure obligations on your OT equipment suppliers. But until their products achieve compliance, you must manage the risk of their remote maintenance access. Replace uncontrolled VPN access with BlastAccess: scope-limited, session-recorded, phishing-resistant maintenance channels.
Action: Audit all third-party OT access paths; migrate to BlastAccess
Update Procurement Requirements
As the CRA enforcement date approaches, update your OT equipment procurement specifications to require CRA conformity declarations from manufacturers. Prefer CE-marked products where available. Document exceptions with compensating controls for any non-compliant products that must still be purchased.
Deadline: Build into 2026 procurement cycles
Create a Security Event Log for OT Infrastructure
Both the CRA and NIS2 require access logging and incident reporting capabilities. Most legacy OT assets have no native logging. BlastShield provides the security event record for every OT asset it protects — authentication events, access grants, denied probes, and session data — exportable to SIEM for retention and analysis.
Action: Connect BlastShield logs to your SIEM before Sep 2026 reporting obligations
Coordinate with National Cybersecurity Authority
CRA enforcement runs through national market surveillance authorities. NIS2 incident reporting runs through national CSIRTs. Establishing early dialogue with your national authority, demonstrating a documented compensating control architecture, positions you favorably before mandatory reporting obligations begin.
Action: Prepare CRA gap assessment and compensating control documentation
The CRA and NIS2 are complementary, not redundant. The CRA focuses on the security of products with digital elements — the hardware and software that makes up OT infrastructure. NIS2 focuses on the security practices of the organizations that operate that infrastructure. Together they create a supply-side and demand-side security mandate for OT environments.
Under NIS2 Article 21(d), essential and important entities must address cybersecurity risks in their supply chain — which explicitly includes the security of products they procure. A NIS2-compliant operator must therefore have a view on which of their OT products are CRA-compliant (or on what timeline they will become so) and what compensating controls exist for those that are not.
BlastShield in the CRA/NIS2 Stack
→ For NIS2 Article 21(d): BlastShield controls and audits all third-party vendor access, demonstrating active supply chain risk management.
→ For NIS2 Article 21(f): BlastShield provides documented compensating controls for unpatchable OT assets with known CVEs.
→ For CRA Annex I: BlastShield compensates for legacy assets that cannot meet essential product security requirements by providing network-layer enforcement of those outcomes.
→ For both regimes: BlastShield's audit logs satisfy the security event recording requirements that both regulations require.
Our European compliance specialists help OT operators develop a defensible compensating control architecture that addresses both CRA and NIS2 — before enforcement deadlines arrive.
Getting started with BlastShield is easy and free. Follow the three steps below and get up and running fast.
%20(1).svg)
Create a Free Trial
Account
.svg)
Download the BlastShield Authenticator & Client
.svg)
Make Your Host Invisible
In Minutes
.svg)
Privacy Policy | Cookie Policy | © 2025 BlastWave, Inc. All Rights Reserved
This website uses cookies to ensure you get the best experience. More Info