IEC PAS 62443-1-6:2025

Security for industrial automation and control systems - Part 1-6: Application of the 62443 series to the Industrial Internet of Things (IIoT)

IEC PAS 62443-1-6:2025 introduces new communication channels, a new organization of functions, and new cybersecurity concerns. Asset owners are looking for more guidance in how to deal with all these changes. The IEC 62443 series, Security for industrial automation and control systems, can be applied to this new technology, but many asset owners look at the scope of the series and wonder where to start.
This part of IEC 62443 seeks to give guidance to asset owners and their service providers on how the IEC 62443 series can be used to address IIoT. The document points to requirements in the different parts of the IEC 62443 series that might be helpful to the asset owner as they both consider implementing IIoT in their automation solutions as well as dealing with existing IIoT. Product suppliers and service providers can find this document useful as well.
NOTE The drafting committee for IEC 62443 is currently engaged in revision of parts of the standard to recognize emerging technologies, such as IIoT, and this document is part of that on-going effort.
NOTE In accordance with ISO/IEC Directives, Part 1, IEC PASs are automatically withdrawn after 4 years.

General Information

• Status: Published
• Publication Date: 18-Dec-2025
• ICS: 25.040.40 - Industrial process measurement and control
• Technical Committee: TC 65 - Industrial-process measurement, control and automation

Overview

IEC PAS 62443-1-6:2025 - Security for industrial automation and control systems, Part 1-6 - provides guidance on applying the IEC 62443 series to the Industrial Internet of Things (IIoT). Published as a Publicly Available Specification (PAS), this document helps asset owners, product suppliers and service providers understand how IIoT changes communication paths, function allocation and cybersecurity concerns in IACS (industrial automation and control systems). It maps IIoT issues to relevant parts of the IEC 62443 series and informs future revisions. (Note: IEC PASs are withdrawn automatically after four years.)

Key Topics

• IIoT integration challenges: new communication channels, hybrid industrial–business systems, and the need for virtual as well as physical zone/conduit definitions.
• Functional models: evolution from traditional functional capability architectures to IIoT-integrated models and examples.
• Principal roles and lifecycle responsibilities: alignment of asset owner, product supplier and service provider duties across IIoT deployments.
• Risk assessments: guidance on identifying the System under Consideration (SuC), determining target security levels and assessing impacts on zones, conduits and safety-related functions.
• Foundational requirements (FR1–FR7): considerations for Identification & Authentication, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, and Resource Availability in IIoT contexts.
• Cloud-based functionality (CBF): cloud models (SaaS/PaaS/IaaS) and their shared responsibility models, contractual considerations with IIoT cloud service providers and implications for defense-in-depth.
• Security program integration: training, policies, incident response, authentication/authorization strategies, physical security and maintenance of security programs.

Applications

• Asset owners: map IIoT components into existing IEC 62443-based security programs, perform IIoT-specific risk assessments, set target security levels, and design zone/conduit boundaries that reflect virtualized functions.
• Service providers and system integrators: identify applicable IEC 62443 requirements, define contractual security obligations for cloud-hosted IIoT services, and advise asset owners on defense-in-depth strategies.
• Product suppliers: understand asset owner expectations and relevant IEC 62443 parts to support secure IIoT device and system design.

Related Standards and Notes

• Part of the broader IEC 62443 series (Security for industrial automation and control systems).
• Drafting committee is revising IEC 62443 parts to explicitly address emerging technologies such as IIoT; this PAS provides interim guidance and input to those revisions.

This PAS is especially relevant for organizations implementing IIoT in operational technology (OT) environments and for teams mapping IIoT/cloud services to IEC 62443 security requirements.

Standards Content (Sample)

