IEC 62443-4-1:2018

Security for industrial automation and control systems - Part 4-1: Secure product development lifecycle requirements

IEC 62443-4:2018 specifies the process requirements for the secure development of products used in industrial automation and control systems. This specification is part of a series of standards that addresses the issue of security for industrial automation and control systems (IACS). IEC 62443-4 defines secure development life-cycle (SDL) requirements related to cyber security for products intended for use in the industrial automation and control systems environment and provides guidance on how to meet the requirements described for each element. The life-cycle description includes security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end-of-life. These requirements can be applied to new or existing processes for developing, maintaining and retiring hardware, software or firmware.
Note that these requirements only apply to the developer and maintainer of the product, and are not applicable to the integrator or the user of the product. A summary list of the requirements is provided in Annex B.

Sécurité des automatismes industriels et des systèmes de commande - Partie 4-1: Exigences relatives au cycle de développement<br /> de produit sécurisé

L'IEC 62443-4:2018 spécifie les exigences relatives au processus de développement sécurisé des produits utilisés dans des systèmes d'automatisation et de commande industriels. Elle définit un cycle de développement sécurisé (SDL – secure development life-cycle) en vue de développer et d'assurer la sécurité des produits. Ce cycle inclut la définition des exigences de sécurité, la conception sécurisée, la mise en œuvre sécurisée (y compris les lignes directrices en matière de codage), la vérification et la validation, la gestion des défauts, la gestion des correctifs et la fin de vie du produit. Ces exigences peuvent être appliquées à des processus nouveaux ou existants pour le développement, la maintenance et le retrait des matériels, logiciels et micrologiciels destinés aux produits nouveaux ou existants. Elles s'appliquent au développeur et au chargé de maintenance du produit, mais pas à l'intégrateur ni à l'utilisateur du produit. Une liste récapitulative des exigences du présent document peut être consultée à l'Annexe B.

General Information

• Status: Published
• Publication Date: 14-Jan-2018
• ICS: 25.040.40 - Industrial process measurement and control
• ICS: 35.030 - IT Security
• Technical Committee: TC 65 - Industrial-process measurement, control and automation
• Drafting Committee: WG 10 - TC 65/WG 10
• Current Stage: PPUB - Publication issued
• Start Date: 15-Jan-2018
• Completion Date: 02-Feb-2018

Overview

IEC 62443-4-1:2018 defines secure product development lifecycle (SDL) requirements for products used in industrial automation and control systems (IACS). As part of the IEC 62443 series on IACS security, this international standard specifies process-level security requirements for developers and maintainers of hardware, software and firmware - covering security requirements definition, secure design, secure implementation, verification and validation, defect and patch management, and product end-of-life. Note: these requirements apply to the product developer/maintainer only (not to integrators or users). Annex B provides a summary list of the requirements.

Key topics and technical requirements

The standard organizes SDL requirements into practical practices and topics including:

• Security management: defining development processes, roles and responsibilities, development environment protection, file integrity and cryptographic key controls.
• Specification of security requirements: documenting product security context, performing threat modeling, producing traceable product security requirements and reviews.
• Secure by design: applying secure design principles, defense-in-depth, design reviews and best practices.
• Secure implementation: secure coding guidelines, implementation reviews and controls for third‑party or custom components.
• Verification & validation (SVV): security requirements testing, threat mitigation testing, vulnerability testing and penetration testing, plus independence of testers.
• Security-related issue management: receiving, reviewing, assessing, fixing, disclosing and monitoring security defects.
• Security update (patch) management: qualification, documentation and lifecycle handling of security updates and product end-of-life.

These topics form the core of an SDL for industrial control systems, emphasizing traceability, repeatable processes and continuous improvement.

Practical applications - who uses IEC 62443-4-1

IEC 62443-4-1 is intended for:

• Product developers and manufacturers of PLCs, RTUs, HMIs, DCS components, embedded controllers and industrial firmware/software
• Security architects and engineering teams implementing secure development lifecycles for IACS products
• Quality, compliance and product-security managers seeking to demonstrate process-based cybersecurity controls
• Third-party vendors and maintainers responsible for lifecycle management, patching and vulnerability handling

Adoption helps reduce product vulnerabilities, improve incident handling, and simplify compliance with procurement or customer security requirements for industrial environments.

Related standards

• IEC 62443 family (other parts addressing system, component and organizational requirements) - IEC 62443-4-1 complements other IEC 62443 parts that define system-level and component-level requirements.
• (For program alignment) Organizations often map IEC 62443 SDL processes to broader cyber risk and secure development frameworks.

Keywords: IEC 62443-4-1, secure product development lifecycle, SDL, industrial automation security, IACS cybersecurity, secure design, secure implementation, patch management, vulnerability testing.

Standards Content (Sample)

IEC 62443-4-1 ®
Edition 1.0 2018-01
INTERNATIONAL
STANDARD
colour
inside
Security for industrial automation and control systems –
Part 4-1: Secure product development lifecycle requirements

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: [phone]
3, rue de Varembé [e-mail]
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 21 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 16 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.

IEC publications search - webstore.iec.ch/advsearchform IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 67 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and

CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: [e-mail].
IEC 62443-4-1 ®
Edition 1.0 2018-01
INTERNATIONAL
STANDARD
colour
inside
Security for industrial automation and control systems –

