The Execution Layer Gap: Why European Critical Infrastructure May Be Looking at the Wrong Regulatory Clock

The Execution Layer GapPolicy Pulse
Written By Sandra Weiss

BY SANDRA WEISS

The December 2027 Illusion

Many European critical infrastructure operators believe they have until December 2027 to comply with the Cyber Resilience Act (CRA) compliance deadline. That date is real, and an earlier obligation already applies.

On September 11, 2026, mandatory vulnerability reporting under CRA Article 14 took effect across the European Union. From that date, manufacturers of products with digital elements must notify actively exploited vulnerabilities and severe incidents to the European Union Agency for Cybersecurity (ENISA) and the national Computer Security Incident Response Team (CSIRT) designated as coordinator, starting with an early warning within 24 hours. Under Article 69(3), this reporting obligation also covers products placed on the market before December 11, 2027, including hardware already deployed in the field.

If a manufacturer’s Software Bill of Materials (SBOM) tracking and vulnerability management infrastructure was not fully operational by September 11, compliance is now likely to be very difficult, regardless of corporate intent

The industrial operators and hardware vendors who navigated September successfully share one trait. They treated firmware-layer verification as infrastructure and not an afterthought.

This series examines why regulators are taking special interest in the execution layer, the hardware and bootloader code running beneath your operating system, and how to close the gap before the compliance deadline turns into an enforcement conversation.

 

The Layer You May Have Skipped

Over the last decade, European critical infrastructure operators have invested heavily in hardening physical and logical perimeters. They installed industrial firewalls, established strict network segmentation, deployed security information and event management (SIEM) platforms built for operational technology (OT), and drafted comprehensive incident response handbooks. That investment was necessary, and its operational benefits are visible.

What that perimeter investment does not, and unfortunately cannot, protect is the code executing below the operating system layer.

Firmware and the bootloader both run before the operating system and before endpoint security controls start, and UEFI establishes the hardware root of trust before a single system event log is written. If any component within these low-level execution environments is compromised, whether through a tampered vendor update, a backdoored supply chain component, or an unverified pre-boot driver, the attack executes inside the security perimeter with absolute system privilege.

To a perimeter firewall or network intrusion detection sensor, malicious activity operating at the silicon layer appears valid, authorized hardware instructions. The firewall doesn't see it, and the SIEM doesn't log it.

Both NIS2, specifically Article 21, and the Cyber Resilience Act reach into this layer, NIS2 through its supply chain and system maintenance measures, and the CRA through security requirements on the products themselves. European regulators are now asking questions that traditionally network-centric compliance programs cannot answer:

  •   What specific firmware versions are executing on your deep-field programmable logic controllers (PLCs) and industrial personal computers (IPCs)?

  •  When was that code last cryptographically verified against a trusted baseline?

  • Where did those hardware components at the silicon layer originate?

  • Can you empirically prove that the vendor who supplied them maintains secure build environments?

If you can’t answer these with confidence right now, you’re not alone. The rest of this report shows you how to get there.

 

The Regulatory Moment

In 2026, three distinct regulatory clocks are running simultaneously, and all three converge directly at the execution layer.

Clock 1: German NIS2 Implementation Act (NIS2UmsuCG), Active Now

In Germany, the legal framework is not a future prospect. Under § 30 of the German Act on the Federal Office for Information Security (BSIG), risk management obligations, including supply chain security, are active and legally binding today. For particularly important entities, the Federal Office for Information Security (BSI) does not need an active breach or operational outage to initiate a technical audit. The regulatory mandate is active right now.

Clock 2: CRA Article 14, Active Now

As of September 11, 2026, manufacturers marketing connected hardware or software within the EU must report actively exploited vulnerabilities to ENISA and national CSIRTs with an early warning due within 24 hours. For critical infrastructure operators, this creates an immediate supply chain filter. If your primary OT hardware suppliers lack functional Product Security Incident Response Teams (PSIRTs) capable of meeting Article 14 disclosure obligations, retaining those vendors may leave a gap in your NIS2 supply chain coverage.