IEC PAS 62443-1-6 ®
Edition 1.0 2025-12
PUBLICLY AVAILABLE
SPECIFICATION
Security for industrial automation and control systems -
Part 1-6: Application of the 62443 series to the Industrial Internet of Things (IIoT)
ICS 25.040.40  ISBN 978-2-8327-0905-4

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 Secretariat 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 - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
publications previews, graphical symbols and the glossary.
The advanced search enables to find IEC publications by a
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
The world's leading online dictionary on electrotechnology,
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: [e-mail].
CONTENTS
FOREWORD. 3
INTRODUCTION . 5
1 Scope . 6
2 Normative references . 6
3 Terms, definitions, abbreviated terms and acronyms . 6
3.1 Terms and definitions . 6
3.2 Abbreviated terms and acronyms . 8
4 From current functional models to the future . 9
4.1 General . 9
4.2 Traditional model representation of functional capability architecture . 10
4.3 Challenges of IIoT within functional model . 10
4.3.1 General . 10
4.3.2 Hybrid industrial-business systems . 12
4.3.3 Zero trust architecture . 12
4.4 Example of functional model with IIoT integrated . 13
5 Principal roles and how they interact in IIoT . 14
6 Integrating IIoT into the asset owner's security program . 17
6.1 Overview . 17
6.2 Recommendations . 17
6.2.1 Risk to IACS . 17
6.2.2 Training for personnel . 17
6.2.3 Impact on business continuity . 17
6.2.4 Security policies and procedures . 18
6.2.5 Policies and procedures for physical security and physical assets . 18
6.2.6 Policies and activities around IIoT . 18
6.2.7 Authentication strategy . 18
6.2.8 Authorization policies and procedures . 18
6.2.9 Security program maintenance . 19
6.2.10 Information and document management . 19
6.2.11 Incident planning and response . 19
6.2.12 Defense-in-depth strategy . 19
6.2.13 Conformance with the IEC 62443 series . 19
7 Risk assessments of IIoT . 20
7.1 Overview . 20
7.2 Recommendations . 20
7.2.1 Identify the SuC . 20
7.2.2 Cybersecurity risk assessment . 20
7.2.3 Target security levels . 20
7.2.4 Logical or physical separation . 21
7.2.5 Implications for safety-related zones . 21
7.2.6 Impact on essential functions . 21
7.2.7 Impact on zone and conduit boundaries . 21
8 IIoT and foundational requirements . 22
8.1 Overview . 22
8.2 Recommendations . 22
8.2.1 FR 1 – Identification and authentication control . 22
8.2.2 FR 2 – Use control . 22
8.2.3 FR 3 – System integrity . 23
8.2.4 FR 4 – Data confidentiality . 23
8.2.5 FR 5 – Restricted data flow . 24
8.2.6 FR 6 – Timely response to events . 24
8.2.7 FR 7 – Resource availability . 24
9 Considerations for integration of IIoT with cloud-based functionality into IACS . 25
9.1 Overview . 25
9.2 Cloud models . 25
9.3 Recommendations . 27
9.3.1 Risk assessment . 27
9.3.2 IIoT CBF and risk . 29
9.3.3 Importance of contractual relationships with IIoT CBF . 33
Bibliography . 34

Figure 1 – Example of a functional model with IIoT integration . 11
Figure 2 – Example of hybrid virtualized IACS with IIoT integrated into the PERA
architecture . 14
Figure 3 – Alignment of roles across IIoT lifecycle . 15
Figure 4 – Shared responsibilities for SaaS, PaaS and IaaS . 26
Figure 5 – High-level example of zones and conduits in an IACS with IIoT CBF . 28

Table 1 – Roles and relevant documents . 16
Table 2 – Examples of security measures and potential impact of IIoT CBF . 30
Table 3 – Examples of security capabilities offered by cloud service providers . 32

INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
Security for industrial automation and control systems -
Part 1-6: Application of the 62443 series to
the Industrial Internet of Things (IIoT)

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) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC PAS 62443-1-6 has been prepared by IEC technical committee 65: Industrial-process
measurement, control and automation and the liaison ISA99: ISA committee on Security for
industrial automation and control systems. It is a Publicly Available Specification.
The text of this Publicly Available Specification is based on the following documents:
Draft Report on voting
65/1155/DPAS 65/1176/RVDPAS
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this Publicly Available Specification is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, [and the
ISO/IEC Directives, JTC 1 Supplement] available at www.iec.ch/members_experts/refdocs. The
main document types developed by IEC are described in greater detail at
www.iec.ch/publications.
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.
Text in bold: Lead recommendations (in Clause 6 to Clause 9).
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
NOTE In accordance with ISO/IEC Directives, Part 1, IEC PASs are automatically withdrawn after 4 years.