Part 4-1: Secure product development lifecycle requirements

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ISBN 978-2-8322-5239-0
ICS 25.040.40; 35.030
– 2 – IEC 62443-4-1:2018 © IEC 2018
CONTENTS
FOREWORD . 6
INTRODUCTION . 8
1 Scope . 11
2 Normative references . 11
3 Terms, definitions, abbreviated terms, acronyms and conventions . 11
3.1 Terms and definitions . 11
3.2 Abbreviated terms and acronyms . 16
3.3 Conventions . 17
4 General principles . 17
4.1 Concepts . 17
4.2 Maturity model . 19
5 Practice 1 – Security management . 20
5.1 Purpose . 20
5.2 SM-1: Development process . 21
5.2.1 Requirement . 21
5.3 Rationale and supplemental guidance . 21
5.4 SM-2: Identification of responsibilities . 21
5.4.1 Requirement . 21
5.4.2 Rationale and supplemental guidance. 21
5.5 SM-3: Identification of applicability . 21
5.5.1 Requirement . 21
5.5.2 Rationale and supplemental guidance. 22
5.6 SM-4: Security expertise . 22
5.6.1 Requirement . 22
5.6.2 Rationale and supplemental guidance. 22
5.7 SM-5: Process scoping . 22
5.7.1 Requirement . 22
5.7.2 Rationale and supplemental guidance. 23
5.8 SM-6: File integrity . 23
5.8.1 Requirement . 23
5.8.2 Rationale and supplemental guidance. 23
5.9 SM-7: Development environment security . 23
5.9.1 Requirement . 23
5.9.2 Rationale and supplemental guidance. 23
5.10 SM-8: Controls for private keys . 23
5.10.1 Requirement . 23
5.10.2 Rationale and supplemental guidance. 24
5.11 SM-9: Security requirements for externally provided components . 24
5.11.1 Requirement . 24
5.11.2 Rationale and supplemental guidance. 24
5.12 SM-10: Custom developed components from third-party suppliers . 24
5.12.1 Requirement . 24
5.12.2 Rationale and supplemental guidance. 25
5.13 SM-11: Assessing and addressing security-related issues . 25
5.13.1 Requirement . 25
5.13.2 Rationale and supplemental guidance. 25

5.14 SM-12: Process verification . 25
5.14.1 Requirement . 25
5.14.2 Rationale and supplemental guidance. 25
5.15 SM-13: Continuous improvement . 25
5.15.1 Requirement . 25
5.15.2 Rationale and supplemental guidance. 26
6 Practice 2 – Specification of security requirements . 26
6.1 Purpose . 26
6.2 SR-1: Product security context . 27
6.2.1 Requirement . 27
6.2.2 Rationale and supplemental guidance. 27
6.3 SR-2: Threat model . 27
6.3.1 Requirement . 27
6.3.2 Rationale and supplemental guidance. 28
6.4 SR-3: Product security requirements . 28
6.4.1 Requirement . 28
6.4.2 Rationale and supplemental guidance. 28
6.5 SR-4: Product security requirements content . 29
6.5.1 Requirement . 29
6.5.2 Rationale and supplemental guidance. 29
6.6 SR-5: Security requirements review . 29
6.6.1 Requirement . 29
6.6.2 Rationale and supplemental guidance. 29
7 Practice 3 – Secure by design . 30
7.1 Purpose . 30
7.2 SD-1: Secure design principles . 30
7.2.1 Requirement . 30
7.2.2 Rationale and supplemental guidance. 30
7.3 SD-2: Defense in depth design. 31
7.3.1 Requirement . 31
7.3.2 Rationale and supplemental guidance. 32
7.4 SD-3: Security design review . 32
7.4.1 Requirement . 32
7.4.2 Rationale and supplemental guidance. 32
7.5 SD-4: Secure design best practices . 32
7.5.1 Requirement . 32
7.5.2 Rationale and supplemental guidance. 33
8 Practice 4 – Secure implementation . 33
8.1 Purpose . 33
8.2 Applicability . 33
8.3 SI-1: Security implementation review . 33
8.3.1 Requirement . 33
8.3.2 Rationale and supplemental guidance. 34
8.4 SI-2: Secure coding standards . 34
8.4.1 Requirement . 34
8.4.2 Rationale and supplemental guidance. 34
9 Practice 5 – Security verification and validation testing . 34
9.1 Purpose . 34

– 4 – IEC 62443-4-1:2018 © IEC 2018
9.2 SVV-1: Security requirements testing . 35
9.2.1 Requirement . 35
9.2.2 Rationale and supplemental guidance. 35
9.3 SVV-2: Threat mitigation testing . 35
9.3.1 Requirement . 35
9.3.2 Rationale and supplemental guidance. 35
9.4 SVV-3: Vulnerability testing . 36
9.4.1 Requirement . 36
9.4.2 Rationale and supplemental guidance. 36
9.5 SVV-4: Penetration testing . 36
9.5.1 Requirement . 36
9.5.2 Rationale and supplemental guidance. 36
9.6 SVV-5: Independence of testers . 37
9.6.1 Requirement . 37
9.6.2 Rationale and supplemental guidance. 37
10 Practice 6 – Management of security-related issues . 38
10.1 Purpose . 38
10.2 DM-1: Receiving notifications of security-related issues . 38
10.2.1 Requirement . 38
10.2.2 Rationale and supplemental guidance. 38
10.3 DM-2: Reviewing security-related issues . 38
10.3.1 Requirement . 38
10.3.2 Rationale and supplemental guidance. 39
10.4 DM-3: Assessing security-related issues . 39
10.4.1 Requirement . 39
10.4.2 Rationale and supplemental guidance. 39
10.5 DM-4: Addressing security-related issues . 40
10.5.1 Requirement . 40
10.5.2 Rationale and supplemental guidance. 40
10.6 DM-5: Disclosing security-related issues . 41
10.6.1 Requirement . 41
10.6.2 Rationale and supplemental guidance. 41
10.7 DM-6: Periodic review of security defect management practice . 42
10.7.1 Requirement . 42
10.7.2 Rationale and supplemental guidance. 42
11 Practice 7 – Security update management . 42
11.1 Purpose . 42
11.2 SUM-1: Security update qualification . 42
11.2.1 Requirement . 42
11.2.2 Rationale and supplemental guidance. 42
11.3 SUM-2: Security update documentation . 42
11.3.1 Requirement . 42
11.3.2 Rationale and supplemental guidance. 43
11.4 SUM-3: Dependent component or operating system security update
documentation . 43
11.4.1 Requirement . 43
11.4.2 Rationale and supplemental guidance. 43
11.5 SUM-4: Security update delivery . 43
11.5.1 Requirement . 43

