Developing Secure Products and Components

Learning objectives

Distinguish IEC 62443-4-1 process requirements from IEC 62443-4-2 technical capability.
Describe the eight secure development practices.
Explain the role of threat modelling, verification and vulnerability handling.
Evaluate product security evidence and lifecycle support.

Introduction

This module concludes the course by considering security within industrial products and components.

Planned video lesson

Module 15 video lesson

Video lesson coming soon. The written module can be completed without the video.

Planned recording: 12-15 minutes comparing a supplier's IEC 62443-4-1 development evidence with IEC 62443-4-2 component capability and the Riverside system requirement.

Transcript will be added with the video.

Main lesson

Process and capability are separate claims

Standard	Main question	What it does not prove by itself
IEC 62443-4-1	Does the supplier use a controlled secure product development lifecycle?	That every product has every technical security feature
IEC 62443-4-2	Which technical security capabilities does an IACS component provide?	That the component was securely integrated or that the full system achieves its target

IEC 62443-4-1 is process-oriented. It does not prescribe a specific development method such as waterfall or agile, and it does not replace component security requirements. IEC 62443-4-2 addresses capabilities aligned to the seven foundational requirements for different component types.

The eight IEC 62443-4-1 practice areas

Practice	Purpose in plain language
SM - Security management	Establish scope, roles, competence, secure environments, supply-chain control, process verification and improvement
SR - Specification of security requirements	Define the product context, threat model and reviewed security requirements
SD - Secure by design	Apply secure design principles, defence-in-depth and design review
SI - Secure implementation	Use implementation reviews and secure coding or hardware practices
SVV - Security verification and validation testing	Test requirements, threat mitigations, vulnerabilities and resistance to attack
DM - Management of security-related issues	Receive, investigate, assess, address and disclose security issues
SUM - Security update management	Qualify, document and securely deliver updates, including dependency information
SG - Security guidelines	Provide defence-in-depth, hardening, operation, maintenance and disposal guidance

These practices form a lifecycle. Finding a vulnerability during testing should update the defect process, threat model, requirements and future design practice.

Product security context comes first

The supplier must understand:

Intended use and foreseeable misuse.
Deployment environment.
Trust boundaries and interfaces.
External services and dependencies.
Required user and device roles.
Security assumptions.
Consequence if assumptions are not met.
Supported lifetime and update route.

A product advertised as secure without defined assumptions is difficult to integrate safely.

Threat modelling

A useful product threat model:

Defines the product, assets, interfaces and data flows.
Identifies trust boundaries and privileged functions.
Identifies threats using structured methods and relevant attack knowledge.
Assesses likelihood and impact using stated criteria.
Selects and traces mitigations.
Reviews residual risk.
Updates when design, dependencies or threats change.

Threat modelling is not a one-off diagram. It is a maintained design record.

Verification and validation need different lenses

Product testing should include:

Security requirement tests.
Threat-mitigation tests.
Vulnerability-focused testing.
Penetration testing.
Invalid-input and error-handling tests.
Update and rollback tests.
Independent review appropriate to the assurance claim.

Automated tools can find classes of issue, but they do not replace design review, manual analysis or system-context testing.

Vulnerability and update management continue after release

Look for:

Public security contact and coordinated disclosure route.
Triage and severity method.
Supported-product and affected-version process.
Timely advisory and mitigation information.
Authenticated update delivery.
Dependency and operating-system update guidance.
Clear support periods and end-of-life notice.
Lessons learned feeding back into development.

EU product-security context

IEC 62443 evidence can support engineering and conformity work, but it is not a legal declaration. Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), applies to many hardware and software products with digital elements made available on the EU market. It introduces lifecycle cybersecurity, vulnerability-handling, technical-documentation, conformity-assessment and market-surveillance duties.

The CRA's reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026. Its main obligations apply from 11 December 2027. A manufacturer should determine product scope, role, classification, support period, reporting route and conformity route from the Regulation and current Commission guidance. An IEC 62443-4-1 or 4-2 certificate may be useful evidence, but it does not automatically establish CRA conformity.

IEC 62443-4-2 component types

