Compliance-by-Design for Critical Infrastructure: NIS2, CRA, and How Energy Innovators Can Prepare 

This is the second article in a series exploring regulatory themes from ENODA's participation in the European Blockchain Sandbox (EBS). 

 

Europe's cybersecurity requirements for energy companies are increasing rapidly. The NIS2 Directive, the Critical Entities Resilience Directive, the Cyber Resilience Act, and the EU's Network Code on Cybersecurity are all now in force or entering application — the most significant expansion of security obligations for the energy sector in a decade. 

The challenge isn't just that requirements are increasing. It's that they vary from country to country, from grid operator to grid operator, and from product to product. 

At ENODA, we encountered this directly through our participation in the European Blockchain Sandbox — a structured regulatory dialogue run by the European Commission. What we learned about navigating these overlapping frameworks is relevant to any technology company deploying connected infrastructure into European grids. 

 

The regulatory landscape

NIS2 replaced the original NIS Directive in October 2024, significantly expanding who falls within scope. The energy sector is classified as a "sector of high criticality," meaning grid operators, producers, suppliers, and market participants providing aggregation or balancing services are likely subject to its risk management and incident reporting requirements. 

The directive was supposed to be transposed into national law by October 2024. As of early 2026, roughly twenty Member States have completed transposition, but others are still finalising. The Commission has issued formal warnings to nineteen countries. For companies operating across borders, the same directive can produce different obligations depending on where you deploy. 

On top of NIS2, the Critical Entities Resilience Directive (CER Directive) extends requirements beyond cybersecurity to physical resilience. For energy infrastructure providers, these two directives often apply in parallel. 

Then there's the Cyber Resilience Act (CRA), which regulates products rather than entities: any hardware or software "product with digital elements" placed on the EU market must meet lifecycle security requirements including vulnerability handling, signed software updates, and software bills of materials. The CRA applies fully from December 2027, adding a product-level compliance layer on top of entity-level NIS2 obligations. 

 

Classification determines obligations 

One thing the EBS dialogue made clear, is that how a platform is classified under NIS2, materially changes what's required. The directive distinguishes between essential and important entities, and creates specific categories for Managed Service Providers (companies that manage IT infrastructure on behalf of customers) and Managed Security Service Providers (a narrower category covering companies that specifically deliver cybersecurity services like incident response or security monitoring). 

Both MSPs and MSSPs are classified as essential entities under NIS2, facing the stricter tier of obligations. But MSSPs are also subject to an emerging EU certification scheme under the Cybersecurity Act, so the distinction matters. 

For a platform that coordinates distributed energy resources and interfaces with grid operators, the classification question is not academic. Are you a market participant? An MSP? Potentially an MSSP? Each answer leads to different obligations. 

Through our EBS dialogue, the general view was that a coordination platform like the one we are building at ENODA, would most likely be classified as an MSP rather than an MSSP — but this remains an area where further regulatory clarification would be valuable, particularly as national transposition introduces local variation. 

 

Building for divergence, not uniformity 

The instinct for many companies is to treat compliance as a single target: meet the requirements, tick the box. But when the same directive produces meaningfully different obligations across jurisdictions, that approach breaks down quickly. 

What works better is anchoring your security posture to internationally recognised standards, and mapping national or operator-specific requirements against that foundation.

Two standards are particularly relevant for the energy sector:

  1. IEC 62443 is a family of standards for securing industrial automation and control systems (covering network segmentation, device hardening, role-based access, and incident response) and is widely referenced by grid operators as a baseline expectation.  

  2. ISO 27019 extends the broader ISO 27001 information security management framework with controls specific to energy utility environments, including SCADA systems and operational technology. 

Aligning to these standards doesn't automatically satisfy NIS2 in any given jurisdiction. But it provides a common foundation that regulators and grid operators already understand, making it easier to identify and address jurisdiction-specific gaps rather than starting from scratch each time. 

 

Designing for the CRA now 

For companies building connected hardware, the CRA's December 2027 application date may seem distant. It isn't. Product development cycles in the energy sector are long, and the CRA's requirements need to be designed in, not bolted on. 

The practical implications include establishing a coordinated vulnerability disclosure process, maintaining a software bill of materials, implementing signed update mechanisms, and ensuring secure-by-default configurations. These are architecture decisions, not paperwork exercises. 

 

Why this matters commercially 

Compliance-by-design isn't just a regulatory obligation, but a procurement accelerator. Grid operators are critical infrastructure entities under NIS2, meaning their supply chain risk management obligations extend to the technology vendors they work with. A vendor that can demonstrate a structured, standards-aligned security posture reduces due diligence friction and shortens procurement timelines. 

In our experience, showing up with a clear classification analysis, standards alignment, and a CRA readiness plan changes the conversation. It moves cybersecurity from a blocker to a differentiator. 

 

ENODA is building a coordination and settlement platform for distributed energy resources. This is the second article in a series exploring regulatory themes from our participation in the European Blockchain Sandbox. The next article will examine how the EU Data Act interacts with sector-specific energy regulation. 

 

Previous
Previous

Auditability as a Market Feature: How Distributed Ledger Technology Reduces Friction in Balancing and Aggregation

Next
Next

Inside ENODA's European Blockchain Sandbox Experience