Software Supply Chain Security for Manufacturing and OT: A 90-Day Plan

Software supply chain security in manufacturing means knowing which software components run in your plants, who supplied each one, which of them carry known vulnerabilities, and how you will fix or contain them without stopping a line. For the software you build (MES extensions, historian connectors, edge apps) you generate and maintain SBOMs and fix dependencies yourself. For the software you buy (SCADA, HMI, PLC engineering tools, controller firmware) you require SBOMs, advisories and patch commitments from vendors, then track them against your own inventory.

ISA/IEC 62443 ties this together for industrial automation, and CISA and NIST guidance, SEC disclosure rules and the EU Cyber Resilience Act push the same way. This guide covers the software a plant runs, the rules and dates, six public incidents from the last three years, who owns each part, and a 30/60/90-day plan that works with the tools you have today.

Key takeaways

• Plants run enterprise IT (ERP, PLM, quality), operations software (MES, historians, SCADA and HMI) and control software (PLC and controller firmware, drives, safety systems). Open source sits in all three, most visibly in Linux gateways, HMI panels, edge containers and MES web front ends.
• ISA/IEC 62443 is the anchor: part 2-1 for the asset owner's program, 2-4 for integrators, 3-3 for system requirements and 4-1 for how product suppliers manage third-party components.
• CISA's Secure by Demand guide for OT buyers (13 January 2025) asks buyers to seek manufacturers who include a hardware and software bill of materials with product delivery. CISA's 2026 Minimum Elements for an SBOM (29 July 2026) replaced the 2021 NTIA document.
• Listed US manufacturers file Form 8-K Item 1.05 within four business days of deciding an incident is material, and recent filings show IT incidents halting production.
• The EU Cyber Resilience Act's reporting obligations have applied since 11 September 2026; main obligations apply from 11 December 2027.
• Safeguard capabilities in this guide, all GA: SBOM generation and analysis, software composition analysis and vulnerability management with EPSS and KEV, Third-Party Risk Manager (TPRM), CSAF and VEX upload, the compliance and GRC suite with IEC 62443 mapping, policies and gates (Block, Warn, Notify), the CLI and local runner, air-gapped and on-prem deployment with Zero AI mode, and autonomous remediation with Griffin fix pull requests (ships switched off, every category set to Manual).

The situation

The trigger in manufacturing rarely arrives as a regulation. It arrives as a large customer's questionnaire asking for IEC 62443-4-1 evidence and an SBOM for the controller you sell them; an EU distributor asking how you meet the Cyber Resilience Act; or a board that has just read about a peer's plant shutdown and asks how long it would take to know which lines and products contain a backdoored open source library.

A bad week looks like this. A critical vulnerability lands on Monday in a component that ships inside several vendor products. IT security clears the corporate laptops within hours. Nobody can answer for the plant floor, because the OT asset list records hardware models and firmware versions but not the open source libraries inside them. Vendors answer at different speeds, some with a CSAF advisory, some by email, some not at all. By Friday the CISO is still reporting "under investigation". The rest of this guide is about making that week shorter.

What software a manufacturer actually runs

Before rules or tools, map the software. The Purdue style split between enterprise, operations and control is still the most useful way to think about it, even where the layers have blurred.

Three points follow. You build more software than you think: MES extensions, line dashboards, historian to cloud pipelines and ERP integrations all have dependencies, and machine builders ship software inside their equipment. You buy most of the software that matters for safety: you cannot rebuild PLC firmware or a SCADA platform, so your levers are procurement terms, vendor transparency (SBOMs, advisories, VEX), testing and compensating controls. Open source crosses the layers: the same library can sit in a corporate web app, an MES server and an HMI panel, so "where else is this?" spans IT and OT.

That gives you two columns, and most programs fail by applying one to the other:

The regulations and frameworks that apply

This section summarises primary sources as of 25 October 2026. It is not legal advice; confirm what applies to your company with counsel, and check each source for updates.

ISA/IEC 62443: the anchor standard for industrial automation

ISA describes the ISA/IEC 62443 series as defining requirements and processes for implementing and maintaining electronically secure industrial automation and control systems (IACS). The parts that matter most for software supply chain work, with the editions ISA lists today:

• Part 2-1 (ANSI/ISA-62443-2-1-2024): security program requirements for IACS asset owners, the plant operator's program.
• Part 2-3 (ISA-TR62443-2-3-2015): a technical report on patch management in the IACS environment.
• Part 2-4 (ANSI/ISA-62443-2-4-2018): security program requirements for IACS service providers, which covers the integrators who build and maintain your systems.
• Part 3-3 (ISA-62443-3-3-2013): system security requirements and security levels.
• Part 4-1 (ANSI/ISA-62443-4-1-2018): secure product development lifecycle requirements for product suppliers.
• Part 4-2: technical security requirements for IACS components.

ISA also lists a 2025 technical report on IACS security protection schemes (part 2-2), covered in IEC 62443-2-2 security protection schemes.

The 62443 texts are sold by ISA and IEC, so we do not quote them. The clause references most often used for software supply chain evidence are part 3-3 SR 7.8 (control system component inventory), SR 3.4 in part 3-3 and CR 3.4 in part 4-2 (software and information integrity), and part 4-1 practices SM-9 (externally provided components) and SM-10 (custom and third-party components). Check them against your licensed copy before citing them to an auditor or customer. In short: asset owners are expected to know their components and manage patches with suppliers, and product suppliers are expected to identify and manage the third-party and open source components in what they ship.

NIST SP 800-82 Rev. 3

NIST published SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, in September 2023, superseding Rev. 2 from 2015 and widening the scope from industrial control systems to OT in general. It covers OT topologies, common threats and vulnerabilities, and recommended countermeasures. NIST has since released the initial public draft of Revision 4, with comments due by 30 November 2026. Rev. 3 is the current final text.

CISA Secure by Demand for OT buyers (13 January 2025)

CISA and partner agencies from the US, Australia, Canada, Germany, the Netherlands, New Zealand, the UK and the European Commission published Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products on 13 January 2025. It lists twelve elements for buyers of OT products: configuration management, logging in the baseline product, open standards, ownership, protection of data, secure by default, secure communications, secure controls, strong authentication, threat modeling, vulnerability management, and upgrade and patch tooling.

Two are direct software supply chain asks. Under vulnerability management, buyers should seek manufacturers who include a hardware and software bill of materials with product delivery, commit to timely remediation through a vulnerability disclosure program, and define a support period during which patches are supplied free of charge. Under upgrade and patch tooling, buyers should look for a documented patch process, patches that can be verified, and support for owner-controlled patch management. The guide also points buyers to ISA/IEC 62443 and NIST SP 800-82. It is the most practical free procurement checklist for OT software today.

CISA OT asset inventory guidance (13 August 2025)

CISA's Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators describes an asset inventory as an organised, regularly updated list of an organisation's systems, hardware and software, paired with an OT taxonomy that categorises and prioritises assets. Software belongs in the inventory, not only device models.

CISA 2026 Minimum Elements for an SBOM (29 July 2026)

CISA, NSA, FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials, which updates and replaces the minimum elements NTIA published in 2021 and applies to all software. Cite the 2026 document in OT purchase contracts, not the 2021 one; our older NTIA minimum elements guide explains the history.

SEC cybersecurity disclosure rules

On 26 July 2023 the SEC adopted rules requiring registrants to disclose material cybersecurity incidents on Form 8-K Item 1.05, generally within four business days of determining materiality, and to describe cyber risk management and governance annually under Regulation S-K Item 106. The 8-K requirement began on 18 December 2023 for most registrants. For a listed manufacturer, knowing quickly which plants and products contain an affected component feeds the materiality decision.

EU rules, as context for exporters and EU plants

The European Commission states that the Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024, that reporting obligations apply from 11 September 2026, and that the main obligations apply from 11 December 2027. If you sell controllers, HMIs, gateways or industrial software into the EU, you are a manufacturer under the Act, and EU customers will pass its expectations back to you in contracts; see EU CRA SBOM obligations. The Commission's NIS2 page lists critical product manufacturing among the sectors added beyond the original directive, with national transposition due by 17 October 2024, so EU plants may fall under national NIS2 laws.

