Execution Integrity in the Age of NIS2 & CRA: What Comes After Perimeter Compliance

Written by Sandra Weiss

BY SANDRA WEISS

European critical infrastructure operators are racing against regulatory clocks, but we may be building our compliance programs under the revised Network and Information Security Directive (NIS2) on a foundational misconception, the assumption that securing the network around an industrial asset secures the asset itself. With the March 2026 registration deadline of the Federal Office for Information Security (BSI) under Germany’s NIS2 Implementation Act (NIS2UmsuCG) now behind us and Cyber Resilience Act (CRA) conformity timelines running, compliance requires shifting from perimeter security to execution integrity, verifying not just what traffic touches your device, but what code actually executes on it.

 

The IT-Centric Blind Spot

Many NIS2 compliance programs across Europe are currently being constructed around network architecture. Teams are investing heavily in network segmentation, access controls, micro-perimeter firewalls, continuous network monitoring, and incident response playbooks. The underlying assumption is simple. If everything surrounding the system is secure, the system inside must be secure.

The flaw in this logic is a costly one. It treats the hardware layer as an unassailable given, when it’s often the least-checked part of the whole chain.

But are we checking whether the component running inside the secure perimeter is actually executing the code it was designed to run? Execution integrity sits below the operating system, below the application stack, and below every log collector or network sensor that a standard compliance checklist measures.

The Hardware Blind Spot: A firewall cannot verify the integrity of firmware execution running on the programmable logic controller (PLC) sitting behind it. The firewall sees network traffic, but it does not see code execution.

If an attacker or an untrusted supply chain actor alters the firmware of an industrial controller, the network-layer controls in your architecture will continue to report that the system is fully healthy and compliant.

As Report 4 of this series discussed, grid-scale Battery Energy Storage Systems (BESS) often depend on inverters and battery management systems manufactured in jurisdictions with state-compelled access laws. You cannot verify whether an embedded microcontroller's low-level firmware has been modified or backdoored simply by listening to its network traffic.

 

What the Regulations Actually Ask For

When you map the requirements across key frameworks, a clear mandate emerges:

NIS2 Article 21(2)(d): Mandates supply chain security, explicitly covering the security-related aspects of relationships between each entity and its direct suppliers or service providers.

CRA Article 13: Obligations placed on manufacturers to document components, address known vulnerabilities, and provide security updates throughout the lifecycle. This is where the CRA's Software Bill of Materials (SBOM) requirement comes from.

§ 30(2) of the German Act on the Federal Office for Information Security (BSIG): Mandates technical and organizational measures covering supply chain security, acquisition processes, and secure operations. It can be interpreted as requiring organizations to demonstrate a trustworthy operational baseline, meaning operators must prove what software/firmware is running and that it matches what was formally approved.

Read together, these regulations point toward three capabilities. You need to know what firmware exists on your critical devices, know precisely where it came from, and be able to show that it was not tampered with before or during operation.

The NERC CIP Reference: A Road Already Walked

European operators feeling overwhelmed by these mandates can look to North America, where this exact regulatory journey played out over the last decade.

In the US electric sector, the North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection standard CIP-010 established the requirement for a documented baseline configuration that explicitly includes firmware versions. Soon after, CIP-013 required supply chain risk management plans, and CIP-010 required verifying software integrity before installation.

After years of enforcement audits, US energy entities learned a hard lesson. A perimeter-based compliance program could not answer the auditor’s core question:

“How do you know that the code running on that critical asset is actually the code you approved?”

The US sector shifted from perimeter security to execution integrity not through theoretical debates, but through years of audits and enforcement. NIS2 and the CRA are now pointing EU operators towards the same lesson.

In Germany, the risk management measures in § 30 BSIG point toward what NERC CIP-010 codified years ago. European operators who study how NERC CIP entities solved baseline verification have a head start.

What a Defensible Baseline Technically Requires

To move from “documentation mode” to a technically defensible baseline, an operational technology (OT) security architecture requires four core technical components:

1. Hardware Root of Trust

