– 13 – ANSI/ISA-62443-4-2-2018

0 Introduction
NOTE The format of this document follows the ISO/IEC requirements discussed in ISO/IEC Directives, Part 2 [13].
These directives specify the format of this document as well as the use of terms like “shall”, “should”, and “may”. The
requirements specified in normative clauses use the conventions discus sed in Appendix H of the Directives document.
0.1 Overview
Industrial automation and control system (IACS) organizations increasingly use commercial -off-
the-shelf (COTS) networked devices that are inexpensive, efficient and highly automated. Control
systems are also increasingly interconnected with non-IACS networks for valid business reasons.
These devices, open networking technologies and increased connectivity provide an increased
opportunity for cyber-attack against control system hardware and software. That weakness may
lead to health, safety and environmental (HSE), financial and/or reputational consequences in
deployed control systems.

Organizations choosing to deploy business information technology (IT) cyber security solutions to
address IACS security may not fully comprehend the results of their decision. While many business
IT applications and security solutions can be applied to IACS, they need to be applied in an
appropriate way to eliminate inadvertent consequences. For this reason, the approac h used to
define system requirements needs to be based on a combination of functional requirements and
risk assessment, often including an awareness of operational issues as well.

IACS security countermeasures should not have the potential to cause loss of essential services
and functions, including emergency procedures. (IT security countermeasures, as often deployed,
do have this potential.) IACS security goals focus on control system availability, plant protection,
plant operations (even in a degraded mode) and time-critical system response. IT security goals
often do not place the same emphasis on these factors; they may be more concerned with
protecting information rather than physical assets. These different goals need to be clearly stated
as security objectives regardless of the degree of plant integration achieved. A key step in the risk
assessment, as required by ISA‑62443‑2‑1 2 [5], should be the identification of which services and
functions are truly essential for operations. (For example, in some facilities engineering support
may be determined to be a non-essential service or function.) In some cases, it may be acceptable
for a security action to cause temporary loss of a non -essential service or function, unlike an
essential service or function that should not be adver sely affected.

This document provides the cyber security technical requirements for the components that make
up an IACS, specifically the embedded devices, network components, host components and
software applications. This document derives its requirements from the IACS System security
requirements described in ISA‑62443‑3‑3 [11]. The intent of this document is to specify security
capabilities that enable a component to mitigate threats for a given security level (SL) without the
assistance of compensating countermeasures.

The primary goal of the ISA‑62443 series is to provide a flexible framework that facilitates
addressing current and future vulnerabilities in IACS and applying necessary mitigations in a
systematic, defensible manner. It is important to understand that the intention of the ISA‑62443
series is to build extensions to enterprise security that adapt the requirements for business IT
systems and combines them with the unique requirements for strong integrity and availability
needed by IACS.

0.2 Purpose and intended audience

The IACS community audience for this document is intended to be asset owners, system
integrators, product suppliers, and, where appropriate, compliance authorities. Compliance

—————————
2 Many documents in the ISA‑62443 series are currently under review or in development.
ANSI/ISA-62443-4-2-2018 – 14 –

authorities include government agencies and regulators with the legal aut hority to perform audits
to verify compliance with governing laws and regulations.

System integrators will use this document to assist them in procuring control system components
that make up an IACS solution. The assistance will be in the form of helping system integrators
specify the appropriate security capability level of the individual components they require. The
primary standards for system integrators are ISA‑62443‑2‑1 [5], ISA‑62443‑2‑4 [8],
ISA‑62443‑3‑2 [10] and ISA‑62443‑3‑3 [11] that provide organizational and operational
requirements for a security management system and guide them through the process of defining
security zones for a system and the target security capability levels (SL-T) for those zones. Once
the SL-T for each zone has been defined, components that provide the necessary security
capabilities can be used to achieve the SL-T for each zone.

Product suppliers will use this document to understand the requirements placed on control system
components for specific security capability level (SL-C)s of those components. A component may
not provide a required capability itself but may be designed to integrate with a higher level entity
and thus benefit from that entity’s capability - for example an embedded device may not be
maintaining a user directory itself, but may integrate with a system wide authentication and
authorization service and thus still meet the requirements to provide individual user authentication,
authorization and management capabilities. This document will guide product suppliers as to
which requirements can be allocated and which requirements need to be native in the components.
As defined in Practice 8 of ISA‑62443‑4‑1 [12], the product supplier will provide documentation
of how to properly integrate the component into a system to meet a specific SL-T.

The component requirements (CRs) in this document are derived from the system requirements
(SRs) in ISA‑62443‑3‑3 [11]. The requirements in ISA‑62443‑3‑3 [11] are referred to as SRs,
which are derived from the overall foundational requirements (FRs) defined in ISA‑62443‑1‑1 [1].
CRs may also include a set of requirement enhancements (REs). The combination of CRs and REs
is what will determine the target security level that a component is capable of .

This document provides component requirements for four types of components: software
application, embedded device, host device and network device. Thus the CRs for each type of
component will be designated as follows:

• Software application requirements (SAR);

• Embedded device requirements (EDR);
• Host device requirements (HDR); and
• Network device requirements (NDR).
The majority of the requirements in this document are the same for the four types of components
and are thus designated simply as a CR. When there are unique component-specific requirements
then the generic requirement will state that the requirements are component-specific and are
located in the component-specific requirements clauses of this standard.
 – 15 – ANSI/ISA-62443-4-2-2018

Figure 1 shows a graphical depiction of the ISA‑62443 series when this document was written.

Figure 1 – ISA‑62443 Work Products

 – 17 – ANSI/ISA-62443-4-2-2018

1 Scope

This document in the ISA‑62443 series provides detailed technical control system component
requirements (CRs) associated with the seven foundational requirements (FRs) described in
ISA‑62443‑1‑1 [1] including defining the requirements for control system capability security levels
and their components, SL-C(component).

As defined in ISA‑62443‑1‑1 there are a total of seven Foundational Requirements (FRs):

a) Identification and authentication control (IAC),

b) Use control (UC),
c) System integrity (SI),
d) Data confidentiality (DC),
e) Restricted data flow (RDF),
f) Timely response to events (TRE), and
g) Resource availability (RA).
These seven FRs are the foundation for defining control system security capability levels. Defining
security capability levels for the control system component is the goal and objective of this
document as opposed to SL-T or achieved SLs (SL-A), which are out of scope.

NOTE Refer to ISA‑62443‑2‑1 [5] for an equivalent set of non-technical, program-related, capability requirements
necessary for fully achieving a SL-T(control system).

2 Normative references
The following referenced documents are indispensable for the application 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.

ISA‑62443‑1‑1 – Security for industrial automation and control systems, Part 1-1: Concepts and
models [1]

ISA‑TR62443‑1‑2, Security for industrial automation and control systems, Part 1-2: Master
glossary of terms and abbreviations [2]

ISA‑62443‑3‑3:2013 – Security for industrial automation and control systems, Part 3-3: System
security requirements and security levels [11]

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 the normative references
specified in Clause 2 apply, in addition to the following.
NOTE Many of the following terms and definitions are originally based on relevant International Organization for
Standardization (ISO), International Electrotechnical Commission (IEC) and U.S. National Institute of Standards and
Technology (NIST) sources, sometimes with minor modifications to en hance suitability for IACS security requirements.
3.1.1
asset
physical or logical object having either a perceived or actual value to the IACS
Note 1 to entry: In this specific case, an asset is any item that should be protected as part of the IACS security
management system.
Note 2 to entry: An asset is not limited to the IACS alone, but can also include the physical assets under its control