Defense suppliers also face CMMC and automotive suppliers face UNECE rules; see defense industrial base supply chain and CMMC and automotive cybersecurity under UNECE WP.29.

What each source asks for, side by side

Real public incidents from the last three years

These six incidents come from official advisories and company filings. We describe only what the sources say, and we draw no conclusions about what any named organisation should have done.

November to December 2023: PLCs and HMIs defaced across sectors

Joint advisory AA23-335A, first published 1 December 2023 and since updated by the FBI, CISA, NSA, EPA, the Israel National Cyber Directorate and Canadian and UK partners, reports that from November 2023 cyber actors affiliated with Iran's Islamic Revolutionary Guard Corps, using the persona "CyberAv3ngers", compromised Unitronics Vision Series PLCs and HMIs. The advisory says these PLCs are used in water systems and other industries including food and beverage manufacturing, and may be rebranded under other manufacturers' names. The update describes actors replacing ladder logic, resetting software to older versions and disabling upload and download functions.

Because the advisory notes rebranding, an asset list keyed on brand names can miss affected equipment; the actual component and software version answer "do we have this?"

29 March 2024: the XZ Utils backdoor (CVE-2024-3094)

CISA reported on 29 March 2024 that malicious code had been embedded in XZ Utils versions 5.6.0 and 5.6.1, a data compression library that may be present in Linux distributions, and recommended downgrading to an uncompromised version such as 5.4.6 Stable and hunting for malicious activity. Embedded Linux runs in many HMI panels, gateways and edge nodes, so this was a plant floor question too; see the XZ Utils backdoor explained.

August 2024: a semiconductor maker's facilities run below normal levels

Microchip Technology filed a Form 8-K under Item 8.01 on 20 August 2024. It said that on 17 August it detected potentially suspicious activity involving its IT systems, and that certain of its manufacturing facilities were operating at less than normal levels and its ability to fulfil orders was impacted.

May 2025: a steel producer halts production operations

Nucor filed a Form 8-K under Item 1.05 on 14 May 2025 and an amendment in June 2025. The amendment says a threat actor illegally accessed the company's IT systems, that the company temporarily and proactively halted certain production operations at various locations, that those operations and the needed application access were later restored, and that the actor exfiltrated limited data.

September 2025: a car maker shuts down global systems

JLR initiated production stoppages in September 2025 after a cyber incident. The UK's National Cyber Security Centre said it was working with the company. On 28 September 2025 the UK government announced a loan guarantee expected to unlock up to £1.5 billion to support JLR's supply chain, which it said had been greatly impacted by the shutdown. In its results for the quarter to 30 September 2025, published 14 November 2025, JLR reported revenue down 24% year on year, attributed partly to the production stoppages, exceptional cyber related costs of £196 million in the quarter, and production returned to normal levels.

23 September 2025: a self-replicating worm in the npm registry

CISA reported a widespread software supply chain compromise in the npm registry, in which a self-replicating worm publicly known as "Shai-Hulud" compromised over 500 packages. CISA recommended a dependency review of all software using the npm ecosystem, among other steps. MES front ends and operator dashboards are often built with JavaScript packages; see the Shai-Hulud npm supply chain attack explained.

What the sources show in common

Three patterns appear in the sources themselves, without speculating about any company's decisions. IT incidents stop production: the filings and statements above describe production effects from incidents in IT systems. Components cross sectors and brands: the PLC advisory notes rebranding, and the XZ and npm alerts concern open source that ships inside many products. The first ask is an inventory: CISA's XZ and npm recommendations start with finding the affected component, which is an SBOM question.

The personas who own the problem

Software supply chain risk in a manufacturer has more owners than in a software company, because the plant, the product and the corporate network all carry it.

Procurement holds the strongest lever in OT, because you cannot rebuild a vendor's controller; contract terms are where SBOMs and patch commitments come from. And if you sell equipment with software inside, your own customers will ask you for the SBOMs and advisories you ask of your vendors.

Step by step: a 30/60/90-day plan that works with or without Safeguard

This plan assumes a mid-sized manufacturer with a few plants, an in-house development team and a few dozen critical OT vendors. Every step works with spreadsheets, open source SBOM tools and email; a platform makes it faster and keeps it current.