Component requirements are adapted for:

Software applications.
Embedded devices.
Host devices.
Network devices.

Capability requirements derive from the same foundational objectives used at system level, but the exact responsibility depends on the component. A network device and a software application contribute differently to identity, restricted data flow, event response and resource availability.

Product evaluation checklist

Ask:

Which exact product, firmware and options are in scope?
Which IEC 62443 part, edition, maturity or capability claim applies?
Which security functions are native, licensed or dependent on external services?
Which insecure defaults must the integrator change?
How are accounts, roles, certificates and keys managed?
Can unused ports, protocols and services be disabled?
Are logs accessible without weakening the device?
How are updates authenticated, tested and rolled back?
Are third-party components and dependencies identified?
What is the support period and migration path?
Is a hardening guide available?
Which assumptions must appear in the system CRS?

Treat an SBOM, certification or security white paper as evidence, not as the final decision. Confirm that it covers the version and lifecycle used by the project.

Planned original figure — M15-F01

Create an original secure-development lifecycle showing the eight IEC 62443-4-1 practices around a product, with IEC 62443-4-2 capability feeding the system design.

Planned asset: /static/training/ot-cyber-security/module-15/figure-01.svg

Engineering example

Riverside application

The two proposed Riverside PLCs demonstrate why product features, development evidence, dependencies and lifecycle support must be assessed together.

Practical activity

Apply what you learned

Compare two proposed PLCs. Product A has strong authentication and logging features but weak update and disclosure information. Product B provides mature lifecycle evidence and long support but depends on an external identity service not available at the station.

Write:

Evidence gaps.
System assumptions.
Compensating controls.
Questions to suppliers.
Conditions of acceptance.

Do not select a winner until the Riverside requirements and operating constraints are applied.

Your response (optional)

Record your reasoning and project notes here. Your response stays in this browser and is not submitted to the website.

Loading saved response…

0 / 10,000

Do not enter real credentials, confidential network details, sensitive asset information or security-sensitive project data.

Knowledge check

Answer every question correctly to complete this module. If an answer is incorrect, review the explanation and try again. This is not a formal examination.

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

Part 4-1 defines system security levels; Part 4-2 defines the maturity of the supplier’s development process.Part 4-1 addresses secure development processes; Part 4-2 addresses technical capabilities for IACS component types.Part 4-1 applies to software; Part 4-2 applies only to embedded, host and network hardware.

2. A controller has an IEC 62443-4-2 SL-C 2 claim, but the supplier provides no secure-development evidence. What follows?

The technical claim proves conformity with IEC 62443-4-1 because secure development is a prerequisite for every 4-2 claim.The supplier can omit development evidence if the asset owner performs penetration testing before deployment.The stated component capability may still be relevant, but it does not establish a 4-1 process claim or the system’s SL-A.

3. A field vulnerability exposes the same input-validation weakness across several products. What should the supplier do?

Treat affected products and feed the systemic lesson into threat models, requirements, design guidance, testing and process improvement.Issue fixes only for supported products because changing the development process would invalidate earlier test evidence.Update the penetration-test scope, but leave requirements and design practice unchanged to preserve lifecycle independence.

4. As at 15 July 2026, which statement about the EU Cyber Resilience Act is correct for an in-scope product with digital elements?

All CRA obligations already apply, so every existing product must immediately carry a new CE mark.Reporting starts 11 September 2026 and main duties 11 December 2027; prepare scope and evidence now.An IEC 62443-4-1 certificate creates automatic legal conformity and removes the need for CRA classification.

0 of 4 questions answered correctly.

Key takeaways

Remember these points

IEC 62443-4-1 concerns secure development lifecycle practices; IEC 62443-4-2 concerns component capabilities.
Product evaluation must include assumptions, dependencies, update handling and support life.
Field vulnerabilities should improve threat models, requirements, design practice and future verification.

Relevant standards and guidance

This module uses original explanatory language. Consult the applicable editions and project requirements rather than treating this lesson as normative text.

ISA/IEC 62443-4-1
ISA/IEC 62443-4-2

Last reviewed

15 July 2026.