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

Policy Pulse
Written By Sandra Weiss

BY SANDRA WEISS

The Gap Between Two Clocks

European critical infrastructure operators find themselves caught between two regulatory timelines moving at very different speeds.

On one side, supply chain obligations under the revised Network and Information Security Directive (NIS2) are already in force. Regulated entities must demonstrate right now that they know what code is running across their environments and that every software and firmware layer comes from a verifiable, documented source.

On the other side stands the Cyber Resilience Act (CRA). Its mandatory CE marking and conformity assessment requirements for hardware manufacturers do not take full effect until December 2027.

The Unified Extensible Firmware Interface (UEFI) firmware running on the vast majority of industrial PCs, human-machine interfaces (HMIs), and edge gateways across Europe today was designed, shipped, and integrated long before either clock started ticking. It was not CE-marked under cyber regulations. It usually has no Software Bill of Materials (SBOM). The Secure Boot keys are frequently vendor defaults. In 2024, Binarly's PKfail research found untrusted test Platform Keys in nearly 900 device models.

This report addresses the ground operators are standing on today: how the low-level UEFI trust chain actually operates, where it breaks down under real-world operational technology (OT) conditions, and how to bridge the compliance gap before the 2027 enforcement cliff arrives.

UEFI and Secure Boot

UEFI is the firmware that runs before your operating system (OS) does, at a privilege level that lets it override anything built on top of it, including endpoint detection, logging, and the OS kernel itself. Secure Boot is supposed to guarantee that only trusted code loads at that layer. In practice, that guarantee breaks down through shared default vendor keys, Secure Boot disabled for legacy compatibility and never re-enabled, and pre-boot environments that go unpatched for years because updating them means taking a production line offline.

Note that “Secure Boot Enabled” in your Basic Input/Output System (BIOS) setting does not mean “Secure Boot Enforcing”. If the firmware itself is unpatched or trusts a revoked certificate, the gate is open regardless of what the setting says.

 

The CRA CE Marking Chain

The CRA restructures supply chain liability across three distinct layers. Understanding how liability flows through this chain is essential for procurement teams and equipment manufacturers alike.

Obligation by Layer

UEFI / Chip Vendors: A component supplier that places its own product on the EU market carries its own CRA obligations as a manufacturer. Otherwise, the duty sits with the OEM, which must exercise due diligence when integrating third-party components (Article 13(5)). In practice, OEMs need SBOMs, vulnerability documentation, and signed update channels from their suppliers to meet that duty, and will often write those requirements into supply contracts.

OEMs (Equipment Manufacturers): The OEM carries primary CRA product liability. The CE mark on the chassis represents the OEM’s formal declaration that the entire assembled product, including the third-party UEFI code running on the motherboard, meets CRA essential cybersecurity requirements. Outsourcing hardware manufacturing or buying off-the-shelf BIOS code does not shift the liability. If an OEM’s logo is on the box, they carry full legal responsibility.

Operators: Operators can use the OEM's CE mark as supporting evidence of supply chain due diligence. However, under NIS2 Article 21(2)(d), CE marking does not absolve the operator. In practice, operators remain responsible for verifying that updates are applied, default keys are rotated, and configuration baselines are enforced.

The Validation Requirement

An OEM cannot simply forward a chip vendor's documentation downstream. Under CRA Article 13(5), OEMs must exercise due diligence when integrating third-party components, so that integrated UEFI modules do not compromise the product's cybersecurity, before issuing their EU Declaration of Conformity.

 

The Enforcement Gap: 2026 Reality vs. 2027 Conformity

The Current Enforcement Landscape (2026):
NIS2 Obligations: Germany's NIS2UmsuCG has applied since 6 December 2025, and its registration deadlines have passed. Other member states transposed NIS2 on their own timelines. NIS2 does not name UEFI or firmware specifically, but its supply chain risk management requirements (Article 21(2)(d)) are broad enough that operators are already subject to regulatory audit on how they verify the integrity of components they source, including firmware and pre-boot code.

CRA Reporting:
Since September 11, 2026, manufacturers have had to send an early warning within 24 hours of becoming aware of an actively exploited vulnerability under CRA Article 14.

The Window to December 2027:
Full CRA product conformity assessment becomes mandatory for new products placed on the EU market in December 2027. 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. A Notified Body is an independent organization officially accredited by an EU member state to test and certify products against CRA requirements.

 

The Global Frame: Why NERC CIP and the CRA Differ

When evaluating supply chain standards, European operators frequently look to the North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) standards as a benchmark for regulatory maturity. However, on hardware-rooted trust and pre-boot security, the European regulatory framework goes further on manufacturer obligations.