11.5.2 Rationale and supplemental guidance. 43
11.6 SUM-5: Timely delivery of security patches . 44
11.6.1 Requirement . 44
11.6.2 Rationale and supplemental guidance. 44
12 Practice 8 – Security guidelines . 44
12.1 Purpose . 44
12.2 SG-1: Product defense in depth . 44
12.2.1 Requirement . 44
12.2.2 Rationale and supplemental guidance. 45
12.3 SG-2: Defense in depth measures expected in the environment . 45
12.3.1 Requirement . 45
12.3.2 Rationale and supplemental guidance. 45
12.4 SG-3: Security hardening guidelines . 45
12.4.1 Requirement . 45
12.4.2 Rationale and supplemental guidance. 46
12.5 SG-4: Secure disposal guidelines . 46
12.5.1 Requirement . 46
12.5.2 Rationale and supplemental guidance. 46
12.6 SG-5: Secure operation guidelines . 46
12.6.1 Requirement . 46
12.6.2 Rationale and supplemental guidance. 47
12.7 SG-6: Account management guidelines . 47
12.7.1 Requirement . 47
12.7.2 Rationale and supplemental guidance. 47
12.8 SG-7: Documentation review . 47
12.8.1 Requirement . 47
12.8.2 Rationale and supplemental guidance. 47
Annex A (informative) Possible metrics . 48
Annex B (informative) Table of requirements . 50
Bibliography . 52

Figure 1 – Parts of the IEC 62443 series. 9
Figure 2 – Example scope of product life-cycle . 10
Figure 3 – Defence in depth strategy is a key philosophy of the secure product life-cycle . 18

Table 1 – Maturity levels . 20
Table 2 – Example SDL continuous improvement activities . 26
Table 3 – Required level of independence of testers from developers . 37
Table B.1 – Summary of all requirements . 50

– 6 – IEC 62443-4-1:2018 © IEC 2018
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
SECURITY FOR INDUSTRIAL AUTOMATION
AND CONTROL SYSTEMS –
Part 4-1: Secure product development lifecycle requirements

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62443-4-1 has been prepared by IEC technical committee 65:
Industrial-process measurement, control and automation.
The text of this International Standard is based on the following documents:
FDIS Report on voting
65/685/FDIS 65/688/RVD
Full information on the voting for the approval of this International Standard can be found in
the report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.

A list of all parts in the IEC 62443 series, published under the general title Security for
industrial automation and control systems, can be found on the IEC website.
Future standards in this series will carry the new general title as cited above. Titles of existing
standards in this series will be updated at the time of the next edition.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 8 – IEC 62443-4-1:2018 © IEC 2018
INTRODUCTION
This document is part of a series of standards that addresses the issue of security for
industrial automation and control systems (IACS). This document describes product
development life-cycle requirements related to cyber security for products intended for use in
the industrial automation and control systems environment and provides guidance on how to
meet the requirements described for each element.
This document has been developed in large part from the Secure Development Life-cycle
Assessment (SDLA) Certification Requirements [26] from the ISA Security Compliance
Institute (ISCI). Note that the SDLA procedure was based on the following sources:
– ISO/IEC 15408-3 (Common Criteria) [18];
– Open Web Application Security Project (OWASP) Comprehensive, Lightweight Application
Security Process (CLASP) [36];
– The Security Development Life-cycle by Michael Howard and Steve Lipner [43];
– IEC 61508 Functional safety of electrical/electronic/ programmable electronic
safety-related systems [24], and
– RCTA DO-178B Software Considerations in Airborne Systems and Equipment Certification
[28].
Therefore, all these sources can be considered contributing sources to this document.
This document is the part of the IEC 62443 series that contains security requirements for
developers of any automation and control products where security is a concern.
Figure 1 illustrates the relationship of the different parts of IEC 62443 that were in existence
or planned as of the date of circulation of this document. Those that are normatively
referenced are included in the list of normative references in Clause 2, and those that are
referenced for informational purposes or that are in development are listed in the Bibliography.
___________
Figures in square brackets refer to the bibliography.

IEC TS 62443-1-1 IEC TR 62443-1-2 IEC TS 62443-1-3 IEC TR 62443-1-4
Master glossary of System security
IACS security life-cycle
Terminology, concepts
terms and abbreviations compliance metrics
and use-cases
and models
IEC 62443-2-1 IEC TR 62443-2-2 IEC TR 62443-2-3 IEC 62443-2-4
Establishing an industrial
Implementation guidance Security program
Patch management in
automation and control for an IACS security
requirements for IACS
the IACS environment
system security program management system
service providers
IEC TR 62443-3-1 IEC 62443-3-2 IEC 62443-3-3
System security
Security technologies
Security risk assessment
requirements and
for industrial automation and system design
security levels
and control systems
IEC 62443-4-1 IEC 62443-4-2
Technical security
Product development
requirements for IACS
requirements
components
Published In development Development planned
Published (under review) Out for comment/vote Adoption planned

