Supply Chain Trust: Verified Source, Unknown Origin

Policy Pulse
Written By Sandra Weiss

BY SANDRA WEISS

Trusted Packages Carrying Untrusted Intent

Reports 2 and 3 established how operators can cryptographically prove that a firmware binary or Unified Extensible Firmware Interface (UEFI) bootloader was not altered in transit. However, those technical controls leave a fundamental vulnerability unaddressed. Cryptographic verification confirms what was delivered, but does not confirm that the contents are not malicious.

For example, a cryptographically signed firmware image from an original equipment manufacturer (OEM) whose software development environment was compromised, whose component sourcing is opaque, or whose update infrastructure operates under state-compelled access obligations will pass every technical inspection.

A primary threat to operational technology (OT) supply chains is the delivery of trusted packages carrying untrusted intent.

This report shows you how to close that gap, moving beyond mathematical verification to evaluate supplier transparency, geographic manufacturing dependencies, and vulnerability management practices in a way that holds up under audit.

 

The Verification Paradox

The OT community faces an architectural limitation.
Every tool in the standard verification suite (SHA-256 hashing, UEFI Secure Boot, Trusted Platform Module (TPM) 2.0 PCR measurements, and remote attestation) validates the integrity of the payload. None of them validate the trustworthiness of the vendor.

If a state-sponsored actor compromises a vendor’s software build server, steals their code-signing certificates, or legally mandates access to a vendor’s source code, the resulting malicious firmware update is fully authentic from a cryptographic perspective. The hash matches the vendor’s database, the signature validates against the platform key, and the TPM extended registers approve execution.

The SolarWinds Model in OT

This paradox was demonstrated at scale during the SolarWinds Orion supply chain attack. The compromised software update was not intercepted or altered on the network. It was compiled, signed, and distributed directly from the legitimate vendor’s build environment.

In industrial environments, where human-machine interfaces (HMIs), engineering workstations, and programmable logic controllers (PLCs) operate with direct physical process authority, a build-pipeline attack grants the adversary immediate control over physical process logic while bypassing most security tools.

 

The Regulatory Framework: EU Legal Mandates

European cyber regulations explicitly require operators to evaluate supply chain relationships beyond basic product checks.

Network and Information Security Directive (NIS2), Article 21(2)(d)
Mandates that essential and important entities address supply chain security, explicitly including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. Article 21(3) adds that entities must take into account the quality of their suppliers' products and cybersecurity practices.

Cyber Resilience Act (CRA) Articles 13 & 14
Requires manufacturers to handle vulnerabilities systematically throughout the product lifecycle. A vendor’s ability to maintain a functional Product Security Incident Response Team (PSIRT), generate machine-readable Software Bills of Materials (SBOMs), and send an early warning of actively exploited vulnerabilities within 24 hours under Article 14 is a mandatory prerequisite for CRA compliance.

The 5G Toolbox Precedent in Industrial OT
The EU's 5G Toolbox, agreed by member states in 2020, recommends assessing suppliers on non-technical risk factors, such as state influence, and restricting or excluding high-risk suppliers from key network assets. The Toolbox itself is a set of recommendations. In January 2026, the European Commission proposed a revised Cybersecurity Act that would make the derisking of mobile networks from high-risk suppliers mandatory and set up a wider ICT supply chain security framework for NIS2 sectors, including energy. The proposal is still going through the legislative process.

§ 30 BSIG Requirements
Under German national implementation, § 30 requires supply chain security measures, and in an audit, operators will need to show how they assessed their suppliers. Using empirical datasets (such as the ICS Advisory Project) to evaluate supplier PSIRT maturity can support audit-ready compliance evidence for national authorities.

 

The Geopolitical Layer & High-Risk Geographies

European regulations address build-level risk using objective operational criteria instead of directly naming specific nation-states. NIS2 Article 21(2)(d) requires operators to evaluate supplier relationships. The EU’s 5G Toolbox framework establishes the concept of high-risk vendor dependencies in critical infrastructure. Although EU regulation deliberately avoids naming specific countries, geography still matters operationally: a vendor’s country of origin or primary manufacturing jurisdiction becomes an operational risk factor when local legislation:

1. Compels companies to assist state intelligence services without public warrant processes or judicial oversight.

2. Requires vendors to provide state agencies with access to administrative update channels, source code, or decryption keys.

3. Prohibits vendors from disclosing state-mandated vulnerabilities or security access mechanisms to international customers.

The Operational Example: Grid-Scale BESS

This risk category is already active across European energy infrastructure. Grid-scale Battery Energy Storage Systems (BESS) depend on high-power inverter units and battery management systems (BMS) frequently manufactured in jurisdictions with state-compelled access laws.

Even if an inverter’s firmware update passes cryptographic checks, the continuous remote management interface required for grid balancing creates a persistent control vector. If the vendor’s home jurisdiction mandates access, the remote interface could become an unmanaged point of operational failure for the power grid.

 