Dimension NERC CIP-010 / CIP-013 CRA (Annex I)
Firmware scope Treated as general software under configuration baselines. Covered as part of the product, with essential requirements applying to the whole product.
Secure Boot requirement No explicit enforcement requirement. Not named. Integrity protection is required as an outcome, and the mechanism is left to the manufacturer.
Hardware root of trust Not mandated, with no Trusted Platform Module (TPM) or silicon requirement. Not named. The manufacturer chooses the mechanism.
UEFI component SBOMs Software integrity verification required, with no sub-component UEFI granularity. An SBOM is required, covering at the very least the top-level dependencies.

Technical Comparison

NERC CIP-010 focuses on documenting software/firmware revision numbers and controlling change windows. It treats firmware as a static string in an asset database.

NERC CIP-013 obligates entities to establish supply chain risk management plans and verify software integrity prior to installation, but it does not specify hardware-rooted boot validation protocols.

The Takeaway

While NERC CIP remains a mature framework for operational change management and audit culture, it does not mandate silicon-level execution trust. European operators cannot assume that US-focused OT vendor offerings will automatically satisfy EU requirements. The CRA may well shape engineering baselines beyond the EU for hardware security.

Strategic Action Plan for OT Engineers & Procurement Teams

Three structural hurdles have emerged:

  • For OEMs (The Assessment Bottleneck): Notified Body assessments for complex industrial hardware take considerably longer than self-assessment. OEMs that have not finalized their UEFI supply chain documentation and hardware security architecture will face severe market entry delays come December 2027. Starting the assessment process early is the most effective way to reduce the risk this bottleneck produces.

  • For Procurement Teams (for 15 years or more): OT equipment purchased today may remain in active field service through 2040. Buying industrial PCs or HMIs in 2026 without explicit CRA readiness roadmaps forces operators to carry unmaintainable supply chain risk for over a decade.

  • For Supply Chain Lifecycle Support: The CRA requires a support period of at least five years, and each security update must remain available for at least 10 years after it is issued. Many legacy OT hardware suppliers lack the technical infrastructure to sign, deliver, and verify UEFI updates for the full support period.

To bridge the enforcement gap between current NIS2 obligations and upcoming CRA requirements, engineering and procurement teams should execute the following technical measures:

For OT Engineering Teams

1. Conduct an Explicit UEFI Audit: Expand current asset management programs beyond the OS layer. For every HMI, industrial PC, engineering workstation, and edge gateway, document:

  • UEFI vendor, build version, and patch date

  • Secure Boot state (Disabled, Enabled (Default Keys), or Enforcing (Custom Keys))

  • Revocation list (dbx) state to ensure known vulnerable bootloaders are blocked 

2. Actively Test Secure Boot Enforcement: Do not rely on physical BIOS setup screen readings alone. Use platform management tools or OS-level query interfaces to confirm that the pre-boot environment is actively enforcing signature checks and rejecting unsigned code.

3. Establish a Dedicated UEFI Patching Process: Treat UEFI updates with the same rigor as production control logic changes. Test vendor-signed UEFI updates on dedicated staging hardware before deployment, verify binary signatures, and maintain audit logs of all pre-boot flash operations.

4. Verify Immediate Vendor CRA Reporting Readiness: Contact your primary OT hardware suppliers to verify whether they have established their Product Security Incident Response Team (PSIRT) and CRA Article 14 intake channels. That mandatory 24-hour vulnerability reporting deadline took effect September 11, 2026. If a vendor cannot explain how they are currently handling zero-day UEFI disclosures, that gap becomes your NIS2 supply chain liability to manage, worth resolving before it becomes an audit finding.

For Procurement Teams

1. Insert CRA Conformity Roadmaps into Requests for Proposals (RFPs): Make CRA compliance an explicit, scored evaluation criterion for all new OT hardware purchases. Require vendors to submit written answers to the following:

  • What is your documented timeline for issuing CRA EU Declarations of Conformity?

  • How will UEFI component SBOMs be generated and delivered?

  • What is your technical process for delivering signed UEFI updates for the full support period?

2. Require Vendor Key Customization Capabilities: Ensure that incoming industrial PCs allow the enterprise to manage and enroll its own Platform Keys (PK) and Key Exchange Keys (KEK), rather than locking the hardware permanently to shared factory default keys.

3. Audit OEM Notified Body Engagement: For Class II products, ask OEMs directly if they have initiated the conformity assessment process with a designated European Notified Body. If a vendor supplying critical infrastructure hardware has not begun this process, they represent an unmanaged supply chain risk to your organization.

 

Summary

Securing the boundary between information technology (IT) and OT requires validating the very first lines of code executed when power hits the silicon. As NIS2 enforces active supply chain oversight and the Cyber Resilience Act establishes legal liability for hardware manufacturers, European operators must ensure their pre-boot environments are known, verifiable, and actively enforced. By auditing UEFI configurations today and embedding CRA requirements into current procurement pipelines, OT security teams can establish hardware-rooted trust across their critical assets.

 

Sources and Further Reading

Sandra Weiss
Next

Firmware and Bootloader: The Verification Gap in OT Infrastructure