IEC
Figure 1 – Parts of the IEC 62443 series
Figure 2 illustrates how the developed product relates to maintenance and integration
capabilities defined in IEC 62443-2-4 and to its operation by the asset owner. The product
supplier develops products using a process compliant with this document. Those products
may be a single component, such as an embedded controller, or a group of components
working together as a system or subsystem. The products are then integrated together,
usually by a system integrator, into an Automation Solution using a process compliant with
IEC 62443-2-4. The Automation Solution is then installed at a particular site and becomes
part of the industrial automation and control system (IACS). Some of these capabilities
reference security measures defined in IEC 62443-3-3 [10] that the service provider ensures
are supported in the Automation Solution (either as product features or compensating
mechanisms). This document only addresses the process used for the development of the
product; it does not address design, installation or operation of the Automation Solution or
IACS.
In Figure 2, the Automation Solution is illustrated to contain one or more subsystems and
optional supporting components such as advanced control. The dashed boxes indicate that
these components are “optional”.
NOTE 1 Automation Solutions typically have a single product, but they are not restricted to do so. In some
industries, there may be a hierarchical product structure. In general, the Automation Solution is the set of hardware
and software, independent of product packaging, that is used to control a physical process (for example,
continuous or manufacturing) as defined by the asset owner.
NOTE 2 If a service provider provides products used in the Automation Solution, then the service provider is
fulfilling the role of product supplier in this diagram.
NOTE 3 If a service provider provides products used in the Automation Solution, then the service provider is
fulfilling the role of product supplier in this diagram.

Policies and
Component System
General
procedures
Status
key
– 10 – IEC 62443-4-1:2018 © IEC 2018
Industrial automation and control system (IACS)
Operational and maintenance
Asset
Operates (IEC 62443-2-1,
capabilities (policies and procedures)
Owner
IEC 62443-2-4)
+
Automation Solution (IEC 62443-3-3)
Integrates (IEC 62443-2-4,
System
Complementary
Integrator
hardware and
IEC 62443-3-2)
Subsystem 1 Subsystem 2
software
components
Configured for intended environment
Includes a configured instance  of the Product
Product (IEC 62443-4-2)
system, subsystem, or component such as:
Product
Develops (IEC 62443-4-1)
Supplier
Embedded Network Host
Applications
devices components devices
Independent of the intended environment
IEC
Figure 2 – Example scope of product life-cycle

SECURITY FOR INDUSTRIAL AUTOMATION
AND CONTROL SYSTEMS –
Part 4-1: Secure product development lifecycle requirements

1 Scope
This part of IEC 62443 specifies process requirements for the secure development of
products used in industrial automation and control systems. It defines a secure development
life-cycle (SDL) for the purpose of developing and maintaining secure products. This life-cycle
includes security requirements definition, secure design, secure implementation (including
coding guidelines), verification and validation, defect management, patch management and
product end-of-life. These requirements can be applied to new or existing processes for
developing, maintaining and retiring hardware, software or firmware for new or existing
products. These requirements apply to the developer and maintainer of the product, but not to
the integrator or user of the product. A summary list of the requirements in this document can
be found in Annex B.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
IEC 62443-2-4:2015, Security for industrial automation and control systems – Part 2-4:
Security program requirements for IACS service providers
IEC 62443-2-4:2015/AMD1:2017
3 Terms, definitions, abbreviated terms, acronyms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC TR 62443-1-2 and
the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1.1
abuse case
test case used to perform negative operations of a use case
Note 1 to entry: Abuse case tests are simulated attacks often based on the threat model. An abuse case is a type
of complete interaction between a system and one or more actors where the results of the interaction are
intentionally intended to be harmful to the system, one of the actors or one of the stakeholders in the system.
___________
Under consideration.
– 12 – IEC 62443-4-1:2018 © IEC 2018
3.1.2
access control
protection of system resources against unauthorized access
3.1.3
access control
process by which use of system resources is regulated according to a security policy and is
permitted by only authorized users according to that policy
Note 1 to entry: Access control includes identification and authentication requirements specified in other parts of
the IEC 62443 series.
3.1.4
administrator
user who has been authorized to manage security policies/capabilities for a product or system
3.1.5
asset
physical or logical object owned by or under the custodial duties of an organization, having
either a perceived or actual value to the organization
Note 1 to entry: In this specific case, an asset is an object that is part of an IACS.
3.1.6
asset owner
individual or organization responsible for one or more IACSs
3.1.7
attack surface
physical and functional interfaces of a system that can be accessed and, therefore, potentially
exploited by an attacker
3.1.8
audit log
event log that requires a higher level of integrity protection than provided by typical event logs
Note 1 to entry: Audit logs are used to protect against claims that repudiate responsibility for an action.
3.1.9
authentication
provision of assurance that a claimed characteristic of an identity is correct
Note 1 to entry: Not all credentials used to authenticate an identity are created equally. The trustworthiness of the
credential is determined by the configured authentication mechanism. Hardware or software-based mechanisms
can force users to prove their identity before accessing data on a device. A typical example is proving the identity
of a user usually through an identity provider.
Note 2 to entry: Authentication includes verifying human users as well as non-human users such as devices or
processes.
3.1.10
automation solution
control system and any complementary hardware and software components that have been
installed and configured to operate in an IACS
Note 1 to entry: Automation Solution is used as a proper noun in this part of the IEC 62443 series.
Note 2 to entry: The difference between the control system and the Automation Solution is that the control system
is incorporated into the Automation Solution design (for example, a specific number of workstations, controllers and
devices in a specific configuration), which is then implemented. The resulting configuration is referred to as the
Automation Solution.
Note 3 to entry: The Automation Solution can be comprised of components from multiple suppliers including the
product supplier of the control system.
3.1.11
banned function
software method that is no longer recommended to be used in software because more secure
versions exist with less propensity for misuse
Note 1 to entry: Banned functions are sometimes called banned methods or banned Application Programming
Interfaces (APIs).
3.1.12
best practices
guidelines for securely designing, developing, testing, maintaining or retiring products that the
supplier has determined are commonly recommended by both the security and industrial
automation communities
EXAMPLE Least privilege, economy of mechanism and least common mechanism.
3.1.13
component
one of the parts that make up a product or system
Note 1 to entry: A component may be hardware or software and may be subdivided into other components.
3.1.14
configuration management
discipline of identifying the components of an evolving system for the purposes of controlling
changes to those components and maintaining continuity and traceability throughout the
life-cycle
3.1.15
defense in depth
approach to defend the system against any particular attack using several independent
methods
Note 1 to entry: Defense in depth implies layers of security and detection, even on single systems, and provides
the following features:
• is based on the idea that any one layer of protection, may and probably will be defeated;
• attackers are faced with breaking through or bypassing each layer without being detected;
• a flaw in one layer can be mitigated by capabilities in other layers;
• system security becomes a set of layers within the overall network security; and
• each layer should be autonomous and not rely on the same functionality nor have the same failure modes as
the other layers.
3.1.16
dependent component
component external to the product on which the product depends
EXAMPLE Java run time environment or a driver
Note 1 to entry: This includes both hardware and software.
3.1.17
deprecated function
software method that is supported but whose use is no longer recommended
Note 1 to entry: Methods are generally deprecated before becoming obsolete (deleted from the set of functions
provided by the supplier of the function). Deprecated functions are sometimes called deprecated methods or
deprecated APIs.
– 14 – IEC 62443-4-1:2018 © IEC 2018
3.1.18
externally provided component
component included in a product that is developed by an external organization and is not
developed specifically for one supplier
Note 1 to entry: Examples include purchased software and open source software.
3.1.19
fuzz testing
process of creating malformed or unexpected data or call sequences to be consumed by the
entity under test to verify that they are handled appropriately
3.1.20
industrial automation and control system
collection of personnel, hardware, software, procedures and policies involved in the operation
of the industrial process and that can affect or influence its safe, secure and reliable operation
Note 1 to entry: The IACS can include components that are not installed at the asset owner’s site.
Note 2 to entry: The definition of IACS was taken from in IEC 62443-3-3 [10] and is illustrated in Figure 2.
3.1.21
patch management
area of systems management that involves acquiring, testing and installing software patches
(code changes) to a product
Note 1 to entry: See IEC TR 62443-2-3 [7] for additional information.
rd
Note 2 to entry: Patch management also applies to the process of keeping included 3 party libraries current
before releasing a product.
3.1.22
product
system, subsystem or co
...