Clock 3: Full CRA Conformity, December 11, 2027

By late 2027, every new product with digital elements placed on the EU market must bear CE marking confirming CRA compliance. Class II important products, such as firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers, will require third-party conformity assessment by a Notified Body. Because third-party conformity assessment takes considerably longer than self-assessment, hardware manufacturers and procurement teams who have not yet initiated baseline assessments are already behind schedule.

Operators who treated September 2026 as the real baseline are now ahead of those who planned around December 2027.

 

What This Series Covers

This deep-dive series breaks down the execution layer gap across four core technical dimensions, concluding with an actionable blueprint for enterprise leadership.

Report 2
Firmware and Bootloader: The Verification Gap in OT Infrastructure

This report examines the verification paradox and shows the practical controls that close it. Cryptographic controls can verify that a firmware image was not tampered with during transport, but they say nothing about what vulnerabilities were built into the code at compile time. Our report details the technical controls available to verify bare-metal PLC and remote terminal unit (RTU) integrity, compares NIS2 Article 21 requirements against CRA Article 13 obligations, and analyzes lessons from North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) enforcement in the US energy sector.

Report 3
UEFI in OT: Hardware Trust, Secure Boot & CE Marking

Focusing on industrial PCs, human-machine interfaces (HMIs), and edge gateways, this piece explores the pre-boot execution layer where UEFI operates before the operating system loads. It maps the complex CE marking responsibility chain stretching from silicon vendors to original equipment manufacturers (OEMs) and operators, reviews real-world Secure Boot bypass vulnerabilities, and details what September 2026 and December 2027 mean for procurement teams making capital hardware investments today. Each finding translates directly into what your procurement and audit teams need to check before the deadline.

Report 4
Supply Chain Trust: Verified Source, Unknown Origin

A cryptographically signed firmware package originating from a compromised or state-controlled vendor will pass every local integrity check. This report presents a quantitative methodology for building vendor risk profiles using empirical datasets like the ICS Advisory Project. It examines how to satisfy § 30 BSIG audit scrutiny and analyzes how the EU's 5G Toolbox high-risk vendor framework is reshaping OT procurement decisions.

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

This report explains why the perimeter-focused defense model is incomplete. If malicious or modified code runs inside your hardware, external firewalls and network monitoring tools cannot detect the breach. The report maps out what NIS2 Article 21 technical measures actually mandate at the silicon level and defines what an audit-defensible technical baseline looks like in practice.

Report 6
From Analysis to Action: Building Your OT Firmware Security Program

The concluding report provides a structured, four-track execution framework designed for Chief Information Security Officers (CISOs), Managing Directors, and Procurement Leads. It translates the technical findings into a concrete 30-day action plan, outlines the specific risk acceptance decisions that warrant formal board sign-off, given managing directors’ personal liability under § 43 of the German Limited Liability Companies Act (GmbHG), and presents a roadmap to maintain BSI audit readiness while preparing for CRA conformity.

 

Who Should Read This Series

This series is written for two audiences at once, the engineers configuring the systems and the executives accountable for them.

This Foundation report is for any leader who needs to understand why the execution layer now matters so much for industrial security, before moving on to the technical or operational reports.

 

Closing

European regulators and national auditing authorities are no longer stopping at firewall rule sets and network topology diagrams. They are looking beneath them and asking direct, technical questions about what code is executing on your silicon, where it originated, whether you can cryptographically verify its integrity, and whether you can legally defend your trust in the vendor who provided it.

 With the September 11 deadline now behind us, now is the time to move forward if you have not done so already. Critical infrastructure operators who close the execution layer gap through structured, documented programs will spend less time reacting to unannounced BSI audit findings and more time running the resilient physical systems their communities depend on.

The remainder of this series provides the blueprint for critical infrastructure operators who need to build that posture.

 

Sources and Further Reading

Sandra Weiss
Previous

Firmware and Bootloader: The Verification Gap in OT Infrastructure
Next

One Incident, Several Reports: What GAO's Panel & CISA's Town Halls Say About Harmonization [Updated]