IEC 62443-4-1 Explained: Secure Development Rules for OT Suppliers

IEC 62443-4-1 is the part of the IEC 62443 series that tells a supplier of industrial automation and control system (IACS) products how its development process must work, from security requirements and design through coding, testing, vulnerability handling, patching and user guidance. It was published by the IEC as Edition 1.0 on 15 January 2018, and it applies only to the organisation that develops and maintains the product, not to the integrator or the plant that runs it.

It is a process standard, not a product standard. Part 4-1 asks "is this supplier's development life cycle secure, documented and actually followed?", while its sibling IEC 62443-4-2 asks "does this component have the technical security capabilities it claims?". Suppliers can have their process assessed and certified, most visibly through the ISASecure Security Development Lifecycle Assurance (SDLA) program and the IECEE scheme, and in Europe the standard is being amended so it can support the Cyber Resilience Act.

Key takeaways

• IEC 62443-4-1:2018 (also published as ANSI/ISA-62443-4-1-2018) defines secure development life cycle requirements for products used in industrial automation and control systems. It covers hardware, software and firmware, and it applies to new and existing development processes.
• The requirements are grouped into eight practices: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management and security guidelines. Public summaries count 47 requirements in total.
• Each requirement is identified by a practice prefix and number (SM, SR, SD, SI, SVV, DM, SUM, SG). NIST's Secure Software Development Framework cites these IDs directly in its mapping table, which makes SP 800-218 the easiest free crosswalk.
• Conformance is judged against four process maturity levels, from an ad hoc process at level 1 to a measured and continuously improved process at level 4. Most public guidance treats level 2, a written and controlled process, as the practical floor.
• Certification is of a named organisation's documented process, checked against real product artifacts. ISASecure SDLA certification is also a prerequisite for ISASecure product certification of components and systems.
• Part 4-1 is not an SBOM standard. A 2024 joint analysis by the European Commission's Joint Research Centre and ENISA did not map it to the CRA requirement to document components in a software bill of materials, so suppliers selling into the EU need to add that on top.
• The European adaptation, EN IEC 62443-4-1:2018/A11:2026, is being written to align the standard with the CRA's horizontal cyber resilience principles, including documenting a product's intended use and security context.

What is IEC 62443-4-1?

The IEC webstore abstract describes Part 4-1 as the process requirements for securely developing products used in industrial automation and control systems. It defines a secure development life cycle (SDL) and gives guidance on meeting each requirement. The life cycle it describes runs through security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end of life.

Three details in that abstract matter more than they first appear:

1. It applies to hardware, software and firmware. A programmable logic controller, a safety relay, an engineering workstation application, a historian, a remote I/O module and an industrial firewall all fall within reach. A supplier that only writes the PC software still has to cover the firmware it ships, and a supplier that only makes hardware still has to manage the software on it.
2. It applies to the developer and maintainer only. The abstract is explicit that the requirements do not apply to the integrator or the user of the product. Asset owners use other parts of the series (2-1 for their security programme, 3-2 for risk assessment, 3-3 for system requirements). Integrators and service providers use 2-4. Part 4-1 is aimed at the organisation with the source code, the build system and the update channel.
3. It can be applied to new or existing processes. Nothing in the scope requires a greenfield SDL. A supplier with a mature quality management system can extend it, which is how most do it in practice.

Publication facts

The IEC webstore lists both documents as having a new edition "under development", so the 2018 text is the current edition but not the final word. The ISA page for the series also records a small piece of history: an editorial corrigendum in December 2020 changed the ISA title from "Product security development life-cycle requirements" to match the IEC title, with no other changes.

Where Part 4-1 sits in the IEC 62443 series

ISA describes the series as built on shared responsibility between four stakeholder groups: asset owners, product suppliers, integrators and service providers. The ISA99 committee started the work in 2002, and ISA99 and IEC TC 65 Working Group 10 developed the documents together, so the ISA and IEC editions are identical. In 2021 the IEC recognised the series as a horizontal standard, meaning it applies across industries rather than to one sector.

For a product supplier, the useful mental model is two documents that interlock:

• Part 4-1 (process). How you build, test, fix and support anything you sell. It is about evidence that your life cycle is defined and followed.
• Part 4-2 (product). Which technical capabilities a component offers, such as identification and authentication, use control, integrity, confidentiality and event logging, graded by security level.

A component can only credibly claim a 4-2 security level if the process that produced it, and that will produce its patches, meets 4-1. The ISASecure scheme makes that dependency formal: a supplier must hold SDLA certification for the process used to develop product updates before it can get a component or system certified. If you already know the zones, conduits and roles model, our explainers on IEC 62443 roles, zones and conduits and who is responsible for what under ISA/IEC 62443 cover the system side. This post stays on the supplier's development process.

