← Back to the learning library
Before you begin: Read TFA-107 on constrained-device cybersecurity and TFA-301 on applicability. Bring a product context showing service, network and update interfaces.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Publication basis: IEC 62443-4-1:2018 and IEC 62443-4-2:2019, including the publisher-listed 2022 corrigendum for Part 4-2. Other series parts address additional roles and system concerns.
Learning objectives
By the end of this module, you should be able to:
- Separate product-development assurance from component technical capabilities.
- Define an industrial component’s security boundary and integration assumptions.
- Translate threats into verifiable firmware controls.
- Explain why process maturity, security capability and achieved system security are different claims.
Lesson 1
1. Select the relevant industrial scope
IEC 62443-4-1 addresses secure development and maintenance processes for products used in industrial automation and control systems. Part 4-2 addresses technical security requirements for components. The wider series includes other roles and system concerns. A product-development assessment therefore cannot by itself establish that a deployed industrial installation is secure.
For a fictional networked pump controller, define what is supplied: embedded firmware, hardware, update packages, service utility and user documentation. Identify the intended operational environment and component role. A laboratory prototype connected to an isolated engineering laptop has different assumptions from a controller exposed to a shared plant network. Record the supported use and boundaries before selecting detailed requirements.
Lesson 2
2. Distinguish the developer, integrator and operator
The developer controls product capabilities and secure engineering practices. The integrator combines components and configures system relationships. The operator maintains the operational environment. One organisation can perform several roles, but the responsibilities still need to be identified.
A firewall supplied by the integrator may reduce network exposure, but the manufacturer must clearly state any reliance on it. Likewise, a component can provide account management while the operator decides who receives credentials. Describe which protections are built in, which are configurable, and which depend on external controls. Avoid hiding essential requirements in a general statement that the customer must “use a secure network”.
Lesson 3
3. Make development processes produce product evidence
Use security work throughout development and maintenance. In the pump-controller example, this includes defining the security context, reviewing threats, allocating requirements, reviewing implementation, testing controls and handling vulnerabilities after release. Security findings should enter controlled defect and change processes.
Connect the process to actual outputs: a threat review should change a requirement, confirm a justified assumption or record an accepted issue. A release checklist should identify the exact assessed build and unresolved security findings. Training records and policies are relevant, but they cannot replace evidence that the intended activities occurred for the supplied product. Equally, a one-off penetration test does not demonstrate an ongoing secure development lifecycle.
Lesson 4
4. Map capabilities to the component boundary
Part 4-2 concerns component security capabilities. For teaching purposes, the pump controller’s assessment can be organised around identity, authority, integrity, confidentiality, communications boundaries, event handling and continued availability. Use the authorised publication for exact requirements, applicability and any enhanced capabilities.
| Example concern | Candidate firmware capability | Verification question |
|---|---|---|
| Service access | Authenticate service personnel and restrict commands | Can an unauthorised role change calibration? |
| Update integrity | Validate authorised packages before activation | Does a modified or wrong-product image fail safely? |
| Resource pressure | Bound queues and parsing work | Can network traffic prevent required control activity? |
| Security events | Record relevant failures without leaking secrets | Can the operator identify repeated rejected access? |
The table is an original assessment aid, not a substitute checklist for the standard.
Lesson 5
5. Handle capability levels and system assumptions carefully
A component capability claim, a system’s target security level and the security achieved in its configured environment are different concepts. Part 4-2 addresses component capability levels; it does not itself establish the system target or achieved level. Do not infer a functional-safety SIL from a cybersecurity security-level designation.
For the pump controller, a protected update mechanism can be undermined operationally if maintenance procedures expose signing authority or disable verification. Conversely, external network controls may support the system argument without becoming native component capabilities. Record the exact product configuration, assumptions and assessment scope behind any claim. Broad phrases such as “62443 compliant” leave too much unexplained to guide an integration decision.
Lesson 6
6. Verify adverse operation as well as access control
Test what happens after a control rejects an action. Repeated authentication failures must not consume unbounded memory, lock out necessary authorised servicing indefinitely or disrupt time-critical control. Evaluate these outcomes within the product’s security and safety context; there is no universal retry policy suitable for every controller.
Use controlled tests for malformed messages, replayed requests, unauthorised service commands, interrupted updates and resource exhaustion. Observe both security outcomes and the physical control contribution. A parser that rejects malicious input but blocks a control task for seconds may still violate the product’s required behaviour. Record the test environment and permitted operating limits so results can be assessed without implying coverage of every possible attack.
Lesson 7
7. Support integration, patching and end of life
Provide clear integration information: required external protections, supported authentication arrangements, update procedures, logging behaviour, recovery constraints and insecure configurations that must be avoided. Make the support period and vulnerability-reporting route available to the people responsible for deployed equipment.
When a vulnerability is found, identify affected versions and configurations, assess operational consequences and plan remediation. A patch may require downtime or compatibility checks with the control system. Retain the decision and communicate necessary conditions for safe installation. Ending product support also requires an explicit treatment of remaining field devices and reliance on external protections; it is not simply removal of a download page.
Decision guide
Who must establish this protection?
| Protection | Product contribution | Integration or operation contribution |
|---|---|---|
| Authorised service access | Identity and permission mechanisms | Account assignment and controlled service practice |
| Restricted exposure | Supported interfaces and secure defaults | Network design and deployment configuration |
| Secure updates | Package verification and controlled activation | Authorised installation and compatibility checks |
| Incident response | Useful events and supported remediation | Monitoring, triage and operational action |
Worked example
Worked example — a service port behind a plant firewall
A controller accepts calibration writes on a service port without authentication. The manufacturer claims this is acceptable because the installation guide recommends a firewall, although local service access bypasses that firewall.
The team documents all access paths and the intended maintenance roles. It reviews the threat to calibration integrity, adds appropriate authorisation for the product’s service commands and specifies any remaining physical-access assumptions. Verification covers local and network paths, normal and service modes, and unsuccessful attempts during control operation.
The security argument no longer depends on a protection that does not cover the relevant interface. Product capability evidence and integration requirements are recorded separately, giving the integrator a usable statement of remaining responsibilities.
Engineering evidence
What should the work produce?
Product security context
Defines component role, interfaces, assets and operating assumptions.
Lifecycle activity records
Connect security reviews and findings to controlled product changes.
Capability assessment and tests
State scope, configuration, requirements and observed behaviour.
Integration and support guidance
Explains external dependencies, updates, vulnerability reporting and retirement.
Common failure patterns
What goes wrong?
- Treating a development-process certificate as proof of every component capability.
- Using a firewall assumption for interfaces that bypass it.
- Testing rejected requests without measuring their impact on control behaviour.
- Making an unqualified security-level claim for all product configurations.
Applied exercise · approximately 25 minutes
Allocate security for a remotely maintained controller
A manufacturer supplies a controller and service application. An integrator supplies the remote-access gateway. The operator manages technicians. Each party assumes another party controls authorisation for firmware updates.
- Allocate update responsibilities across the three roles.
- Identify a product capability and an external condition that both need evidence.
- Define a negative test at the boundary between gateway and controller.
Review a suggested approach
The manufacturer should define and verify how the controller accepts authorised images and update commands. The integrator should establish the approved remote path and its configuration. The operator should assign and remove technician access and follow the agreed installation procedure. Contracts and product requirements determine the precise allocation; it must be explicit rather than assumed.
Evidence should cover both package authorisation inside the product and the access conditions supplied by the gateway. A useful test sends an update command from an authenticated gateway session without the required update authority, and separately attempts to provide a modified image through an authorised session. Successful network authentication alone must not be treated as evidence that every subsequent action and image is authorised.
Completion criteria
- No essential security decision is left between organisations.
- Component capabilities and deployment conditions are distinguished.
- Tests challenge both action authority and image trust.
This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.
Practical check
Questions for your next design review
- Are product, integration and operator responsibilities explicit?
- Do assumptions cover every relevant service and network path?
- Are security claims tied to assessed configurations and evidence?
- Can deployed users obtain and apply necessary remediation?
Industrial product security needs both controlled development and demonstrated capabilities, with integration assumptions stated clearly.
References and further reading
- IEC 62443-4-1:2018 — secure product development
- IEC 62443-4-2:2019 — component requirements and corrigendum
- TFA-107 — Cybersecurity for Constrained Devices
- TFA-206 — Product Cybersecurity Engineers
Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.