Days 1 to 30: know what you have

1. Name the owners. On one page, write who owns software risk for corporate IT, each plant, products you sell and vendor contracts. Most delays in the bad week come from nobody owning the OT software question.
2. Add software to the asset list. For each OT asset, record operating system, vendor application and firmware versions, and use CISA's OT asset inventory guidance to build a taxonomy by function and criticality.
3. Tier your vendors. Tier 1 is anything whose failure stops a line or creates a safety risk (controllers, safety systems, SCADA, MES); tier 2 is historians, quality and engineering tools; tier 3 is the rest.
4. Generate SBOMs for what you build, in SPDX or CycloneDX, starting with applications closest to the plant floor.
5. Send SBOM requests to tier 1 vendors using the template below.
6. Subscribe to advisories. Find where each tier 1 vendor publishes advisories, whether they offer CSAF, and note those that publish nothing.

Template: vendor SBOM request

Subject: SBOM and vulnerability information request for [product] version [version]

We run [product] version [version] at [number] sites. To support our IEC 62443 program and CISA's Secure by Demand guidance for OT buyers, please provide:

1. A software bill of materials for this version in SPDX or CycloneDX format, meeting CISA's 2026 Minimum Elements for an SBOM.
2. The location of your security advisories, and whether you publish them in CSAF format.
3. VEX statements or equivalent for known vulnerabilities in listed components that you have assessed as not affecting the product.
4. The defined support period for this version, and your process for verifying and applying patches.
5. A contact for coordinated vulnerability disclosure.

Please reply by [date, 30 days out]. If an SBOM is not available, please tell us when it will be.

Days 31 to 60: decide how you will act

7. Match components to vulnerabilities. Run every SBOM against vulnerability sources and add CISA KEV and EPSS context. Expect noise in vendor products; vendor VEX statements exist to cut it.
8. Agree the OT patch decision table below and have the OT lead sign it, so the next advisory does not restart the argument.
9. Write procurement clauses for SBOMs, advisories, support periods and verifiable patches, aligned to Secure by Demand. Procurement owns this.
10. Set release rules for in-house software: what blocks, what warns, and who approves exceptions for how long.
11. Record each plant's connectivity (internet, DMZ only or isolated), which decides how scanning and updates will work.

Decision table: OT patching

Days 61 to 90: make it routine and show it working

12. Automate the build side: SBOMs, dependency scans and release rules in every in-house pipeline.
13. Track vendors as a list: SBOM received and date, advisory format, support period, response time; review tier 1 monthly.
14. Map evidence to clauses for each 62443 requirement customers or auditors ask about.
15. Run a tabletop on a past advisory such as XZ Utils, timing how long it takes to answer "where do we run this?" across IT, plants and products sold.
16. Report to the board with three numbers: tier 1 vendors with a current SBOM, open known exploited vulnerabilities by plant and product, and the tabletop's time to answer.

Checklist at day 90

• Named owner for software risk in IT, each plant, products and procurement
• Software inventory linked to the OT asset list, with a taxonomy
• SBOMs for every in-house application near the plant floor
• SBOM requests sent to every tier 1 vendor, with responses tracked
• OT patch decision table signed by the OT lead
• Release rules and exception process for in-house software
• SBOM and patch clauses in the procurement template
• Evidence map for the 62443 clauses customers ask about
• One tabletop completed and timed
• Board report with three metrics

How do you get an SBOM from an OT vendor that has never produced one?