Who is expected to meet it?

Anyone who develops and maintains products for industrial automation and control, in practice:

• Makers of controllers, drives, protection relays, remote terminal units, gateways and industrial network equipment.
• Developers of control and supervisory software, engineering tools, historians and HMI software.
• Makers of building automation, power grid, water and transport control equipment, since ISA lists building automation, electric power, medical devices, transportation and process industries among the sectors that use the series.
• Suppliers of industrial IoT components and edge devices that sit inside a control system.

Buyers are increasingly the ones who ask. The January 2025 joint guide "Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products", published by CISA with partner agencies in the United States, Europe, Canada, Australia, the United Kingdom, New Zealand, Germany and the Netherlands, tells buyers to look for manufacturers that show adoption of Secure by Design and the ISA 62443 standards. It also lists questions about SBOMs, coordinated vulnerability disclosure and patch tooling that line up closely with the 4-1 practices described below.

The eight practices and their requirement IDs

The standard's own text is sold by the IEC and ISA, so this section describes the practices only as public sources describe them. Three public sources are enough to reconstruct the structure without reading the standard itself:

• The IEC abstract, which lists the life cycle stages.
• NIST SP 800-218, which cites individual 4-1 requirement IDs next to each SSDF task.
• The 2024 JRC and ENISA mapping of standards to the Cyber Resilience Act, which names several individual 4-1 requirements.

A public white paper from an industrial supplier that has been through certification adds the per-practice counts. The table below combines them.

The "What it covers" column is a summary drawn from the public mapping documents and the supplier white paper's own summary of each practice, not the standard's wording. Two requirement names are stated plainly by the JRC and ENISA analysis: SUM-1 is about security update qualification and SUM-5 is about timely delivery of security patches. The same analysis names DM-5 as the requirement on disclosing security-related issues. The supplier white paper uses SM-8 as its example of a requirement about controls for private keys. If you need the exact text of any requirement, buy the standard; this is one case where a summary is not a substitute.

Practice 1: Security management (SM)

Security management is the largest practice and the one assessors spend the most time on, because it describes the process itself. Reading the SSDF mapping backwards shows what kind of evidence it expects:

• SSDF task PO.1.1 (identify security requirements for the development infrastructure and processes) maps to SM-7 and SM-9.
• PO.2.1 (create roles and responsibilities) maps to SM-2 and SM-13. PO.2.2 (role-based training) maps to SM-4.
• PO.1.3 (communicate requirements to third parties who provide software components) maps to SM-9 and SM-10, as does PW.4.1 (acquire well-secured components from third parties).
• PS.1.1 (store all forms of code securely) maps to SM-6, SM-7 and SM-8. PS.2.1 (provide a mechanism to verify release integrity) maps to SM-6, SM-8 and SUM-4.
• PO.5.1 and PO.5.2 (separate and protect development environments, secure developer endpoints) map to SM-7.
• PO.3.3 (configure toolchains to generate artifacts that support security practices) maps to SM-12 and SI-2.

So when an assessor reads your SM evidence, they are looking for a documented SDL with a defined scope, named roles with proof of competence, a protected development and build environment, controlled code signing keys, rules for what third-party code may enter the product and a record that the process itself is reviewed.

Practice 2: Specification of security requirements (SR)

This practice is where the product's security context is written down: where it will be deployed, what it connects to, what the threats are and which security requirements follow. SSDF task PW.1.1 (use threat modelling and risk information to assess security risk for the software) maps to SM-4, SR-1, SR-2 and SD-1. PO.1.2 (identify and maintain security requirements for the software) maps to SR-3, SR-4, SR-5 and SD-4. In practice the outputs are a security context document, a threat model per product line and a requirements list with a review record.

Practice 3: Secure by design (SD)

