IEC 62443 and SBOM for industrial automation: what the standard asks and what to ship

IEC 62443 does not require an SBOM by name in its current editions, but it requires the component knowledge that an SBOM records. The IEC catalogue entry for 62443-4-1 describes a lifecycle that "includes security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end-of-life," for "hardware, software or firmware." Defect and patch management for firmware assume you know what the firmware contains.

The public contents pages of the 2018 standard show where that knowledge is needed: two Security Management requirements on components from outside the team, six defect management requirements and five security update management requirements. The requirement wording itself sits in the paid standard; the titles below are taken from the public contents, and what follows each title is our reading, not a quotation.

The European side has moved further. The draft EN IEC 62443-4-1:2018/prAA, dated March 2026 and prepared by CLC/TC 65X under a European Commission standardization request, was submitted to enquiry. It adds term entry 3.1.45, defining a software bill of materials as "information in a structured format that allows the exchange of information for a software package, which might usefully include name, version, origin, license, copyright and known vulnerabilities in a manner useful to third parties," citing ISO/IEC 18974:2023. Its contents also list informative mappings to two other European drafts, prEN 40000-1-2 and prEN 40000-1-3. Until a final text is cited in the Official Journal, treat the draft as direction, not as a requirement you can claim.

A component list per firmware release supports at least twelve 62443-4-1 requirements: SM-9, SM-10, DM-1 to DM-6 and SUM-1 to SUM-4, with SUM-5 depending on them. Titles come from the public contents of IEC 62443-4-1:2018; the evidence column is ours.

The prAA draft changes this map: its contents delete the 2018 SM-10 and add a new SM-10, "Policy on vulnerability handling," and they modify every DM and SUM requirement. Read the 4-1 guide for the eight practices and SDLA certification; this page covers only the component side.

IEC 62443-4-2 asks for component capabilities that rely on knowing the software inside, and IEC TR 62443-2-3 describes the patch information an asset owner expects from a product supplier. The 4-2 contents list three requirements that touch this work:

• CR 3.4, Software and information integrity: the component's ability to detect unauthorised changes to its software.
• CR 3.10, Support for updates, repeated for embedded, host and network devices as EDR, HDR and NDR 3.10.
• CR 7.8, Control system component inventory: an inventory requirement under foundational requirement 7.

None of these says "SBOM", and an SBOM does not on its own satisfy a capability requirement. It is the record behind them: which software an update replaces, which version an integrity check should expect. The 4-2 component guide covers the four component types and CSA testing.

IEC TR 62443-2-3:2015 is a technical report on patch management. Its IEC abstract says it "describes requirements for asset owners and industrial automation and control system (IACS) product suppliers that have established and are now maintaining an IACS patch management program." Its contents show clause 5 for asset owners, clause 6 for product suppliers, clause 7 on exchanging patch information with the vendor patch compatibility (VPC) file format, and an annex section titled "Inventory of existing environment." An asset owner who keeps that inventory will ask its OEMs for component data to fill it. Our 2-3 guide explains the patch lifecycle states and VPC fields.

Send a versioned, machine-readable SBOM for the exact firmware the plant runs, plus the vulnerability status that goes with it. An SBOM alone produces a long CVE list on the customer side; the triage record is what makes it useful.

The free SBOM diff tool compares two CycloneDX or SPDX JSON files in the browser and lists added, removed and version-changed components: a quick way to answer the third row before writing the release note. Agree a channel with each customer: a portal, a signed download or a contract annex. The requirement minimums in the NTIA SBOM elements guide are a common baseline for what each entry should carry.

The same per-release SBOM and triage record serves the CRA directly and an FDA submission with two extra fields per component. Annex I Part II(1) of the Cyber Resilience Act requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies." Article 13(5) adds that manufacturers "shall exercise due diligence when integrating components sourced from third parties," and Article 13(6) requires them to report a vulnerability found in a component to the person or entity maintaining it. That is SM-9, SM-10 and DM-1 in legal form. The 4-2 vs CRA guide covers the technical-requirement side.

Some automation hardware also ends up in medical products: an HMI board in a lab analyser, a gateway in a hospital building system. FDA's premarket cybersecurity guidance, issued 3 February 2026, states that "For cyber devices, an SBOM is required" under section 524B(b)(3) of the FD&C Act. For each component it asks, beyond the NTIA minimum elements, for "the software level of support" and "the software component's end-of-support date." Our FDA premarket cybersecurity guide covers the full submission, and the medical devices page explains how we support those makers.

Synthetic example: no real company or product. A maker of a Linux-based protocol gateway sells it to plants and, as a board, to a maker of laboratory instruments. Release 4.2 fixes a TLS library flaw.

1. The release pipeline unpacks the 4.2 image and the 4.1 image and writes a CycloneDX SBOM for each: 212 components in 4.2, of which 14 come from the chip vendor's binary SDK and are declared by hand.
2. The diff shows two changes: the TLS library moved to a fixed version and the vendor SDK received a point update.
3. Matching 4.2 against KEV, EPSS, NVD and CSAF ICS advisories leaves nine open CVE matches. Engineers mark six "not affected" with a VEX justification and schedule three for 4.3.
4. Plant customers receive the 4.2 SBOM, the VEX file and patch compatibility notes through the customer portal (62443-2-3 clause 7).
5. The instrument maker receives the same SBOM plus a support-level and end-of-support field for each component, which it needs for its FDA file.
6. The CRA technical file stores the SBOM, the triage record and the advisory.

Takeaway. One pipeline, one SBOM per version, three audiences. The extra work for the medical customer is two fields, not a second SBOM.

AI helps with explanation and drafting, not with deciding exploitability. In SoftWSP, the code does the scoring: the firmware path unpacks images with unblob, detects components with Syft, writes a CycloneDX 1.6 SBOM, and matches it against NVD, CISA KEV, FIRST EPSS and CISA CSAF ICS advisories with a fixed KEV, EPSS, CVSS ruleset. A language model then drafts the report, and every sentence it writes must cite a piece of that evidence before the report is accepted. A separate lookup table, not a model, marks which CRA and IEC 62443-4-2 clauses a finding is indicatively relevant to. Engineers review the draft and make every "not affected" call; SoftWSP does not certify products or assess conformity. Our device firmware security service runs this for a firmware release, and the industrial automation OEM page shows how it fits PLC, drive, HMI and gateway makers.

• Quoting the standard from a blog. Cite requirement IDs and titles from the public contents and keep your reading separate from quotation marks.
• Calling a draft a requirement. The prAA amendment is a March 2026 enquiry draft; its clauses can change.
• One SBOM for a product line. Asset owners run old versions; keep an SBOM for every version still in the field.
• Skipping binary-only code. The chip-vendor SDK is often where the old components are; declare it even when a scanner cannot see inside.
• Sending raw CVE lists. Without triage records, the customer escalates every match back to you.
• Two pipelines for two regulators. Add the FDA fields to the industrial SBOM rather than building a medical copy.

For the wider OT security picture, start from our NIST SP 800-82 guide.

This guide is general information, not legal advice.