Ask specifically, tie the request to recognised sources (CISA's 2026 minimum elements, Secure by Demand, and 62443-4-1 if the vendor claims it), and accept a phased answer: a written date now and SBOM delivery in the next renewal. Vendors selling into the EU face CRA obligations from December 2027, so many are building the capability anyway.

Check what arrives: valid format, names and versions, a supplier per component, unambiguous identifiers such as package URLs, and an author and creation date. An SBOM of top-level components only tells you little.

What do you do when you cannot patch a PLC?

Often you cannot for months: no outage window, no vendor patch, or a patch that means recertifying a safety function. ISA publishes a whole technical report (62443-2-3) on patch management for this reason. Record the decision, apply compensating controls (segmentation, restricted engineering access, disabling unused services, monitoring logic and configuration changes) and put an expiry date on the risk acceptance. The PLC advisory above leads with addressing OT connected insecurely to the internet, a reminder that exposure often matters as much as version.

How do you handle plants with no internet connection?

Vulnerability data has to move in and results out through channels your OT design allows: a scanner inside the plant updated by signed offline bundles, a DMZ machine with outbound only access, or SBOMs exported and analysed elsewhere. Do not open a new path for convenience. Our air-gapped vulnerability management guide goes deeper.

How Safeguard does this

This section shows how the same plan runs in Safeguard, using only flows from Safeguard's documentation. Commands are shown as the docs show them; we did not run them for this post.

1. Generate SBOMs for the software you build. SBOM generation and analysis (GA) and software composition analysis with deep transitive dependency scanning (GA) cover in-house applications and edge containers. The Safeguard CLI (GA) signs in with an OAuth device code flow; on a machine without a browser it prints a URL and code to enter elsewhere:

   safeguard login --no-browser
   safeguard scan --dir .
   safeguard scan --image myregistry.example.com/edge-analytics:2.4
   

   The image name is illustrative. Results are written as JSON under ./output. The docs note that safeguard scan exits 0 when the scan ran, whatever it found, 1 when the command failed, and 2 when results were written but the vulnerability scan did not run. Gating is done by policy gates in the platform.

2. Check and track vendor SBOMs. The CLI validates a vendor SBOM against its specification and scans it locally with safeguard validate sbom.json and safeguard scan --sbom sbom.json. To monitor it over time, go to Integrations, click Connect on the Upload SBOM card, enter the project name and version, and upload the file (CycloneDX 1.3 to 1.6 and SPDX 2.2 and 2.3 are listed). Safeguard validates format, schema and required fields, enriches components with vulnerability matches, EPSS, CISA KEV status, license and supplier data, and keeps monitoring for new vulnerabilities. Vulnerability management with EPSS and KEV is GA.

3. Request SBOMs from vendors. Third-Party Risk Manager (TPRM, GA) turns the vendor request into a tracked workflow. Navigate to the vendor, click Request SBOM, select products, choose a template, set a deadline and send; bulk requests go from the Vendors list. Custom templates live under Settings, Request Templates, so yours can name CISA's 2026 minimum elements. Requests move through Sent, Viewed, In Progress, Submitted, and Validated or Rejected, with reminders 7 days before the deadline, at the deadline, and an escalation 7 days after. Each submitted SBOM is checked for format and completeness and scanned; if it falls short, click Request Revision and list the corrections.

4. Score and monitor vendors. TPRM scores each vendor from 0 to 100, where higher is better, from vulnerability risk (including EPSS and known exploited vulnerabilities), SBOM quality and age, component health and operational factors such as response time. Monitoring alerts you when a new critical vulnerability affects a vendor SBOM, when a CVE in it joins CISA KEV, when a score drops below your threshold or when an SBOM goes stale, by email, Slack, Microsoft Teams, PagerDuty or webhook. Re-assessment can run daily for critical vendors. To accept a vendor risk, click Accept Risk, give a justification, set a review date and obtain approvals.

5. Ingest vendor advisories and VEX. CSAF and VEX upload (GA) takes CSAF 2.0 advisories and VEX in CycloneDX, OpenVEX and CSAF VEX formats, from the Upload CSAF/VEX card under Integrations. Vendor VEX lets you mark vulnerabilities as not affected for a product and record mitigation status, the "vendor VEX says not affected" row of the decision table.

6. Map evidence to IEC 62443. The compliance and GRC suite (GA) includes IEC 62443 and IEC 62443-4-2 mappings, on unless you switch them off in Compliance, Manage. The docs list what each scan checks against the product's SBOM: component inventory (SR 7.8, CR 7.8), software integrity through integrity hashes (SR 3.4, CR 3.4), a known supplier for externally provided components (4-1 SM-9), unambiguous identifiers for third-party components (4-1 SM-10), exact versions for defect management, and SBOM author and creation metadata (including CR 2.12 non-repudiation). The framework's Controls tab lists further controls you evidence with tests, uploads, policies or an attestation. These checks show whether the SBOM carries what a clause presupposes; they do not assess your whole 62443 program.

7. Gate releases of in-house software. Policies, gates and guardrails (GA) enforce your release rules. Go to Settings, Policies, click Create Policy, define conditions with the visual builder or YAML (for example no critical CVEs, no abandoned packages, approved licenses only), set severity and actions, then save and enable. Each policy's action is Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent). Exceptions carry a justification and an expiry date, go to approvers and are recorded in an audit trail. In CI, with policy outcomes on for your workspace, the docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   Replace the placeholder with your gate's name; the job fails when the gate fails.

8. Scan where plant networks allow only outbound traffic. The local runner (GA) is part of the CLI. Run safeguard, type /login, approve the session, and the machine polls the platform for scan jobs. All traffic is outbound HTTPS that the runner opens; nothing connects to it. It scans locally and uploads only the SBOM and findings, never your source code. Where held connections are forbidden, the docs show safeguard runner start --workspace ./path/to/repo with --poll-wait 0 to poll at a fixed interval.

9. Run fully inside an isolated site. On-prem and air-gapped deployment (GA) runs the web app, TPRM, CLI, runner and continuous scanning inside your perimeter. Signed snapshot bundles bring vulnerability feed deltas (including CISA KEV and EPSS) and policy template updates through a DMZ receiver, by one-way diode, signed removable media, scheduled DMZ sync or a pull replica, hourly to quarterly. No component inside the perimeter calls outbound. Zero AI mode (GA) runs the platform with no language model in the loop. Safeguard's own posture: designed for FedRAMP High, with the SOC 2 Type II audit in progress.

10. Fix dependencies in software you build. Autonomous remediation (GA) uses Griffin to open tested, policy gated fix pull requests, single or in bulk. It ships switched off, with every category set to Manual. It applies to your MES extensions, integration services and edge applications, never to vendor firmware.

The plan, mapped

What Safeguard does not do

• It does not read or change PLC logic or controller configuration. It works on SBOMs, dependencies, container images and vendor documents; monitoring ladder logic and controller configuration is a different class of OT tool.
• It does not patch vendor firmware or appliances. Those fixes come from the vendor, through your change process and outage windows.
• It does not discover devices on the plant network. The device inventory comes from your OT asset and network tools; Safeguard holds the software side.
• It cannot make a vendor produce a good SBOM. TPRM tracks and validates; a thin or missing SBOM is a contract issue.
• It does not certify you to IEC 62443. Certification is done by accredited bodies against your whole program.
• It does not decide your risk. Deferring a patch on a safety system stays with your OT lead, CISO and safety engineers.
• It does not file your disclosures. SEC filings and CRA notifications are prepared and submitted by your company.

Common mistakes

• Stopping the inventory at the IT boundary. The same open source component runs in corporate apps and plant floor panels. An inventory that only covers one side cannot answer the board's question.
• Treating every CVE in a vendor product as an emergency. Use VEX, KEV and the decision table.
• Asking vendors for "an SBOM" without saying which one. Name the product version, the format, and CISA's 2026 minimum elements. Otherwise you get a PDF of top-level components.
• Letting risk acceptances live forever. A deferred patch without an expiry date becomes permanent. Put a review date on every acceptance.
• Applying pipeline rules to bought software. A CI gate cannot block a controller you already own. Use procurement terms for bought software.
• Opening network paths for scanning convenience. Fit scanning to your segmentation instead.
• Forgetting the products you sell. Your customers will ask you for SBOMs and advisories too.
• Citing retired documents, such as the 2021 NTIA minimum elements, in contracts and policies.

FAQ

What is software supply chain security in manufacturing?

Managing the risk from software components you did not write, across ERP, MES and historians, SCADA and HMI, controller firmware and edge devices: keeping SBOMs for software you build and buy, matching them to known vulnerabilities, getting vendors to supply advisories and patches, and fixing or containing issues without unsafe downtime.

Does IEC 62443 require an SBOM?

Check your licensed copy of the standard. Its component inventory, software integrity and third-party component requirements are commonly evidenced with SBOM data, and CISA's Secure by Demand OT guide asks manufacturers to include a hardware and software bill of materials with product delivery.

Which US rules apply to manufacturers' software supply chains?

No single US regulation covers manufacturing OT software. Listed companies disclose material incidents under SEC Form 8-K Item 1.05 and describe risk management under Regulation S-K Item 106. CISA's OT guidance, its 2026 SBOM minimum elements and NIST SP 800-82 are guidance, and customers often require IEC 62443 by contract.

Does the EU Cyber Resilience Act apply to US manufacturers?

It applies to manufacturers of products with digital elements placed on the EU market, wherever they are based. Reporting obligations have applied since 11 September 2026 and main obligations apply from 11 December 2027, according to the European Commission.

How do I get SBOMs from my OT vendors?

Send a specific written request for the versions you run, in SPDX or CycloneDX, meeting CISA's 2026 minimum elements, and ask for advisories, VEX, support periods and a disclosure contact. Track replies and write SBOM delivery into the next contract or renewal.

What should I do when a PLC cannot be patched?

Apply compensating controls such as segmentation, restricted engineering access and change monitoring, record a risk acceptance with an expiry date, press the vendor for a date, and patch at the next outage window once a tested patch exists.

How do I scan software in an air-gapped plant?

Keep a scanner and vulnerability data inside the isolated network, updated by signed offline bundles, or scan from a DMZ machine with outbound only access. Do not open new inbound paths for convenience.

What metrics should a manufacturer report to the board?

The share of tier 1 OT vendors with a current SBOM, open known exploited vulnerabilities by plant and product line, and the time a tabletop takes to answer "where do we run this component?"

Can Safeguard scan PLC firmware?

Safeguard's docs describe scanning directories, container images, repositories and existing SBOMs, and importing vendor SBOMs, CSAF and VEX. For controller firmware, the practical route is the vendor's SBOM, imported and monitored in Safeguard. Safeguard does not read or modify controller logic.

Most of the vulnerabilities this plan surfaces in software you build will have a fixed version upstream, and some will not. The section below explains how Safeguard closes both gaps for the open source dependencies and container images in your own MES extensions, integration services and edge applications.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is the pattern for a plant network that allows only outbound connections.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to "fix the lodash CVE in this repo". The assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to the JavaScript dependencies in an MES front end or operator dashboard your team maintains.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing.

Click through it at your own pace, or open it full screen.

Quick check

Try it on your own software: download Safeguard at safeguard.sh/download, and read the docs at docs.safeguard.sh.

For related reading, see our shorter overview of manufacturing OT software supply chain, the firmware supply chain security guide and the VEX guide.

Sources

• ISA: ISA/IEC 62443 Series of Standards
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA: Secure by Demand, Priority Considerations for OT Owners and Operators when Selecting Digital Products
• CISA: Secure by Demand OT guide (PDF)
• CISA: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• SEC: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
• European Commission: Cyber Resilience Act
• European Commission: NIS2 Directive
• CISA: AA23-335A, IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors
• CISA: Reported Supply Chain Compromise Affecting XZ Utils (CVE-2024-3094)
• CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem
• SEC: Microchip Technology Form 8-K, 20 August 2024
• SEC: Nucor Form 8-K/A, Item 1.05, June 2025
• GOV.UK: Government backs Jaguar Land Rover with £1.5 billion loan guarantee
• NCSC: Incident impacting Jaguar Land Rover
• JLR: Q2 FY26 results, 14 November 2025
• Safeguard Docs: IEC 62443
• Safeguard Docs: IEC 62443-4-2
• Safeguard Docs: TPRM SBOM Requests
• Safeguard Docs: TPRM Risk Assessment
• Safeguard Docs: TPRM Monitoring
• Safeguard Docs: Existing SBOM
• Safeguard Docs: CSAF/VEX Upload
• Safeguard Docs: Policies and Gates
• Safeguard Docs: CLI Usage
• Safeguard Docs: Local Runner
• Safeguard Docs: Air-Gapped Deployment

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.