A physical cryptographic anchor embedded on the motherboard that verifies the boot chain hasn’t been altered before any higher-level code executes. Trusted Platform Module (TPM) 2.0 is increasingly becoming the preferred hardware root of trust for modern industrial platforms.

What it does: Securely measures boot stages and holds cryptographic keys tied to system state integrity.

What it doesn’t do: It does not fix vulnerable software by itself. It records each boot stage, so a modification can be detected through attestation or sealed keys.

2. Secure Boot

Ensures that the platform only executes signed, cryptographically approved firmware binaries and bootloaders. Unified Extensible Firmware Interface (UEFI) Secure Boot is the baseline implementation for modern control systems.

Reference: For a deep dive into implementing UEFI Secure Boot in industrial environments, see Report 3 of this series, UEFI in OT: Hardware Trust, Secure Boot & CE Marking.

3. Firmware SBOM (Bill of Materials)

A comprehensive Firmware SBOM details embedded sub-components, third-party libraries, and microcode built into a device's binary image. The CRA requires manufacturers to draw up an SBOM covering at least the top-level dependencies, so a firmware SBOM that goes deeper is a key part of operational vulnerability management.

4. Cryptographic Update Verification

Supply chain risk extends past initial procurement. Every firmware update is a potential attack vector. A defensible posture requires cryptographic signature verification of update packages, documented vendor change notifications, and strict change-control authorization prior to deployment on operational assets.

 

The Legacy OT Problem

Many critical infrastructure operators are running legacy OT hardware that cannot support modern firmware security controls.

A 15-year-old PLC or a remote wind turbine controller does not have a TPM 2.0 chip. It cannot execute UEFI Secure Boot, and the original vendor may no longer exist or support updates.

The gap does not make compliance impossible, but it requires a strategic pivot toward compensating controls:

Strict Network Isolation: Restricting legacy devices behind micro-segmented conduits to reduce blast radius.

Passive Deep-Packet Inspection: Monitoring network protocols for abnormal payload behavior, serving as a secondary proxy since on-device firmware verification isn’t supported.

Documented Risk Acceptance: Formally recording technical limitations alongside implemented compensating measures to present during BSI audits.

The goal for legacy OT is a documented, defensible operational position, not unachievable perfection.

What to Do Now

If you are responsible for NIS2 and CRA compliance within an industrial or utility organization, network policy alone won’t close this gap.

Inventory Firmware Details: Immediately move beyond IP addresses and hardware model numbers. Record exact firmware versions, vendor signatures, and build numbers across all critical-infrastructure-relevant assets. Document whether each system supports cryptographic verification or lacks update capability entirely.

Establish Verification Gates: For systems that support signed firmware, implement strict pre-update verification workflows. Require cryptographic signature checks, formal authorization logs, and post-installation validation before any update touches components.

Document the Legacy Gap: Identify all legacy OT assets lacking hardware roots of trust or Secure Boot support. Build formal compensating control packages for these assets as soon as possible. In Germany, for example, BSI auditors can demand precisely this during evaluations.

Commission Independent Firmware Assessments: NIS2 Article 21 and, for operators of critical facilities, § 39 BSIG place heavy emphasis on audit-ready evidence. Commission independent security assessments of critical device firmware to validate that vendors are delivering untampered code. If an auditor or regulator raises this question before you do, that’s a much harder conversation to have. Getting ahead of it now is the easier path.

Track CRA Procurement Deadlines: Demand Firmware SBOMs and software transparency documentation from prospective vendors now so your procurement pipeline is aligned before mandatory enforcement takes hold in December 2027. 

 

Final Thought

The perimeter compliance model was built for a simpler era of OT. The technical capabilities for verifying execution integrity at the silicon layer exist today, and the regulatory mandates under NIS2, the CRA, and § 30 BSIG point toward it. For critical infrastructure operators, the question is whether to build a defensible baseline now, on your own terms, or wait for an auditor’s finding or a grid incident to force the answer.

 

Sources and Further Reading

Sandra Weiss
Next

FERC's 2026 CIP Lessons Are an AI Change-Control Warning