IEC 62443-4-1 ®
Edition 1.0 2018-01
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Security for industrial automation and control systems –
Part 4-1: Secure product development lifecycle requirements

Sécurité des automatismes industriels et des systèmes de commande –
Partie 4-1: Exigences relatives au cycle de développement de produit sécurisé

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Central Office Tel.: [phone]
3, rue de Varembé [e-mail]
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, with equivalent terms in 16 additional languages.
and withdrawn publications. Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and Definitions clause of
IEC publications issued since 2002. Some entries have been
IEC Customer Service Centre - webstore.iec.ch/csc collected from earlier publications of IEC TC 37, 77, 86 and
If you wish to give us your feedback on this publication or CISPR.

need further assistance, please contact the Customer Service

Centre: [e-mail].
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC - Electropedia - www.electropedia.org
webstore.iec.ch/advsearchform Le premier dictionnaire d'électrotechnologie en ligne au
La recherche avancée permet de trouver des publications IEC monde, avec plus de 22 000 articles terminologiques en
en utilisant différents critères (numéro de référence, texte, anglais et en français, ainsi que les termes équivalents dans
comité d’études,…). Elle donne aussi des informations sur les 16 langues additionnelles. Egalement appelé Vocabulaire
projets et les publications remplacées ou retirées. Electrotechnique International (IEV) en ligne.

IEC Just Published - webstore.iec.ch/justpublished Glossaire IEC - std.iec.ch/glossary
Restez informé sur les nouvelles publications IEC. Just 67 000 entrées terminologiques électrotechniques, en anglais
Published détaille les nouvelles publications parues. et en français, extraites des articles Termes et Définitions des
Disponible en ligne et une fois par mois par email. publications IEC parues depuis 2002. Plus certaines entrées
antérieures extraites des publications des CE 37, 77, 86 et
Service Clients - webstore.iec.ch/csc CISPR de l'IEC.

Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-nous:
[e-mail].
IEC 62443-4-1 ®
Edition 1.0 2018-01
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Security for industrial automation and control systems –

Part 4-1: Secure product development lifecycle requirements

Sécurité des automatismes industriels et des systèmes de commande –

Partie 4-1: Exigences relatives au cycle de développement de produit sécurisé

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 25.040.40; 35.030 ISBN 978-2-8322-8693-7