Secure by design asks you to turn the requirements into an architecture that applies secure design principles and defence in depth, then review it. SSDF PW.1.2 (track and maintain the software's security requirements, risks and design decisions) maps to SD-1. PW.1.3 (use standardised security features and services) maps to SD-1 and SD-4. PW.2.1 (review the design to verify it meets requirements and addresses risk) maps to SM-2, SR-2, SR-5, SD-3, SD-4 and SI-2. The evidence is a design document with trust boundaries and interfaces, a list of the controls the design relies on, and the review minutes.

Practice 4: Secure implementation (SI)

With only two requirements, secure implementation is the shortest practice, but it touches a lot of SSDF tasks. SI-1 is mapped to code review and analysis tasks (PW.7.1 and PW.7.2), to the human-readable code task PW.5.1, and to the vulnerability root cause task RV.3.3. SI-2 is mapped to coding practice and compiler and toolchain settings (PW.5.1, PW.6.1 and PW.6.2). Put simply: have a secure coding standard, enforce it with tools and reviews, and configure compilers and build tools to produce safer output.

Practice 5: Security verification and validation testing (SVV)

SVV covers the testing that proves the requirements were met and the threats were addressed. SSDF PW.8.1 (determine whether executable code testing should be performed) maps to SVV-1 through SVV-5, and PW.8.2 (scope the testing, design tests, perform testing and document results) maps to SM-5, SM-13, SI-1 and all five SVV requirements. The JRC and ENISA analysis notes that 4-1 prescribes several security tests on the product, which it treats as a strength relative to other standards it reviewed. NIST also ties SVV-2, SVV-3 and SVV-4 to RV.1.2, its task on reviewing and testing released software to find vulnerabilities that went undetected. Expect an assessor to look for a test plan per release that covers the security requirements, the threats in the threat model and known vulnerabilities in the product and its components, with results kept as evidence.

Practice 6: Management of security-related issues (DM)

DM is the supplier's product security incident response capability. SSDF RV.1.1 (gather information about potential vulnerabilities, including in third-party components) maps to DM-1, DM-2 and DM-3. RV.1.3 (have a policy for addressing vulnerability disclosure and remediation, and a PSIRT) maps to DM-1 through DM-5. RV.2.1 and RV.2.2 (analyse each vulnerability and plan the response) map to DM-2, DM-3 and DM-4. RV.3.4 (review the process after root cause analysis) maps to DM-6. The JRC and ENISA analysis names DM-5 as the disclosure requirement and notes that it covers disclosure of information about fixed vulnerabilities.

Practice 7: Security update management (SUM)

SUM governs how fixes reach the field. Public sources name SUM-1 (security update qualification) and SUM-5 (timely delivery of security patches), and NIST maps SUM-4 to its release integrity task. The JRC and ENISA analysis credits 4-1 with covering patching of discovered vulnerabilities, unlike several other standards it reviewed, while pointing out two gaps for CRA purposes: it does not say updates must be free of charge, and its coverage of secure distribution of updates is less complete than the CRA expects. For a deeper look at how patches land in a plant once they leave the supplier, see factory floor vulnerability management with IEC 62443 patching.

Practice 8: Security guidelines (SG)

SG is about what the supplier tells the user. NIST maps SG-1 to its task on configuring software to have secure settings by default (PW.9.1) and SG-3 to PW.9.2, communicating secure default settings and how to apply them. The certified supplier's white paper summarises SG as clear documentation for installing, commissioning, hardening, operating, maintaining and decommissioning the product. Asset owners and integrators lean heavily on this documentation when they apply IEC 62443-2-2 security protection schemes, so weak SG output shows up as friction in every customer deployment.

How the four maturity levels work

Part 4-1 does not grade products; it grades the maturity of the process that produces them. Public descriptions agree on four levels, loosely modelled on capability maturity models used elsewhere in engineering:

Two rules govern how the levels are used:

1. Levels apply per requirement and roll up. An assessment looks at each requirement in scope. A supplier's overall level is effectively limited by its weakest practice, so a mature PSIRT does not compensate for undocumented design reviews.
2. No cherry picking within a level. Public summaries are consistent that a claim of a given level means all process requirements in scope are practised at that level, not a selected subset.

The names differ slightly between sources: some public summaries call level 3 "Defined" and others call it "Practiced". The substance is the same in each: written process plus proof that it is actually followed. If you quote the level name in a contract, use the term from the edition of the standard you bought.

Which level should a supplier aim for?

Public guidance, including the certified supplier's white paper, points to level 2 as the realistic first target; that paper says suppliers should ideally operate at ML2 or above and aim to improve. It is the level at which a third party can audit you at all, because there is a controlled, written process to audit. Level 3 matters when a buyer wants proof the process is followed on every product, not just described. Level 4 is rare and expensive, and it only pays off for suppliers with enough product volume to produce meaningful process metrics.

A common pattern is ML2 on first certification for the whole SDL, with a plan to reach ML3 for the practices customers scrutinise most: DM, SUM and SVV.

How conformance is certified

There are two main public routes, plus self-declaration.

ISASecure SDLA

The ISA Security Compliance Institute (ISCI), which runs the ISASecure program (founded in 2007 and wholly owned by ISA), operates the Security Development Lifecycle Assurance (SDLA) certification. According to ISASecure's SDLA page:

• SDLA certifies compliance with IEC 62443-4-1, also published as ANSI/ISA-62443-4-1.
• A certification is granted to a named development organisation, or organisations, for a specific version of a named, documented and version controlled development process.
• The documented process must say whether it covers components, systems or both, and which products it applies to.
• The certifier evaluates the documented process against the SDLA specification, then reviews representative artifacts from products in scope to verify that each requirement is actually followed. The supplier supplies the list of products with artifacts and the certifier chooses among them.
• Certification references a three digit version of the ISASecure specifications. The current scheme documents include a transition document to SDLA 3.0.0.
• SDLA is an ISO/IEC 17065 conformity assessment scheme. Assessments are done by chartered certification bodies that are accredited by bodies recognised by IAF or ILAC.
• A supplier must hold SDLA certification for the process used to develop product updates before it can obtain ISASecure product certification (Component Security Assurance or System Security Assurance). Product and process certifications can be pursued at the same time, with product artifacts counting as evidence for both.

The SDLA page also preserves the history: an earlier version of the program, valid until 13 February 2019, granted certification at one of four levels to match the series' level concept, and SDLA 2.0.0 took effect on 13 February 2018, shortly after the IEC published the standard. The page lists an annual certification registration fee of 1,500 US dollars for certifications after 1 January 2020; assessment fees charged by certification bodies are separate.

The IECEE scheme

The IEC's own conformity assessment system for electrical equipment, IECEE, also runs an industrial cyber security programme covering IEC 62443 parts, including 4-1. We could not retrieve the IECEE programme pages with a scripted client, so the description here comes from a public white paper by an industrial supplier that holds such a certificate. It describes a process capability assessment certificate that:

• states the maturity level assessed (ML2 in its example), and
• scores each of the eight practices as a triple (A, B, C): A is the number of requirements assessed and passed, B the number judged not applicable, and C the total number of requirements in that practice.

The white paper's warning is the useful part for buyers: under this scheme a supplier may remove requirements from the assessment scope. A certificate showing (9, 0, 13) for security management means 4 of the 13 SM requirements were never assessed, which is weaker than (12, 1, 13), where one requirement was not applicable and the other 12 passed. Read the scores, not just the logo.

Self-declaration

Nothing stops a supplier from declaring alignment with 4-1 without third-party certification, and many do, especially smaller suppliers or those selling software into OT environments. A declaration is only as good as the evidence behind it. If you self-declare, keep the evidence set in the same shape an assessor would want, so you can convert to certification later without redoing the work.

Choosing a route

How 4-1 maps to NIST SSDF, the EU CRA and IEC 81001-5-1

NIST SSDF (SP 800-218)

NIST published SP 800-218, the Secure Software Development Framework version 1.1, in February 2022. Its practice table lists informative references for every task, and IEC 62443-4-1:2018 is one of them, with the specific requirement IDs listed against each task. That makes the mapping public and free, and the summary below is taken directly from it:

Two things stand out. First, the SUM practice barely appears (only SUM-4, for release integrity), because SSDF does not try to govern patch delivery to the field. Second, SG appears only through the secure defaults tasks, because SSDF is not about user documentation. Going the other way, SSDF tasks around provenance data and software composition (PS.3.2 and PW.4.4) are thinner in 4-1. A supplier that meets 4-1 will cover most of SSDF, but not every SSDF task, and vice versa. If you need to answer a US federal buyer's SSDF question, our post on answering "do you follow a secure development framework?" shows how to phrase it. NIST has also published a draft Revision 1 of SP 800-218 for comment, so watch for changes to the mapping.

EU Cyber Resilience Act Annex I

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. According to the European Commission, its main obligations apply from 11 December 2027, reporting obligations apply from 11 September 2026, and the Commission published practical guidance for manufacturers on 27 July 2026. Products that conform to harmonised standards benefit from a presumption of conformity with the essential requirements, and the Commission's standardisation request M/606 covers 41 horizontal and vertical standards.

Two public sources describe how 4-1 fits:

1. The JRC and ENISA mapping (2024). This analysis was done against the CRA proposal's numbering. In its summary tables it maps EN IEC 62443-4-1:2018 to the first two product requirements (an appropriate level of cybersecurity based on risk, and delivery without known exploitable vulnerabilities) and to four of the eight vulnerability handling requirements: remediating vulnerabilities without delay through security updates, publicly disclosing fixed vulnerabilities once an update is available, securely distributing updates, and disseminating patches without delay with advisory messages. It does not map 4-1 to the first vulnerability handling requirement, which is the one that requires a software bill of materials. Its recurring caveat is that 4-1 is written for IACS only.
2. CEN-CENELEC's adaptation work. CEN-CENELEC states that EN IEC 62443-4-1:2018 is being amended to EN IEC 62443-4-1:2018/A11:2026 to align it with the horizontal "Principles of Cyber Resilience" standard under development in CEN-CLC/JTC 13 WG 9, with updated or added requirements on documenting a product's intended use and security context. The STAN4CRA programme lists this work in CENELEC technical committee CLC/TC 65X Working Group 3, coordinated with IEC TC 65 to avoid duplication.

The practical reading: a supplier with a working 4-1 process has a strong head start on CRA vulnerability handling, but it still needs an SBOM process, a free-of-charge update policy and, depending on the product class, conformity assessment under the CRA itself. Until the amended EN is published and cited in the Official Journal, 4-1 conformance is useful evidence, not a presumption of conformity.

IEC 81001-5-1

IEC 81001-5-1:2021, published on 16 December 2021, defines life cycle requirements for health software. Its IEC abstract says it is needed to support conformance to IEC 62443-4-1 while taking the specific needs of health software into account. That is the lineage in one sentence: 81001-5-1 is 4-1's process model adapted for medical and health software, written so that a health software manufacturer following it is also working toward 4-1. The IEC webstore lists a corrected version dated December 2025.

ISO/IEC 27034

ISO/IEC 27034 is a multi-part series on application security. The JRC and ENISA mapping describes Part 1 (2011, overview and concepts) as focused on secure development practices for applications across all software phases, and Part 5-1 (2018) as covering protocols and an XML data structure for application security controls. Its frame is the organisation's application security controls rather than a product supplier's whole life cycle, and it is not specific to industrial products.

Comparison table

Third-party and open source components

Neither the IEC abstract nor the public summaries treat open source as a separate topic, but third-party code runs through several practices:

• SM-9 and SM-10 (security management). NIST maps its supplier tasks to these two IDs: PO.1.3 (communicate requirements to third parties providing components), PW.4.1 (acquire well-secured components from third parties) and PW.4.4 (verify that acquired components comply with requirements throughout their life cycle). Read together, they expect a documented rule for selecting third-party components, a record of the security requirements you place on suppliers, and ongoing checks once a component is inside the product.
• DM-1 (management of security-related issues). PW.4.4 and RV.1.1 also map to DM-1, and RV.1.1 explicitly includes vulnerabilities in third-party components the software uses. A 4-1 PSIRT must watch upstream advisories for every component in the product, not just the code you wrote.
• SUM requirements. Security updates for released products must be deployed and managed. For most products, many security fixes are fixes to third-party and open source components, so in practice SUM is largely about shipping those on time.
• SVV and RV.1.2. NIST maps its task on finding vulnerabilities in released software to SVV-2, SVV-3, SVV-4, DM-1 and DM-2. In practice that includes scanning the components a product ships, not only your own code.

Here is the honest gap: 4-1 expects you to manage components, but the 2018 text predates today's SBOM expectations, and the JRC and ENISA analysis did not map it to the CRA SBOM requirement. The CISA Secure by Demand OT guide, written in 2025, asks buyers to put the question directly: "Has the manufacturer drawn up a software bill of materials?" It also asks whether advisories are machine readable in the Common Security Advisory Framework (CSAF) format, whether the manufacturer has a coordinated vulnerability disclosure policy, and whether it publishes an RFC 9116 security.txt file. A 4-1 programme built in 2026 should produce all four as normal outputs of SM, DM and SUM.

Update delivery and timelines

Public sources describe SUM-5 as requiring timely delivery of security patches, but they do not say 4-1 sets a fixed number of days. That fits the standard's design: the supplier defines its own timelines in its documented process, and the assessor checks that the process is defined and followed. Buyers increasingly set the numbers in contracts instead. If you supply products into the EU, the CRA adds that updates must be distributed without delay, free of charge and with advisory messages, which is stricter than "timely" on its own.

Step by step: gap-assess a product team against 4-1

The walkthrough below assumes one product line and one development organisation, which is also how SDLA scopes a certification. It produces a gap list and an evidence set an assessor can sample. Buy a copy of the standard before step 2; everything below is structure, and the requirement wording must come from the licensed text.

Step 1: Fix the scope

Write down, in one page:

• The organisation or organisations in scope (site, team, legal entity).
• The product or products the process covers, and whether they are components, systems or both.
• The process version you will assess against. Put the SDL documents under version control from day one, because SDLA certifies a specific version.

Step 2: Build the requirement register

Create one row per requirement, 47 in total, and give each row the same columns: requirement ID, owner, process document section, evidence location, current maturity (1 to 4), target maturity, gap, action and due date. Keep the register in the same repository as the process documents so changes are reviewed like code.

sdl/
  process/
    00-scope.md
    01-security-management.md
    02-security-requirements.md
    03-secure-design.md
    04-secure-implementation.md
    05-verification-validation.md
    06-security-issue-management.md
    07-security-update-management.md
    08-security-guidelines.md
  register/
    requirements.csv          # 47 rows: ID, owner, doc section, evidence path, ML now, ML target, gap
  evidence/
    <product>/<release>/
      threat-model/
      design-review/
      code-review/
      test-reports/
      sbom/
      release-integrity/
      advisories/
      user-guidelines/

A minimal register header:

id,practice,owner,process_doc,evidence_path,ml_current,ml_target,gap,action,due
SM-1,Security management,,sdl/process/01-security-management.md,,,2,,,
SR-1,Specification of security requirements,,sdl/process/02-security-requirements.md,,,2,,,
DM-1,Management of security-related issues,,sdl/process/06-security-issue-management.md,,,2,,,
SUM-1,Security update management,,sdl/process/07-security-update-management.md,,,2,,,

Step 3: Score current maturity honestly

For each requirement, ask three questions in order:

1. Is there a written, controlled procedure? If not, the requirement is at level 1.
2. Can we show the people doing it are trained and following it? If yes, level 2.
3. Can we pull evidence from at least two real products or releases showing it was done? If yes, level 3.

Do not score level 4 unless you already collect process metrics, such as time from vulnerability report to fix, review coverage, or percentage of releases with complete evidence.

Step 4: Produce the evidence set per release

The evidence an assessor samples is per product release. A practical minimum:

Step 5: Generate SBOMs in the build, not by hand

Even though 4-1 does not name SBOMs, they are the cheapest way to prove third-party component management (SM) and to drive known vulnerability scanning (SVV) and upstream monitoring (DM). Generate them from the same build that produces the release.

For a Node.js project, npm can emit a CycloneDX or SPDX SBOM directly from the lockfile:

# CycloneDX JSON for the application
npm sbom --sbom-format cyclonedx --sbom-type application > evidence/sbom/app.cdx.json

# SPDX JSON instead, if your buyers ask for SPDX
npm sbom --sbom-format spdx > evidence/sbom/app.spdx.json

For a multi-module Maven build, the CycloneDX Maven plugin's aggregate goal produces one SBOM for the reactor:

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom
# Output is written under target/ as bom.json and bom.xml by default

Then match components against known vulnerabilities and store the result next to the SBOM. With the Safeguard CLI, safeguard scan builds an SBOM and matches it against vulnerability databases:

# Scan the source tree of the release
safeguard scan --dir .

# Or scan an SBOM you already produced in the build
safeguard scan --sbom evidence/sbom/app.cdx.json

# Or scan the container image you ship, if the product includes one
safeguard scan --image registry.example.com/vendor/gateway-ui:4.2.0

Results are written as JSON under ./output. Copy them into evidence/PRODUCT/RELEASE/sbom/ so the scan result and the SBOM it came from stay together. Firmware images built outside these ecosystems need their own component inventory method; be explicit in your SDL about which parts of the product each method covers.

Step 6: Prove release integrity

NIST maps its release integrity task (PS.2.1) to SM-6, SM-8 and SUM-4. Sign the release and publish hashes customers can check:

# Signed, annotated tag for the release commit
git tag -s v4.2.0 -m "Release 4.2.0"
git tag -v v4.2.0

# Hashes for every shipped file
sha256sum dist/* > dist/SHA256SUMS

Keep the signing keys in a controlled store with named custodians, because that is exactly the kind of private key control that public summaries tie to SM-8.

Step 7: Make the build produce evidence on every release

A small CI job keeps evidence from drifting. This GitHub Actions example generates the SBOM and hashes on each tag and stores them as build artifacts:

name: release-evidence
on:
  push:
    tags: ["v*"]
jobs:
  evidence:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test
      - run: mkdir -p evidence/sbom && npm sbom --sbom-format cyclonedx --sbom-type application > evidence/sbom/app.cdx.json
      - run: npm run build && sha256sum dist/* > evidence/SHA256SUMS
      - uses: actions/upload-artifact@v4
        with:
          name: evidence-${{ github.ref_name }}
          path: evidence/

Step 8: Publish a reporting channel and advisories

DM needs a way for outsiders to report issues and a way for you to tell customers about fixes. RFC 9116 defines security.txt, served at /.well-known/security.txt. Contact and Expires are the two required fields:

Contact: mailto:psirt@example.com
Expires: 2027-10-24T00:00:00.000Z
Encryption: https://example.com/psirt-pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt

Pair it with a written coordinated vulnerability disclosure policy and advisories in a machine-readable format. CISA's OT buyer guide asks specifically about CSAF advisories and CVE identifiers for disclosed vulnerabilities.

Step 9: Write the user security guidelines

SG output is documentation customers actually use. For each product, cover the role of the product in a defence in depth architecture, hardening steps, secure configuration and defaults, account and credential management, how to verify and apply updates, logging and monitoring hooks, and secure decommissioning and disposal. Version it with the product and review it when the threat model changes.

Step 10: Close the loop

DM-6 and the improvement side of SM ask you to review whether the process works. Hold a quarterly review that looks at the register, the open gaps, vulnerability response times and any escaped defects, then update the process documents through version control. This is also where level 4 evidence would come from if you ever pursue it.

Common mistakes

• Treating 4-1 as a product checklist. Part 4-1 grades the process. A product with strong technical controls built by an undocumented process does not meet it, and a well-documented process can produce a product that still fails 4-2.
• Writing the SDL and never using it. Level 2 needs a written process; level 3 needs proof it was followed. Assessors sample real artifacts from real products. A beautiful process document with no release records behind it will not pass.
• Removing requirements from scope to get a certificate. Some schemes allow it, and buyers who read certificates closely will notice. "Not applicable" with a reason is fine; "out of scope" because you were not ready is a weakness that shows on the certificate.
• Ignoring third-party and open source code. RV.1.1 in NIST's mapping explicitly covers third-party components, and so does a buyer's first vulnerability question. A PSIRT that only watches your own code misses most of the vulnerabilities that will reach your customers.
• Assuming 4-1 covers the CRA. It covers a lot of CRA vulnerability handling, but not the SBOM requirement as mapped by JRC and ENISA, not free-of-charge updates and not CRA reporting obligations.
• Leaving firmware out of the component inventory. The scope explicitly includes firmware. If your SBOM process only covers the web interface, say so and add a firmware inventory method.
• Letting signing keys drift into build scripts. Release integrity and key control requirements are some of the easiest for an assessor to test and some of the most embarrassing to fail.
• Skipping the security guidelines. SG is often written last and badly. Asset owners judge suppliers by how usable the hardening guide is.
• Quoting the standard in public documents. The text is copyrighted and licensed. Paraphrase in your own process documents and reference requirement IDs.

Where Safeguard fits

IEC 62443-4-1 is a process standard, and no tool makes a supplier conformant or certified. Safeguard does not certify suppliers or assess conformance. What it can do is produce some of the routine evidence that several practices depend on, for the open source dependencies and container images in the software you build:

• Component inventory and known vulnerability matching (supports SM third-party management, SVV vulnerability testing and DM monitoring). Safeguard scans repositories, container images and SBOM files, builds an SBOM, and matches components against vulnerability databases. The platform shows which projects contain a given component and version, which helps a PSIRT answer "which products ship this library?" when an upstream advisory lands.
• Prioritisation (supports DM triage). Reachability analysis ranks vulnerable code paths your application actually calls, so the DM process spends time on the findings that matter.
• Policies and gates (supports SM and SUM). Policies evaluated in the platform can stop a release that brings in a component your third-party rules forbid.
• Remediation (supports SUM). Autonomous remediation opens tested pull requests that move a dependency to a fixed version; it ships switched off by default, so your change process decides what runs automatically.
• Controlled assistance (supports SI and SUM records). The Safeguard CLI's assistant can edit code and run commands only with your approval, and safeguard exec runs non-interactively in CI.

Where Safeguard does not help: it does not scan firmware binaries, generate hardware bills of materials, run penetration tests, write your threat model, design reviews or user security guidelines, or operate your PSIRT. Most of 4-1 is people and process; Safeguard covers part of the software supply chain evidence.

Industrial products ship more open source than their datasheets suggest: web management interfaces, protocol stacks, embedded Linux userlands and engineering tools all pull in third-party packages that need fixing on the supplier's schedule, not just upstream's. That is why the remediation side of supply chain hygiene still matters to a 4-1 programme, even though it covers only part of what the standard asks.

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 is a real Safeguard CLI session. You ask it to fix a lodash CVE; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and prints a summary without pushing anything. For a 4-1 supplier, that is a dependency fix with a human approval at each step and a summary you can attach to the update qualification record for the release.

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

The second demo sets up the Safeguard runner on your own machine, approves it with a device code, then scans from the terminal. Industrial suppliers often keep source and build systems on segregated networks; running the scan locally keeps the work next to the code and the build, and the output can go straight into the release evidence folder.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A PSIRT analyst triaging an upstream advisory can ask which projects carry the affected component without leaving the assistant, with tool access limited to what you allowed.

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

To try it on your own code, download Safeguard or read the CLI documentation.

FAQ

What is the difference between IEC 62443-4-1 and IEC 62443-4-2?

Part 4-1 sets requirements for the supplier's secure development process, organised into eight practices and graded by maturity level. Part 4-2 sets technical security requirements for IACS components, such as authentication, integrity and logging capabilities, graded by security level. Suppliers usually need both: 4-1 for the process and 4-2 for the product.

Is IEC 62443-4-1 mandatory?

Not by itself in most places. It becomes effectively mandatory when a buyer writes it into a contract or tender, when a sector regulator references it, or, in the EU, if the amended EN version is cited as a harmonised standard under the Cyber Resilience Act and a supplier chooses it to show conformity.

What are the eight practices in IEC 62443-4-1?

Security management (SM), specification of security requirements (SR), secure by design (SD), secure implementation (SI), security verification and validation testing (SVV), management of security-related issues (DM), security update management (SUM) and security guidelines (SG). Public summaries count 47 requirements across them.

What maturity level do I need for IEC 62443-4-1 certification?

The standard defines four levels: Initial, Managed, Defined (also called Practiced) and Improving. Level 2 is the common first target because it is the first level with a written, controlled process an assessor can audit. Check what your buyers and your chosen certification scheme expect before committing.

How long does IEC 62443-4-1 certification take?

Public sources do not give a standard duration. It depends on how much of the process already exists and how much evidence you have from real releases. Teams that already run a documented quality process and keep release records tend to move fastest, because assessors sample artifacts from real products.

Does IEC 62443-4-1 require an SBOM?

The 2018 text does not appear to require an SBOM by that name: the 2024 JRC and ENISA analysis did not map it to the CRA's SBOM requirement. It does require management of third-party components and monitoring of their vulnerabilities, and an SBOM is the most practical way to meet those. Buyers and the CRA increasingly ask for one directly.

Does IEC 62443-4-1 apply to software-only products?

Yes. The scope covers hardware, software and firmware developed for use in industrial automation and control systems. Control system software, engineering tools and HMI applications are all in scope if you develop and maintain them.

Does IEC 62443-4-1 apply to system integrators?

No. The IEC abstract states the requirements apply only to the developer and maintainer of the product, not to the integrator or user. Integrators and service providers look to IEC 62443-2-4, and asset owners to 2-1, 3-2 and 3-3.

How does IEC 62443-4-1 relate to NIST SSDF?

NIST SP 800-218 lists IEC 62443-4-1 requirement IDs as informative references for most SSDF tasks, so the two map closely. Part 4-1 adds patch delivery and user security guidelines that SSDF covers lightly; SSDF adds provenance and software composition tasks that 4-1 covers lightly.

Will the CRA replace IEC 62443-4-1?

No. The CRA is a law that sets essential requirements; standards show how to meet them. CEN-CENELEC is amending EN IEC 62443-4-1 so it can support the CRA, adding requirements on intended use and security context. Suppliers that already run a 4-1 process will reuse most of it.

Quick check

Sources

• IEC webstore: IEC 62443-4-1:2018, Secure product development lifecycle requirements
• IEC webstore: IEC 62443-4-2:2019, Technical security requirements for IACS components
• IEC webstore: IEC 81001-5-1:2021, Health software security activities in the product life cycle
• ISA: ISA/IEC 62443 Series of Standards
• ISASecure: program overview
• ISASecure: IEC 62443 SDLA certification
• ISASecure: IEC 62443 CSA certification
• NIST CSRC: SP 800-218, Secure Software Development Framework version 1.1
• NIST: SP 800-218 full text (PDF)
• NIST CSRC: SP 800-218 Rev. 1 initial public draft
• European Commission: Cyber Resilience Act
• European Commission: Cyber Resilience Act standardisation
• ENISA: Cyber Resilience Act Requirements Standards Mapping
• JRC and ENISA: Cyber Resilience Act Requirements Standards Mapping, Joint Analysis (PDF, 2024)
• CEN-CENELEC: CRA Standards Unlocked, from EN IEC 62443 to CRA (webinar page)
• STAN4CRA: CLC/TC 65X
• CISA: Industrial Control Systems
• CISA: Secure by Demand Priority Considerations for OT Owners and Operators (resource page)
• CISA and partners: Secure by Demand Priority Considerations for OT Owners and Operators (PDF, 13 January 2025)
• Industrial supplier white paper: Cybersecurity and IEC 62443 Part II, Process Certification (PDF)
• Wikipedia: IEC 62443 (secondary summary of maturity levels and certification schemes)
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
• npm Docs: npm sbom
• CycloneDX: cyclonedx-maven-plugin
• Safeguard documentation: CLI

Last reviewed: 24 October 2026. A new edition of IEC 62443-4-1 and the CRA-aligned EN amendment are in progress; check the IEC webstore and the Official Journal for the current status.