Executive summary

Week 17 of 2026 offered a coincidence that was not accidental. On 18 April 2026, Belgium’s first formal NIS2 compliance deadline expired: essential entities had to deliver documentation verified by an accredited body for the cybersecurity controls in place, with self-declarations not accepted. Six days later, on 24 April, the Elsevier journal Sustainable Energy, Grids and Networks published a new study on detection, classification and interpretable mitigation of cyberattacks against cyber-physical microgrids using deep learning.

The power-electronics industry sits, for the first time, exactly at the crossroads between binding regulation and the algorithmic state of the art. The operational question for the engineer at a custom converter manufacturer is not whether those models work in simulation. It is whether the embedded firmware, the monitoring gateways and the OTA procedures can stand up today to a NIS2 audit.

This article advances three theses. The first is that a deep-learning detector, however accurate, is operationally unusable if the operator cannot explain why the model decided to isolate a node. The second is that the interpretability that matters in OT is not feature attribution — that is a debugging tool for the engineer — but the documented causal traceability that supports the action before the regulator. The third is that the place where this game is won or lost is not the algorithmic layer but the engineering methodology: at Premium SA, cybersecurity enters at the Design to Work phase and is not added during Design for Compliance.

Detection yes, decision no: the gap between accuracy and action

A modern microgrid is crossed by two coupled physical planes. The electrical plane carries power between distributed sources, storage and loads. The cyber plane carries measurements, setpoints and diagnostics between converters, control gateways and operations centres. The technical literature has shown over the last decade that an attacker with access to the cyber plane does not need to break cryptography: it is enough to inject false voltage or frequency readings — a False Data Injection Attack (FDIA) — for the control system to react to the mirage and degrade the actual physical plane.

The trap is to confuse detection accuracy with operational utility. A model that correctly classifies 99 % of attacks on a synthetic dataset does not solve the real operator’s problem. The operator must answer three questions in seconds: what is happening, why does the detector claim it, and which mitigation manoeuvre is defensible before the customer, before the regulator and — in railway or defence sectors — within the RAMS dossier.

The methodological consequence is that interpretability must be designed from the start, not bolted on at the end as a cosmetic layer. When it is added afterwards — typically with techniques such as SHAP or post-hoc attention — the result is an explanation that satisfies the data engineer but not the operator. When it is designed from the start, the model is selected and constrained specifically so that its decision is reconstructable by a person with electrotechnical training.

The April 2026 study and its limits

The work published on 24 April 2026 in Sustainable Energy, Grids and Networks proposes a unified framework for detection, classification and mitigation of cyberattacks against cyber-physical microgrids using a deep-learning architecture described by the authors as interpretable. The contribution integrates three steps within a single model: identifying that an attack is taking place, assigning it a known category (FDIA, replay, denial of service on the control bus) and proposing a mitigation action.

Our honest critique of this work, written from the perspective of a manufacturer that will eventually have to take one of these detectors into the field, articulates around four points:

• Synthetic dataset bias: validation on synthetic or lab data does not cover the long-tail failure modes that appear in real fleet operation over 10–30 year product lifetimes.
• Explanation depth: attention-based feature attribution satisfies the data scientist; it does not produce the auditable causal chain that a railway RAMS dossier or a NIS2-verified security assessment requires.
• Latency under load: inference latency of deep models on embedded hardware has not been characterised under the concurrent firmware loads typical of industrial converters.
• Integration pathway: the paper, by its nature, does not address firmware integration, OTA update procedures, key management or the regulatory documentation chain — exactly the gap that a converter manufacturer has to close.

How Premium SA tackles this: D4Co applied to cybersecurity

Premium SA’s D4x methodology — D2W → D2F → D4R → D4Co — was originally developed to embed RAMS discipline in hardware and was extended in March 2026 to critical firmware. The natural extension to cybersecurity treats it with the same pattern of sequential gates and quantitative exit criteria. The difference from the classic IT model is that, in D4x, security is designed in the first gate and validated cumulatively in the following ones — it is not added at the end as a compliance layer.

Why SL 2 is the operational target, not SL 4

IEC 62443-3-3 defines four Security Levels, from SL 1 (protection against casual error) to SL 4 (sophisticated attacker with time, resources and system knowledge). Premium SA sets SL 2 as the default operational target for industrial SCADA and industrial IoT. The reason is methodological, not budgetary: SL 2 covers the attacker with limited resources but specific motivation — the dominant profile in real microgrid incidents — at an implementation cost that does not penalise power density or customer TCO. For defence sectors or critical infrastructure with a higher threat profile, the target SL is raised to SL 3 through a project-specific TARA, while preserving the same D4x methodology.

Firmware hardening: the non-negotiable practices

• Systematic defensive programming: input validation, return-value checks, assertions, timeouts on every communication handler. Explicit assumption that any bus message can be malicious or malformed.
• CRC-16 CCITT on every critical data frame of the internal bus, per IEC 62443-3-3. Guaranteed detection of errors up to 16 bits. Integrity checked in hardware before logical processing.
• Clean MISRA C:2012 static analysis before closing the D2F gate — the 16 mandatory and 111 required rules are exit conditions, with no exceptions documentable at project level.
• OTA procedure with cryptographic signature of the binary and rollback, integrated into FRACAS-SW. Every update is traceable by unit serial number and recoverable to a previously approved version.
• Key management separated from operational firmware — storage in a secure element or protected partition, with the rotation policy documented in the project dossier.

European regulatory framework: what NIS2, CRA and the rest demand

Transposition of NIS2 into national law reached its mature phase in the first months of 2026. As of 1 January 2026, 22 of the 27 Member States had the framework approved or in final approval phase. Spain was at maturity level 2 (draft law in legislative procedure). Belgium set the first formal compliance milestone for 18 April 2026, with documentation verified by an accredited body — no self-declaration accepted. Germany published the KRITIS-Dach-Gesetz on 17 March 2026 with first mandatory registration by 17 July 2026. Italy holds October 2026 deadlines with a framework based on NIST CSF 2.0.

The second regulatory block is the Cyber Resilience Act, applicable directly without transposition from 20 January 2027. For Premium SA, the CRA is not an additional standard: it is the European formalisation of practices that already live inside the D4Co methodology — TARA, FRACAS-SW, signed OTA, compliance dossier — and that have been applied for two years.

The conversation Premium SA has with its customers

When a customer in railway traction, defence microgrids, stationary storage or distributed energy infrastructure asks about cybersecurity for their converters, the conversation does not start by showing a deep-learning detector. It starts with three questions: which critical assets does the system under analysis hold, which threat profile is realistic, and which target Security Level will be defended at audit time. These three questions are the TARA at the D2W gate, and everything else derives from them — the communications architecture, firmware hardening, the OTA procedure, the security FRACAS-SW, the regulatory documentation and the incident response.

The D4Co methodology articulates that discipline in gates with quantitative criteria. The European regulation of 2026 also turns it into a legal condition of operation. Premium SA delivers both as an integrated product.