Using ICS Advisory Data for Vendor Risk Assessment

Security teams can use datasets like the ICS Advisory Project, which correlates US Cybersecurity and Infrastructure Security Agency (CISA) advisories, vendor PSIRT disclosures, and vulnerability databases, to build an objective risk profile.

1. Interpreting the Advisory Count Correctly

A high number of published advisories does not equal a low-quality product. Major OT vendors maintain mature PSIRTs and proactive bug-bounty programs. High advisory volume from these vendors reflects systematic code auditing and transparent disclosure.

Conversely, an established OT vendor with zero published advisories over several years may present a significant risk signal. It could indicate either a complete lack of internal security research or a policy of undisclosed vulnerability patching.

2. The ~78% Visibility Gap (2025)

According to ICS Advisory Project data analyzed by Forescout, only 22% of the OT and industrial control system (ICS) vulnerabilities published by vendors and CERTs in 2025 had an associated CISA ICS Advisory (ICSA), down from 58% in 2024. Organizations relying solely on CISA advisories are likely missing a substantial share of relevant vulnerability disclosures for their installed base.

3. Core Evaluation Metrics

Metric What it measures What it may signal
Patch velocity (advisory-to-patch ratio) Days between public Common Vulnerabilities and Exposures (CVE) disclosure and official patch availability. Extended delays may indicate poor software maintenance processes or low prioritization of industrial security.
Severity distribution The share of critical flaws under the Common Vulnerability Scoring System (CVSS 9.0+), especially unauthenticated remote code execution without available workarounds. A high concentration may signal weak initial design security.
Known Exploited Vulnerabilities (KEV) correlation Vendor advisories cross-referenced against CISA's KEV catalog. A vendor with vulnerabilities exploited in the wild that lacks immediate patch guidance can represent an active operational risk.
Manufacturing dependency mapping Where hardware components are fabricated, compared with where the vendor is headquartered. A European-branded PLC containing silicon, microcode, and firmware from a high-risk jurisdiction inherits that jurisdiction's risk profile.


Comparative Analysis: NERC CIP-013 vs. EU Framework

NERC CIP-013 Limitations

The North American Electric Reliability Corporation’s Critical Infrastructure Protection standard CIP-013 (Supply Chain Risk Management) requires utilities to evaluate vendor risk, control remote access, and verify software integrity before installation.

However, CIP-013 was designed primarily to prevent unauthorized modifications to legitimate software binaries. It does not contain explicit provisions for:

  • Excluding vendors based on national jurisdiction or state-compelled access laws.

  • Evaluating vendor PSIRT patch velocity and disclosure transparency.

  • Auditing sub-tier component manufacturing origins.

The European Paradigm

 The European regulatory stack addresses both technical integrity and systemic trust. By combining product-level transparency (CRA SBOMs) with supplier risk assessments (NIS2 Article 21), EU regulations provide a stronger basis for managing nation-state supply chain risk.

 

Vendor Risk Assessment & Executive Decision Framework

To operationalize these requirements, executive teams should implement a three-tiered assessment matrix.

Tier Focus What to assess
Tier 1 Transparency & PSIRT maturity Visibility into software and firmware components, vulnerability disclosure protocols, and patch responsiveness.
Tier 2 Geographic & manufacturing dependency Supply chain origin, geopolitical risk, and sovereign component dependencies.
Tier 3 Contractual & regulatory commitments Legally binding compliance under frameworks like the CRA or NIS2, liability allocation, and enforceable service level agreements (SLAs) for security updates.

Operational Decision Guidance & Executive Sign-Off

When an essential vendor fails Tier 1 or Tier 2 metrics but cannot be replaced due to operational or sole-source constraints, the organization must initiate a formal Risk Acceptance Protocol:

1. Compensating Controls Definition:
Enforce strict physical air-gapping, disable remote management interfaces, restrict inbound/outbound network traffic via unidirectional security gateways (data diodes), and implement passive protocol anomaly monitoring.

2. Formal Documentation:
Record the precise technical risk, the operational necessity for retaining the vendor, the compensating controls deployed, and a mandatory 12-month re-evaluation schedule.

3. Executive Management Sign-Off:
Risk acceptance for Tier 2 failures on critical OT assets cannot be delegated to information technology (IT) staff or external contractors. It requires formal, signed approval from the Managing Director / Board. Under § 38(2) BSIG, which refers to company law such as § 43 of the German Limited Liability Companies Act (GmbHG), managing directors are liable to their organization if they fail to implement and monitor these risk management measures.

 

Summary

Resilience requires evaluating the entire supply chain, from the jurisdiction where code is written to the transparency of the vendor’s vulnerability disclosures. By combining low-level execution controls with rigorous supplier risk assessments, OT operators can establish a defensible, audit-ready operational security posture.

 

Sources and Further Reading

Sandra Weiss
Next

Would an OT Directive Make CISA an OT Regulator?