– 2 – IEC 62443-4-1:2018 © IEC 2018
CONTENTS
FOREWORD . 6
INTRODUCTION . 8
1 Scope . 11
2 Normative references . 11
3 Terms, definitions, abbreviated terms, acronyms and conventions . 11
3.1 Terms and definitions . 11
3.2 Abbreviated terms and acronyms . 16
3.3 Conventions . 17
4 General principles . 17
4.1 Concepts . 17
4.2 Maturity model . 19
5 Practice 1 – Security management . 20
5.1 Purpose . 20
5.2 SM-1: Development process . 21
5.2.1 Requirement . 21
5.3 Rationale and supplemental guidance . 21
5.4 SM-2: Identification of responsibilities . 21
5.4.1 Requirement . 21
5.4.2 Rationale and supplemental guidance. 21
5.5 SM-3: Identification of applicability . 21
5.5.1 Requirement . 21
5.5.2 Rationale and supplemental guidance. 22
5.6 SM-4: Security expertise . 22
5.6.1 Requirement . 22
5.6.2 Rationale and supplemental guidance. 22
5.7 SM-5: Process scoping . 22
5.7.1 Requirement . 22
5.7.2 Rationale and supplemental guidance. 23
5.8 SM-6: File integrity . 23
5.8.1 Requirement . 23
5.8.2 Rationale and supplemental guidance. 23
5.9 SM-7: Development environment security . 23
5.9.1 Requirement . 23
5.9.2 Rationale and supplemental guidance. 23
5.10 SM-8: Controls for private keys . 23
5.10.1 Requirement . 23
5.10.2 Rationale and supplemental guidance. 24
5.11 SM-9: Security requirements for externally provided components . 24
5.11.1 Requirement . 24
5.11.2 Rationale and supplemental guidance. 24
5.12 SM-10: Custom developed components from third-party suppliers . 24
5.12.1 Requirement . 24
5.12.2 Rationale and supplemental guidance. 25
5.13 SM-11: Assessing and addressing security-related issues . 25
5.13.1 Requirement . 25
5.13.2 Rationale and supplemental guidance. 25

5.14 SM-12: Process verification . 25
5.14.1 Requirement . 25
5.14.2 Rationale and supplemental guidance. 25
5.15 SM-13: Continuous improvement . 25
5.15.1 Requirement . 25
5.15.2 Rationale and supplemental guidance. 26
6 Practice 2 – Specification of security requirements . 26
6.1 Purpose . 26
6.2 SR-1: Product security context . 27
6.2.1 Requirement . 27
6.2.2 Rationale and supplemental guidance. 27
6.3 SR-2: Threat model . 27
6.3.1 Requirement . 27
6.3.2 Rationale and supplemental guidance. 28
6.4 SR-3: Product security requirements . 28
6.4.1 Requirement . 28
6.4.2 Rationale and supplemental guidance. 28
6.5 SR-4: Product security requirements content . 29
6.5.1 Requirement . 29
6.5.2 Rationale and supplemental guidance. 29
6.6 SR-5: Security requirements review . 29
6.6.1 Requirement . 29
6.6.2 Rationale and supplemental guidance. 29
7 Practice 3 – Secure by design . 30
7.1 Purpose . 30
7.2 SD-1: Secure design principles . 30
7.2.1 Requirement . 30
7.2.2 Rationale and supplemental guidance. 30
7.3 SD-2: Defense in depth design. 31
7.3.1 Requirement . 31
7.3.2 Rationale and supplemental guidance. 32
7.4 SD-3: Security design review . 32
7.4.1 Requirement . 32
7.4.2 Rationale and supplemental guidance. 32
7.5 SD-4: Secure design best practices . 32
7.5.1 Requirement . 32
7.5.2 Rationale and supplemental guidance. 33
8 Practice 4 – Secure implementation . 33
8.1 Purpose . 33
8.2 Applicability . 33
8.3 SI-1: Security implementation review . 33
8.3.1 Requirement . 33
8.3.2 Rationale and supplemental guidance. 34
8.4 SI-2: Secure coding standards . 34
8.4.1 Requirement . 34
8.4.2 Rationale and supplemental guidance. 34
9 Practice 5 – Security verification and validation testing . 34
9.1 Purpose . 34

– 4 – IEC 62443-4-1:2018 © IEC 2018
9.2 SVV-1: Security requirements testing . 35
9.2.1 Requirement . 35
9.2.2 Rationale and supplemental guidance. 35
9.3 SVV-2: Threat mitigation testing . 35
9.3.1 Requirement . 35
9.3.2 Rationale and supplemental guidance. 35
9.4 SVV-3: Vulnerability testing . 36
9.4.1 Requirement . 36
9.4.2 Rationale and supplemental guidance. 36
9.5 SVV-4: Penetration testing . 36
9.5.1 Requirement . 36
9.5.2 Rationale and supplemental guidance. 36
9.6 SVV-5: Independence of testers . 37
9.6.1 Requirement . 37
9.6.2 Rationale and supplemental guidance. 37
10 Practice 6 – Management of security-related issues . 38
10.1 Purpose . 38
10.2 DM-1: Receiving notifications of security-related issues . 38
10.2.1 Requirement . 38
10.2.2 Rationale and supplemental guidance. 38
10.3 DM-2: Reviewing security-related issues . 38
10.3.1 Requirement . 38
10.3.2 Rationale and supplemental guidance. 39
10.4 DM-3: Assessing security-related issues . 39
10.4.1 Requirement . 39
10.4.2 Rationale and supplemental guidance. 39
10.5 DM-4: Addressing security-related issues . 40
10.5.1 Requirement . 40
10.5.2 Rationale and supplemental guidance. 40
10.6 DM-5: Disclosing security-related issues . 41
10.6.1 Requirement . 41
10.6.2 Rationale and supplemental guidance. 41
10.7 DM-6: Periodic review of security defect management practice . 42
10.7.1 Requirement . 42
10.7.2 Rationale and supplemental guidance. 42
11 Practice 7 – Security update management . 42
11.1 Purpose . 42
11.2 SUM-1: Security update qualification . 42
11.2.1 Requirement . 42
11.2.2 Rationale and supplemental guidance. 42
11.3 SUM-2: Security update documentation . 42
11.3.1 Requirement . 42
11.3.2 Rationale and supplemental guidance. 43
11.4 SUM-3: Dependent component or operating system security update
documentation . 43
11.4.1 Requirement . 43
11.4.2 Rationale and supplemental guidance. 43
11.5 SUM-4: Security update delivery . 43
11.5.1 Requirement . 43