INTRODUCTION
Today the growing availability of Industrial Internet of Things (IIoT) has widened the array of
technologies and methodologies available for use in industrial automation environments. Much
of the IEC 62443 series was written before IIoT was common but provides a strong basis for
securing these environments. The series can provide a risk-based, defense-in-depth focus that
will assist asset owners and their service providers in navigating the use of IIoT in their own
systems.
This document focuses on the use of IIoT in industrial automation infrastructure, components,
systems, and solutions to identify aspects of the IEC 62443 series that affect IIoT
implementations.
The use of IIoT introduces new communication paths and new ways to allocate functionality in
the automation context. By their nature, IIoT devices introduce functionality into parts of the
automation and control system that have not previously had external communications. For
example, multiple functions can be integrated into a single physical device, and these functions
can represent functions traditionally allocated to different security zones. Also, IIoT can allow
functions traditionally allocated to a single device to be distributed among a wider network of
components, including the use of cloud services. The introduction of IIoT emphasizes the need
to consider the requirements of functions, their allocation to zones, and the interconnection of
these zones with conduits in a virtual sense, as well as in the traditional physical sense. These
changes then permeate through the cybersecurity decisions made.
This document identifies parts of the IEC 62443 series that might be relevant to asset owners
and service providers as they consider the implementation and operation of IIoT in their IACS.
Product suppliers can find assistance in this document in determining asset owner concerns
and requirements.
In addition, this document will provide input to future revisions of the series by identifying
changes or gaps that are needed with the introduction of IIoT, both with and without cloud-
based functionality.
1 Scope
Industrial Internet of Things (IIoT) technology introduces new communication channels, a new
organization of functions, and new cybersecurity concerns. Asset owners are looking for more
guidance in how to deal with all these changes. The IEC 62443 series, Security for industrial
automation and control systems, can be applied to this new technology, but many asset owners
look at the scope of the series and wonder where to start.
This part of IEC 62443 seeks to give guidance to asset owners and their service providers on
how the IEC 62443 series can be used to address IIoT. The document points to requirements
in the different parts of the IEC 62443 series that might be helpful to the asset owner as they
both consider implementing IIoT in their automation solutions as well as dealing with existing
IIoT. Product suppliers and service providers can find this document useful as well.
NOTE The drafting committee for IEC 62443 is currently engaged in revision of parts of the standard to recognize
emerging technologies, such as IIoT, and this document is part of that on-going effort.
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 TS 62443‑1‑1, Security for industrial automation and control systems - Part 1-1:
Terminology, concepts, and models
3 Terms, definitions, abbreviated terms and acronyms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC TS 62443‑1‑1 and
the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
– IEC Electropedia: available at https://www.electropedia.org/
– ISO Online browsing platform: available at https://www.iso.org/obp
3.1.1
cloud
collection of networked remote servers
[SOURCE: ISO 20294:2018 [25], 3.5.8]
3.1.2
cloud computing
paradigm for enabling network access to a scalable and elastic pool of shareable physical or
virtual resources with self-service provisioning and administration on-demand
Note 1 to entry: Examples of resources include servers, operating systems, networks, software, applications, and
storage equipment.
[SOURCE: ISO/IEC 20924:2024 [30], 3.1.5, modified – added Note 1 to entry from
ISO/IEC TR 22678:2019 [10], 3.1]
3.1.3
cloud service
one or more capabilities offered via cloud computing invoked using a defined interface
Note 1 to entry: Capabilities of cloud computing can include infrastructure as a service (IaaS), software as a service
(SaaS) and platform as a service (PaaS) for cloud-based infrastructure, application, security and storage services
[SOURCE: ISO/IEC 20924:2024 [30], 3.1.6, modified – added Note 1 to entry from
ISO/IEC 17788:2014, 3.2.15]
3.1.4
cloud service provider
party that makes cloud-based services available
[SOURCE: ISO/IEC 17788:2014 [4], 3.2.15]
3.1.5
essential function
function or capability that is required to maintain health, safety, the environment and availability
for the equipment under control
[SOURCE: IEC 62443-3-3:2013 [34], 3.1.22, modified – the note has been deleted.]
3.1.6
Industrial Internet of Things
IIoT
technology with the ubiquitous presence of connectivity that is integrated into the traditional
industrial automation and control system(s) (IACS)
Note 1 to entry: Ubiquitous connectivity means industrial resources can be connected or linked through wired or
wireless ways, forming convenient and efficient information channels and realizing interconnection and
intercommunication of industrial resource data; and the breadth and depth of the connection between machines and
machines, machines and people, and machines and the environment are expanded.
3.1.7
infrastructure as a service
IaaS
provisioning of resources to a customer where the customer does not manage or control the
underlying physical or virtual resources, but does have control over operating systems, storage
and deployed applications that use the physical and virtual resources
Note 1 to entry: The customer may also have limited ability to control certain networking components (for example,
host firewalls).
[SOURCE: ISO/IEC 17788:2014 [4], 3.2.24, modified – the actual definition has been deleted,
the text of the note has been made into the definition, with “provisioning of resources to a
customer where” added, and the last sentence of the note has been kept as a note.]
3.1.8
platform as a service
PaaS
capability provided to the customer to deploy onto the cloud infrastructure customer-created or
acquired applications created using programming languages, libraries, services, and tools
supported by the provider
Note 1 to entry: The customer does not manage or control the underlying cloud infrastructure including network,
servers, operating systems, or storage, but has control over the deployed applications and possibly configuration
settings for the application-hosting environment.
[SOURCE: NIST SP 800-145:2011 [27], last paragraph of page 2, modified – replaced both
instances of “consumer”' with ”customer” and added the Note 1 to entry.]
3.1.9
private cloud
server farm for a closed user group
[SOURCE: ISO/IEC TR 26927:2011 [14], 3.35]
3.1.10
software as a service
SaaS
capability provided to the customer to use the provider's applications running on a cloud
infrastructure
Note 1 to entry: The applications are accessible from various client devices through either a thin client interface,
such as a web browser (for example, web-based email), or a program interface. The customer does not manage or
control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual
application capabilities, with the possible exception of limited user-specific application configuration settings.
rd
[SOURCE: NIST SP 800-145:2011, 3 paragraph of Clause 2, modified - replaced ”consumer”
with ”customer” and added the Note 1 to entry.]
3.1.11
trustworthiness
ability to meet stakeholder expectations in a verifiable way
Note 1 to entry: Depending on the context or sector, and also on the specific product or service, data, and
technology used, different characteristics apply and need verification to ensure stakeholder expectations are met.
Note 2 to entry: Characteristics of trustworthiness include, for instance, reliability, availability, resilience, security,
privacy, safety, accountability, transparency, integrity, authenticity, quality, usability, and accuracy.
Note 3 to entry: Trustworthiness is an attribute that can be applied to services, products, technology, data and
information as well as, in the context of governance, to organizations.
[SOURCE: ISO/IEC 30145-2:2020 [20], 3.9]
3.1.12
zero trust
collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least
privilege per-request access decisions in information systems and services in the face of a
network viewed as compromised
rd
[SOURCE: NIST SP 800-207:2020 [28], 3 paragraph of Clause 2]
3.2 Abbreviated terms and acronyms
For the purposes of this document, the following abbreviated terms and acronyms apply.
API Application programming interface
CBF Cloud-based functionality
DNP3 Distributed Network Protocol 3
FR Foundational requirement
IaaS Infrastructure as a service
IACS Industrial automation and control system(s)
IIoT Industrial Internet of Things
I/O Input/output
IoT Internet of Things
IT Information technology
JTC Joint technical committee
MQTT Message Queuing Telemetry Transport
NIST [US] National Institute of Standards and Technology
OPC Open Platform Communication
OPC UA OPC Unified Architecture
PaaS Platform as a service
PERA Purdue Enterprise Reference Architecture
SaaS Software as a service
SL Security level
SL-T Target SL
SP [US NIST] Special Publication
SQL Structured query language
SuC System under consideration
TR Technical report
TS Technical specification
VM Virtual machine
4 From current functional models to the future
4.1 General
Application of a functional model is a formal approach to understanding the network and security
architecture and possible weaknesses of an IACS. The most commonly known model is defined
in the Purdue Enterprise Reference Architecture (PERA) . PERA is rooted in assumptions about
technology and the connectivity between IACS components. IIoT with its ubiquitous connectivity
is creating challenges with the application of such functional models.
With the advent of IIoT, the norms of the PERA model have been blurred as conventional
thinking of physical network segregation and levels of functionality are changed by the internet-
connected nature of IIoT. IIoT has not rendered the model's illustration of functionality obsolete
but has blurred the network architecture analogy made during the 1990s on where these
functions can reside. They can reside in physical assets on premises, or within a host housing
multiple virtual components/systems spanning multiple levels of the model. They can also send
and protect information over a secure channel into the cloud. IIoT has now enabled the
decomposition of the traditional monolithic approach that has been taken with the PERA model.
In Clause 4, the traditional functional model is discussed in the context of IIoT and how the
introduction of such technology can be considered within such a model.
___________
http://pera.net/. PERA is an example of a suitable product available commercially. This information s given for
the convenience of users of this document and does not constitute an endorsement by IEC of this product.
4.2 Traditional model representation of functional capability architecture
The PERA model was originally created to define levels or classes of components and systems
of IACS based on their functional capabilities and purposes. It was a way for smart
manufacturing to categorize IACS components and systems of systems in a physical and logical
architecture to begin documenting and conveying how traditional engineering, physical
equipment and processes began integration and interaction with software applications,
business processes, IT networks and automated operations. PERA was adopted within the
IEC 62264 series (ISA 95). Over time the IT and cybersecurity communities began leveraging
the model as an IACS security reference architecture that went beyond the original intent of the
PERA model as a functional capabilities reference model.
The PERA model was not intended to be used as a security model nor as a network reference
model, but as a functional model used to help categorize components based on their functional
capabilities and usage, or lack thereof. The model allowed the community to create classes of
components, and easily communicate what components were traditionally capable of, before
such components became multifunctional. The inclusion of IIoT in the IACS, however, is proving
to be challenging to asset owners who are used to the traditional PERA model as well as to
service providers and product suppliers.
4.3 Challenges of IIoT within functional model
4.3.1 General
IIoT has resulted in IACS that have functional capabilities that transcend multiple levels of the
traditional functional models such as PERA within a single device or application in some cases.
This essentially breaks the interpretation of the model that a system, application or device can
only have functional features and roles at certain levels of the reference model. With IIoT,
applications and components are no longer limited in features at specific levels, even if asset
owners are only using certain features out of those available.
In an IIoT world, the functional grouping of types of components can still be leveraged. It can
be necessary to define multifunctional components in their own zones, creating new types of
device classes while still applying a functional model. For example, legacy components and
systems might have been protected via physical security and network security and
segmentation. With the introduction of IIoT, more consideration will need to be given to
protections at the functional level rather than the traditional physical level, along with
communication channels used to interconnect these functions.
Additionally, some functions may be performed in external hosts, for example by accessing
cloud services. These services may be provided by a cloud service resident within asset owner
facilities or provided by external cloud service providers. Even for cloud-based services resident
within asset owner facilities, it might not be possible for operations to be managed by the IACS
asset owner. For example, the roles of managing the cloud (such as integration, commissioning,
and maintenance) can be done by the asset owner's IT department or contracted to third parties.
In all cases, the determination of acceptable risks is the responsibility of the asset owner. This
impacts the traditional way that IACS cybersecurity performance can be verified.
Traditionally, the design and implementation of a function are fully under the control of the IACS
asset owner. The asset owner ensures that the equipment specified meets requirements, that
the deployed equipment is authentic, and that fraudulent substitutions do not occur.
However, should functions be performed by external hosts not directly under the control of the
IACS asset owner, additional authentication steps for the services will be required. So not only
is it necessary for communications with such service suppliers to be secured, but the
functionality provided by the service has to be authenticated. It is necessary for this
authentication to ensure that the service provides the performance (and security) metrics
expected.
Work in IIoT is tending toward the introduction of the concept of "trustworthiness". This
encompasses not only the idea of "trust" as generally used in the IEC 62443 series, but extends
it to the ability to verify, both initially and on an ongoing basis, that the service is providing all
of the properties expected. In 1987, the IEC and the ISO established a joint technical committee
JTC1 to address information technology (IT). Originally established to promote the Open
Systems Interconnection (OSI) model and related IT standards, over the years JTC1 has grown
and adapted to cover a wide range of IT topics, such as organizing the development of multiple
standards to address trustworthiness issues for information technology, including in relation to
the Internet of Things (IoT). For example, ISO/IEC 27070 [17] defines means to ensure online
verification of trustworthiness and identifies means for remote attestation that the service is
authentic, applicable to both cloud services and intelligent electronic components. Although this
work is being done for traditional IT, the concept and models around trustworthiness can also
be applicable in the IACS environment.
Figure 1 presents an example of how IIoT might work within the functional reference model in
a simplified form with IIoT at different levels of the functional model. Note that this is a functional
model and not an actual architecture.
The trusted IIoT cloud and the green lines represent services and communication channels that
have been verified as trustworthy by the asset owner. In order to do this, the asset owner
developed a set of required properties (such as availability, integrity, confidentiality, etc.) and
then verified that the cloud and channels meet those requirements. The other cloud-based
services and communication channels have not been verified to the same extent and are
represented by red lines. Whether cloud-based services or communication channels are verified
as trustworthy depends on the risk-based decision of the asset owner. For example, in Figure 1,
the activities that are carried out by the trusted IIoT cloud are at the supervisory and control
level and the asset owner can consider such activities as requiring a higher level of security
than activities at other levels. What the level of verification necessary to reach trustworthiness
is dependent on the risk decision of the asset owner.

Figure 1 – Example of a functional model with IIoT integration
___________
Numbers in square brackets refer to the Bibliography.
4.3.2 Hybrid industrial-business systems
Today many of the lower-level IIoT components in the IACS are communicating to enterprise
systems directly and not just through data historians. This opens attack paths that traditionally
were not available to malicious actors. Increasingly third parties are creating I/O modules with
structured query language (SQL) features for programmable logic controllers (PLC). Also, such
modules are being created with their own communication ports, allowing PLCs or I/O cards and
modules to talk upstream to a database. Additionally, those same third parties are creating I/O
modules for protocols such as Open Platform Communication Unified Architecture (OPC UA)
and Message Queuing Telemetry Transport (MQTT) which were built to encourage and enable
convergence with business systems and applications. There are an increasing number of
business use cases and solution offerings that encourage OPC UA and MQTT off-the-shelf
communications all the way to the cloud. Product suppliers are also introducing similar
capabilities into their products. Many of these solutions do not appear to take into consideration
crossing architecture levels nor consider the IEC 62443‑4‑2 system and component security
requirements and security levels.
4.3.3 Zero trust architecture
The changes in the functional model (see 4.2) as well as the rise of hybrid business systems
(see 4.3.2) introduced by IIoT have also led to the development of new architectures. In 4.3.3,
one of those new architectures, zero trust, is discussed. As this is a new architecture, its
applicability to industrial automation, and its inclusion in the IEC 62443 series, is not yet clear.
However, since it is often considered with IIoT, a basic discussion is included here.
Zero trust is an architectural model that focuses on providing security measures around digital
assets and that does not solely or fundamentally depend on defense of network perimeters.
Instead, zero trust architectures require authentication and authorization whenever access is
granted to a resource. The resource can be any application, data, or other asset, and the
requesting party can be users, devices, systems or a combination of these. Traditional
approaches to cybersecurity focus on defending a perimeter and then accepting as trusted any
party that is within that perimeter. With the changes that IIoT can bring to the traditional
functional model (as discussed in detail above) and especially with the introduction of cloud-
based functionality combined with IIoT, the concept of the traditional network perimeter is
eroding. Zero trust architecture is, in part, a response to that erosion.
Under a traditional trust model, the assumption is that device and user identities are not
compromised and that once an identity is authenticated at the perimeter, it can then be trusted
by all resources within that perimeter. It is also assumed that all users and devices act and
operate responsibly and can be trusted. In comparison, a zero trust architecture supposes that
there are attackers within the perimeter and that perimeter authentication cannot be relied on.
A zero trust model could improve an organization's security posture by reducing reliance on
perimeter-based protection. This model does not mean eliminating perimeter security, instead,
providing a further layer of cybersecurity. It is also useful where perimeters cannot be clearly
established, such as when cloud functions are being used. A zero trust architecture does not
replace or eliminate the need for more traditional defense-in-depth approaches.
An example of the application of zero trust principles with IIoT might be an architecture in which
IIoT components are granted access to other devices and applications only after the
components are assessed for risks and approved within the set parameters of normal
behaviour, whether the resource is inside or outside of the IACS' boundary. The IIoT
components can then be verified against baselined behaviours before being granted access to
other devices and applications in the network.
There are similarities between the discussions around zero trust architecture and the concept
of trustworthiness. Although the current IEC 62443 series does not discuss either concept at
this time, both are generating interest and will probably require more work in the future.
4.4 Example of functional model with IIoT integrated
There has been an evolution of communication in IACS from serial to internet protocol
dependency with a corresponding increase in the functionality of routing protocols. IIoT
represents a further change with dependencies on various data interchange formats, sending
data over public networks to cloud environments which can be outside the asset owner's
environment. These changes lead to the need for new measures to secure data in transit with
a greater level of granularity. The span of OSI layers which represent communication risks now
includes the application layer with the introduction of IIoT.
Figure 2 illustrates a high-level example of a virtual machine (VM) host running multiple
virtualized instances in the control level with IIoT integrated. Virtualized components operating
inside VM hosts can operate at the I/O devices, control, and supervisory levels of the PERA.
These virtualized IACS connect over secured application programming interfaces (APIs) and
are integrated into various levels of the PERA functional model as well as sending data to the
cloud. API cybersecurity gateways (which are systems according to IEC 62443‑3‑3) are
implemented to protect and secure the authorized traffic to the virtualized IACS. APIs are
developed and implemented with the required security to mitigate against malevolent and
unauthorized reading, writing or execution using common industrial protocols, such as Modbus,
MQTT, DNP3 and BACnet . Note that, in this example, the asset owner has verified the
trustworthiness of the cloud service for IIoT running at lower functional levels ("Trusted IIoT
Cloud").
___________
Modbus, MQTT, DNP3 and BACnet are examples of suitable products available commercially. This information
is given for the convenience of users of this document and does not constitute an endorsement by IEC of these
products.
Figure 2 – Example of hybrid virtualized IACS with IIoT integrated
into the PERA architecture
The integration of IIoT and cloud service into the functioning of the IACS can move the zones
and conduits concepts closer to where data is being created and processed in applications.
5 Principal roles and how they interact in IIoT
The IEC 62443 series discusses many activities and responsibilities in terms of roles. Roles in
IEC 62443 are defined as follows:
– Asset owner is accountable for the IACS including its cybersecurity posture and the
associated risks throughout the lifecycle. It also defines the acceptable residual
cybersecurity risk as an input requirement for all activities along the IACS lifecycle.
– Maintenance service provider is responsible for the maintenance and decommissioning of
the automation solution. The maintenance service provider also has the responsibility for
decommissioning parts or the whole automation solution. Measures to match the acceptable
residual cybersecurity risk during decommissioning typically include the active purging of
sensitive data.
– Integration service provider is responsible for the design and deployment as well as
commissioning and validation of the security measures of the automation solution. Note that
in this document, integration and maintenance service providers are referred to collectively
as service providers.
– Product supplier is responsible for the development and support of products used in the
automation solution. The activities include the development of security capabilities to be
used for the deployment of the security measures of the holistic protection scheme.
When working with IIoT with cloud-based functionality, there is a need to define the role of the
cloud service provider and this document uses the following definition:
– Cloud service provider makes cloud-based services available such as infrastructure as a
service (IaaS), software as a service (SaaS) and platform as a service (PaaS).
Full discussions of cloud-based services and the role of the cloud service provider can be fou
...