On this page
- Choose the correct published document
- Scope: the developer and maintainer’s process
- Ask about the product after its first delivery
- Example: selecting an industrial controller supplier
- Compare the related cybersecurity purchasing roles
- Questions before ordering
- Primary sources and edition check
- Explore more standards buying guides
The verified European sale is EN IEC 62443-4-1:2018. Genorma lists a separate prAA:2026 amendment as a draft and a developing revision; IEC identifies the international 2018 base as valid with edition 2 under development. A forecast or draft is not the published replacement. European base and history; Draft amendment status; IEC life-cycle record.
Choose the correct published document
EN IEC 62443-4-1:2018 — Secure product development lifecycle
The link below opens the exact published catalogue product named here.
Confirm the final price, taxes, available language, delivery format and permitted users at the merchant checkout. No fixed price is quoted here.
Scope: the developer and maintainer’s process
The public scope covers secure-development processes for hardware, software and firmware used in industrial automation and control systems. It reaches development, maintenance and retirement, including defect and patch management. Its requirements address the developer and maintainer, rather than the product integrator or user. IEC scope and role distinction.
That role distinction makes the document useful to product-development teams and to buyers evaluating how their suppliers work. If the quotation is for installation or integration, ask which party supplies the product and which party maintains it. Do not assign a developer’s process claim to a service provider without checking who actually performs that work.
Ask about the product after its first delivery
| Stage or responsibility | Question for the supplier |
|---|---|
| Development boundary | Which product family, versions and development activities does the proposed evidence address? |
| External components | Who manages information and changes affecting third-party hardware, software or firmware? |
| Reported defects | How are reports received, evaluated and followed through by the responsible team? |
| Updates | What maintenance and release work is included after the initial delivery? |
| End of support | What information will customers receive when continued maintenance is changing or ending? |
This is a supplier-discussion checklist, not the standard’s normative list. Ask the provider to connect its process description with the actual product being purchased. If a quotation covers only a release test, identify whether a separate support agreement is needed to address the continuing maintenance relationship.
Example: selecting an industrial controller supplier
Imagine a manufacturer choosing a controller expected to remain in service for many years. Competing offers describe similar functions, but one supplier explains its maintenance arrangements and another provides only a report for the current release. The buyer should compare the continuing responsibilities as well as the initial specification.
It could ask what happens when a defect is reported after installation, who evaluates changes to an external software component and what information accompanies an update. It could also ask which product versions are covered by the supplied process evidence. Those questions make the support boundary clearer without prescribing a patch schedule or asserting that a particular controller is secure.
Compare the related cybersecurity purchasing roles
For the system-design security risk assessment, see EN IEC 62443-3-2. For a wider organisational information security system, see EN ISO/IEC 27001. For railway software development, see EN 50716 and check the application scope. A development-process document and an installed-system assessment should not be treated as the same evidence package.
Where a customer asks for “IEC 62443 compliance”, request the part, edition, organisation and evidence boundary. The family number alone does not reveal whether the claim concerns a system, a component capability or a development process. Use the actual scope of the proposed assessment or certificate when comparing suppliers.
- Order the published EN 2018 product if that is the agreed European reference.
- Keep the draft prAA:2026 record separate in any future-change monitoring list.
- Identify the developer and maintainer for each item in the proposed product supply.
- Separate development-process assessment, technical evaluation and continuing support charges.
- Check licences for the product, security and supplier-assurance teams using the text.
Questions before ordering
Can an integrator use a supplier’s process evidence?
It can be useful input to a procurement decision, but check its coverage. The standard’s scope addresses the product developer and maintainer; it does not make the integrator’s separate responsibilities disappear.
Is prAA:2026 already a final amendment?
The checked Genorma record labels it Draft and In Development. Do not describe it as a published amendment or use it to imply a legal transition date. Current draft record.
Does process conformity prove every product configuration is secure?
Request the evidence relevant to the actual product and installation as well. A process claim and an application-specific technical conclusion have different boundaries.
Primary sources and edition check
- Genorma: published European base and development history
- Genorma: separately labelled draft prAA:2026
- IEC: current international first edition and developer/maintainer scope
Publication and purchase records checked on 7 October 2026. The examples and procurement questions are original guidance. Detailed implementation requires the applicable licensed text and decisions for the actual project.
Explore more standards buying guides
Browse standards by reference and subject to compare related document choices.
Editorial information
How this page is maintained
No documented technical review of this version is recorded. Sources and an update date are not a conformity assessment.
Scope: Secure development lifecycle requirements for developers and maintainers of industrial automation products, distinguished from integration and system-design assessments.
View registered primary sources
Keep this guide useful
Your reading list and topic feeds
Saves stay on this browser. Feeds cover guidance on this website, not every change to a standard.