11.5.2 Rationale and supplemental guidance. 43
11.6 SUM-5: Timely delivery of security patches . 44
11.6.1 Requirement . 44
11.6.2 Rationale and supplemental guidance. 44
12 Practice 8 – Security guidelines . 44
12.1 Purpose . 44
12.2 SG-1: Product defense in depth . 44
12.2.1 Requirement . 44
12.2.2 Rationale and supplemental guidance. 45
12.3 SG-2: Defense in depth measures expected in the environment . 45
12.3.1 Requirement . 45
12.3.2 Rationale and supplemental guidance. 45
12.4 SG-3: Security hardening guidelines . 45
12.4.1 Requirement . 45
12.4.2 Rationale and supplemental guidance. 46
12.5 SG-4: Secure disposal guidelines . 46
12.5.1 Requirement . 46
12.5.2 Rationale and supplemental guidance. 46
12.6 SG-5: Secure operation guidelines . 46
12.6.1 Requirement . 46
12.6.2 Rationale and supplemental guidance. 47
12.7 SG-6: Account management guidelines . 47
12.7.1 Requirement . 47
12.7.2 Rationale and supplemental guidance. 47
12.8 SG-7: Documentation review . 47
12.8.1 Requirement . 47
12.8.2 Rationale and supplemental guidance. 47
Annex A (informative) Possible metrics . 48
Annex B (informative) Table of requirements . 50
Bibliography . 52

Figure 1 – Parts of the IEC 62443 series. 9
Figure 2 – Example scope of product life-cycle . 10
Figure 3 – Defence in depth strategy is a key philosophy of the secure product life-cycle . 18

Table 1 – Maturity levels . 20
Table 2 – Example SDL continuous improvement activities . 26
Table 3 – Required level of independence of testers from developers . 37
Table B.1 – Summary of all requirements . 50

– 6 – IEC 62443-4-1:2018 © IEC 2018
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
SECURITY FOR INDUSTRIAL AUTOMATION
AND CONTROL SYSTEMS –
Part 4-1: Secure product development lifecycle requirements

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62443-4-1 has been prepared by IEC technical committee 65:
Industrial-process measurement, control and automation.
The text of this International Standard is based on the following documents:
FDIS Report on voting
65/685/FDIS 65/688/RVD
Full information on the voting for the approval of this International Standard can be found in
the report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.

A list of all parts in the IEC 62443 series, published under the general title Security for
industrial automation and control systems, can be found on the IEC website.
Future standards in this series will carry the new general title as cited above. Titles of existing
standards in this series will be updated at the time of the next edition.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 8 – IEC 62443-4-1:2018 © IEC 2018
INTRODUCTION
This document is part of a series of standards that addresses the issue of security for
industrial automation and control systems (IACS). This document describes product
development life-cycle requirements related to cyber security for products intended for use in
the industrial automation and control systems environment and provides guidance on how to
meet the requirements described for each element.
This document has been developed in large part from the Secure Development Life-cycle
Assessment (SDLA) Certification Requirements [26] from the ISA Security Compliance
Institute (ISCI). Note that the SDLA procedure was based on the following sources:
– ISO/IEC 15408-3 (Common Criteria) [18];
– Open Web Application Security Project (OWASP) Comprehensive, Lightweight Application
Security Process (CLASP) [36];
– The Security Development Life-cycle by Michael Howard and Steve Lipner [43];
– IEC 61508 Functional safety of electrical/electronic/ programmable electronic
safety-related systems [24], and
– RCTA DO-178B Software Considerations in Airborne Systems and Equipment Certification
[28].
Therefore, all these sources can be considered contributing sources to this document.
This document is the part of the IEC 62443 series that contains security requirements for
developers of any automation and control products where security is a concern.
Figure 1 illustrates the relationship of the different parts of IEC 62443 that were in existence
or planned as of the date of circulation of this document. Those that are normatively
referenced are included in the list of normative references in Clause 2, and those that are
referenced for informational purposes or that are in development are listed in the Bibliography.
___________
Figures in square brackets refer to the bibliography.

IEC TS 62443-1-1 IEC TR 62443-1-2 IEC TS 62443-1-3 IEC TR 62443-1-4
Master glossary of
System security IACS security life-cycle
Terminology, concepts
terms and abbreviations compliance metrics
and use-cases
and models
IEC 62443-2-1 IEC TR 62443-2-2 IEC TR 62443-2-3 IEC 62443-2-4
Establishing an industrial
Implementation guidance Security program
Patch management in
automation and control for an IACS security
requirements for IACS
the IACS environment
system security program management system
service providers
IEC TR 62443-3-1 IEC 62443-3-2 IEC 62443-3-3
System security
Security technologies
Security risk assessment
requirements and
for industrial automation and system design
security levels
and control systems
IEC 62443-4-1 IEC 62443-4-2
Technical security
Product development
requirements for IACS
requirements
components
Published In development Development planned
Published (under review) Out for comment/vote Adoption planned
IEC
Figure 1 – Parts of the IEC 62443 series
Figure 2 illustrates how the developed product relates to maintenance and integration
capabilities defined in IEC 62443-2-4 and to its operation by the asset owner. The product
supplier develops products using a process compliant with this document. Those products
may be a single component, such as an embedded controller, or a group of components
working together as a system or subsystem. The products are then integrated together,
usually by a system integrator, into an Automation Solution using a process compliant with
IEC 62443-2-4. The Automation Solution is then installed at a particular site and becomes
part of the industrial automation and control system (IACS). Some of these capabilities
reference security measures defined in IEC 62443-3-3 [10] that the service provider ensures
are supported in the Automation Solution (either as product features or compensating
mechanisms). This document only addresses the process used for the development of the
product; it does not address design, installation or operation of the Automation Solution or
IACS.
In Figure 2, the Automation Solution is illustrated to contain one or more subsystems and
optional supporting components such as advanced control. The dashed boxes indicate that
these components are “optional”.
NOTE 1 Automation Solutions typically have a single product, but they are not restricted to do so. In some
industries, there may be a hierarchical product structure. In general, the Automation Solution is the set of hardware
and software, independent of product packaging, that is used to control a physical process (for example,
continuous or manufacturing) as defined by the asset owner.
NOTE 2 If a service provider provides products used in the Automation Solution, then the service provider is
fulfilling the role of product supplier in this diagram.
NOTE 3 If a service provider provides products used in the Automation Solution, then the service provider is
fulfilling the role of product supplier in this diagram.
Policies and
Component System
General
procedures
Status
key
– 10 – IEC 62443-4-1:2018 © IEC 2018
Industrial automation and control system (IACS)
Operational and maintenance
Asset
Operates (IEC 62443-2-1,
capabilities (policies and procedures)
Owner
IEC 62443-2-4)
+
Automation Solution (IEC 62443-3-3)
Integrates (IEC 62443-2-4,
System
Complementary
Integrator
IEC 62443-3-2)
hardware and
Subsystem 1 Subsystem 2
software
components
Configured for intended environment
Includes a configured instance  of the Product
Product (IEC 62443-4-2)
system, subsystem, or component such as:
Product
Develops (IEC 62443-4-1)
Supplier
Embedded Network Host
Applications
devices components devices
Independent of the intended environment
IEC
Figure 2 – Example scope of product life-cycle

SECURITY FOR INDUSTRIAL AUTOMATION
AND CONTROL SYSTEMS –
Part 4-1: Secure product development lifecycle requirements

1 Scope
This part of IEC 62443 specifies process requirements for the secure development of
products used in industrial automation and control systems. It defines a secure development
life-cycle (SDL) for the purpose of developing and maintaining secure products. This life-cycle
includes security requirements definition, secure design, secure implementation (including
coding guidelines), verification and validation, defect management, patch management and
product end-of-life. These requirements can be applied to new or existing processes for
developing, maintaining and retiring hardware, software or firmware for new or existing
products. These requirements apply to the developer and maintainer of the product, but not to
the integrator or user of the product. A summary list of the requirements in this document can
be found in Annex B.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
IEC 62443-2-4:2015, Security for industrial automation and control systems – Part 2-4:
Security program requirements for IACS service providers
IEC 62443-2-4:2015/AMD1:2017
3 Terms, definitions, abbreviated terms, acronyms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC TR 62443-1-2 and
the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1.1
abuse case
test case used to perform negative operations of a use case
Note 1 to entry: Abuse case tests are simulated attacks often based on the threat model. An abuse case is a type
of complete interaction between a system and one or more actors where the results of the interaction are
intentionally intended to be harmful to the system, one of the actors or one of the stakeholders in the system.
___________
Under consideration.
– 12 – IEC 62443-4-1:2018 © IEC 2018
3.1.2
access control
protection of system resources against unauthorized access
3.1.3
access control
process by which use of system resources is regulated according to a security policy and is
permitted by only authorized users according to that policy
Note 1 to entry: Access control includes identification and authentication requirements specified in other parts of
the IEC 62443 series.
3.1.4
administrator
user who has been authorized to manage security policies/capabilities for a product or system
3.1.5
asset
physical or logical object owned by or under the custodial duties of an organization, having
either a perceived or actual value to the organization
Note 1 to entry: In this specific case, an asset is an object that is part of an IACS.
3.1.6
asset owner
individual or organization responsible for one or more IACSs
3.1.7
attack surface
physical and functional interfaces of a system that can be accessed and, therefore, potentially
exploited by an attacker
3.1.8
audit log
event log that requires a higher level of integrity protection than provided by typical event logs
Note 1 to entry: Audit logs are used to protect against claims that repudiate responsibility for an action.
3.1.9
authentication
provision of assurance that a claimed characteristic of an identity is correct
Note 1 to entry: Not all credentials used to authenticate an identity are created equally. The trustworthiness of the
credential is determined by the configured authentication mechanism. Hardware or software-based mechanisms
can force users to prove their identity before accessing data on a device. A typical example is proving the identity
of a user usually through an identity provider.
Note 2 to entry: Authentication includes verifying human users as well as non-human users such as devices or
processes.
3.1.10
automation solution
control system and any complementary hardware and software components that have been
installed and configured to operate in an IACS
Note 1 to entry: Automation Solution is used as a proper noun in this part of the IEC 62443 series.
Note 2 to entry: The difference between the control system and the Automation Solution is that the control system
is incorporated into the Automation Solution design (for example, a specific number of workstations, controllers and
devices in a specific configuration), which is then implemented. The resulting configuration is referred to as the
Automation Solution.
Note 3 to entry: The Automation Solution can be comprised of components from multiple suppliers including the
product supplier of the control system.
3.1.11
banned function
software method that is no longer recommended to be used in software because more secure
versions exist with less propensity for misuse
Note 1 to entry: Banned functions are sometimes called banned methods or banned Application Programming
Interfaces (APIs).
3.1.12
best practices
guidelines for securely designing, developing, testing, maintaining or retiring products that the
supplier has determined are commonly recommended by both the security and industrial
automation communities
EXAMPLE Least privilege, economy of mechanism and least common mechanism.
3.1.13
component
one of the parts that make up a product or system
Note 1 to entry: A component may be hardware or software and may be subdivided into other components.
3.1.14
configuration management
discipline of identifying the components of an evolving system for the purposes of controlling
changes to those components and maintaining continuity and traceability throughout the
life-cycle
3.1.15
defense in depth
approach to defend the system against any particular attack using several i
...