prEN IEC 62541-21:2024
(Main)OPC unified architecture - Part 21: Device onboarding
OPC unified architecture - Part 21: Device onboarding
OPC Unified Architecture – Teil 21: Onboarding von Geräten
Architecture unifiée OPC - Partie 21: Mise en service d'appareils
Enotna arhitektura OPC - 21. del: Povezovanje naprave
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-marec-2024
Enotna arhitektura OPC - 21. del: Vključevanje naprav
OPC unified architecture - Part 21: Device onboarding
Ta slovenski standard je istoveten z: prEN IEC 62541-21:2024
ICS:
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
65E/1046/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 62541-21 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2024-01-26 2024-04-19
SUPERSEDES DOCUMENTS:
65E/956/NP, 65E/1016/RVN
IEC SC 65E : DEVICES AND INTEGRATION IN ENTERPRISE SYSTEMS
SECRETARIAT: SECRETARY:
United States of America Mr Donald (Bob) Lattimer
OF INTEREST TO THE FOLLOWING COMMITTEES: PROPOSED HORIZONTAL STANDARD:
Other TC/SCs are requested to indicate their interest, if any,
in this CDV to the secretary.
FUNCTIONS CONCERNED:
EMC ENVIRONMENT QUALITY ASSURANCE SAFETY
SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft for
Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which
they are aware and to provide supporting documentation.
Recipients of this document are invited to submit, with their comments, notification of any relevant “In Some Countries”
clauses to be included should this proposal proceed. Recipients are reminded that the CDV stage is the final stage for
submitting ISC clauses. (SEE AC/22/2007 OR NEW GUIDANCE DOC).
TITLE:
OPC Unified Architecture – Part 21: Device Onboarding
PROPOSED STABILITY DATE: 2026
NOTE FROM TC/SC OFFICERS:
electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.
IEC CDV 62541-21 © IEC 2023
1 CONTENTS
2 Page
3 FIGURES . iii
4 TABLES . iv
5 1 Scope . 1
6 2 Normative references . 1
7 3 Terms, definitions, and conventions . 2
8 3.1 Terms and definitions . 2
9 3.2 Abbreviations and symbols . 4
10 4 Onboarding Model . 5
11 4.1 Device Lifecycle . 5
12 4.2 Concepts . 7
13 4.2.1 Secure Elements . 7
14 4.2.2 Firmware and Applications . 7
15 4.2.3 Transfer of Physical Control . 8
16 4.2.4 Trust on First Use (TOFU) . 8
17 4.2.5 SoftwareUpdateManager . 9
18 4.2.6 Roles and Privileges . 9
19 4.3 Device Workflows . 10
20 4.3.1 Distribution . 10
21 4.3.2 Onboarding . 10
22 4.3.3 Application Setup . 10
23 4.3.4 Configuration . 10
24 4.3.5 Operation . 10
25 4.3.6 Decommissioning . 11
26 5 Identities . 11
27 5.1 Overview . 11
28 5.2 Device Identity . 11
29 5.3 ProductInstanceUri . 12
30 5.4 Composite Identity . 12
31 6 Ticket Semantics . 13
32 6.1 Tickets . 13
33 6.2 Ticket Distribution. 14
34 6.3 Authentication . 14
35 6.4 Acquiring and Validating Tickets . 15
36 7 Device Authentication . 16
37 7.1 Overview . 16
38 7.2 Pull Management . 18
39 7.3 Push Management . 20
40 7.4 Alternate Authentication Models . 21
41 8 Ticket Syntax . 22
42 8.1 Signed Ticket Encoding . 22
43 8.2 Ticket Types . 23
44 8.2.1 EncodedTicket . 23
45 8.2.2 BaseTicketType . 24
46 8.2.3 DeviceIdentityTicketType . 24
47 8.2.4 CompositeIdentityTicketType . 25
48 8.2.5 TicketListType . 25
IEC CDV 62541-21 © IEC 2023 ii
49 8.2.6 CertificateAuthorityType . 26
50 9 Information Model . 26
51 9.1 Overview . 26
52 9.2 Registrar . 26
53 9.2.1 Overview . 26
54 9.2.2 DeviceRegistrarType . 27
55 9.2.3 ProvideIdentities . 28
56 9.2.4 UpdateSoftwareStatus. 29
57 9.2.5 RegisterDeviceEndpoint . 29
58 9.2.6 GetManagers . 30
59 9.2.7 ManagerDescription . 31
60 9.2.8 RegisterManagedApplication . 31
61 9.2.9 DeviceRegistrar . 32
62 9.2.10 DeviceRegistrarAdminType . 32
63 9.2.11 RegisterTickets . 33
64 9.2.12 UnregisterTickets . 33
65 9.2.13 DeviceRegistrationAuditEventType . 34
66 9.2.14 DeviceIdentityAcceptedAuditEventType . 34
67 9.2.15 DeviceSoftwareUpdatedAuditEventType . 35
68 9.3 Device Configuration Application (DCA) . 35
69 9.3.1 Overview . 35
70 9.3.2 ProvisionableDevice . 36
71 9.3.3 ProvisionableDeviceType . 37
72 9.3.4 RequestTickets . 37
73 9.3.5 SetRegistrarEndpoints . 38
74 9.3.6 ApplicationConfigurationType . 38
75 10 Namespaces . 39
76 10.1 Namespace Metadata . 39
77 10.2 Handling of OPC UA Namespaces . 39
78 Annex A (normative) Namespaces and Identifiers . 41
79 A.1 Namespace and Identifiers for the Onboarding Information Model . 41
iii IEC CDV 62541-21 © IEC 2023
82 FIGURES
83 Figure 1 – The Lifecycle of a Device . 5
84 Figure 2 – Device Hardware and Software Layers . 7
85 Figure 3 – Possible Transfers of Physical Control . 8
86 Figure 3 – Relationship between Devices, Actors, Identifiers and Tickets . 11
87 Figure 4 – Device Authentication using Pull Management . 18
88 Figure 5 – Requesting Certificates using Pull Management . 19
89 Figure 6 – Device Authentication using Push Management . 20
90 Figure 7 – Updating Certificates using Push Management . 21
91 Figure 8 – Alternate Authentication Models with Pull Management . 22
92 Figure 9 – Registrar Address Space for Onboarding Workflow . 27
93 Figure 10 – Device Address Space for Onboarding Workflows . 36
IEC CDV 62541-21 © IEC 2023 iv
96 TABLES
97 Table 1 – The Actors in the Device Lifecycle . 5
98 Table 2 – The Stages in the Device Lifecycle . 6
99 Table 3 – Well-known Roles for Onboarding . 9
100 Table 4 – Privileges for Onboarding . 9
101 Table 5 – RFC 7515 Header Fields . 23
102 Table 6 – EncodedTicket Definition . 24
103 Table 7 – BaseTicketType Structure . 24
104 Table 8 – BaseTicketType Definition . 24
105 Table 9 – DeviceIdentityTicketType Structure . 24
106 Table 10 – DeviceIdentityTicketType Definition . 25
107 Table 11 – CompositeIdentityTicketType Structure . 25
108 Table 12 – CompositeIdentityTicketType Definition . 25
109 Table 13 – TicketListType Structure . 25
110 Table 14 – TicketListType Definition . 26
111 Table 15 – CertificateAuthorityType Structure . 26
112 Table 16 – CertificateAuthorityType Definition . 26
113 Table 17 – DeviceRegistrarType Definition . 27
114 Table 18 – ProvideIdentities Method AddressSpace Definition . 29
115 Table 19 – UpdateSoftwareStatus Method AddressSpace Definition . 29
116 Table 20 – RegisterDeviceEndpoint Method AddressSpace Definition . 30
117 Table 21 – GetManagers Method AddressSpace Definition . 30
118 Table 22 – ManagerDescription Structure . 31
119 Table 23 – ManagerDescription Definition . 31
120 Table 24 – RegisterManagedApplication Method AddressSpace Definition . 32
121 Table 25 – DeviceRegistrar Definition. 32
122 Table 26 – DeviceRegistrarAdminType Definition . 32
123 Table 27 – RegisterTickets Method AddressSpace Definition . 33
124 Table 28 – UnregisterTickets Method AddressSpace Definition . 34
125 Table 29 – DeviceRegistrationAuditEventType Definition . 34
126 Table 30 – DeviceIdentityAcceptedAuditEventType Definition. 35
127 Table 31 – DeviceSoftwareUpdatedAuditEventType Definition . 35
128 Table 32 – ProvisionableDevice Object Definition . 37
129 Table 33 – ProvisionableDeviceType Definition . 37
130 Table 34 – RequestTickets Method AddressSpace Definition. 38
131 Table 35 – SetRegistrarEndpoints Method AddressSpace Definition . 38
132 Table 36 – ApplicationConfigurationType Definition . 38
133 Table 37 – NamespaceMetadata Object for this Document . 39
134 Table 38 – Namespaces used in this document . 40
v IEC CDV 62541-21 © IEC 2023
137 INTERNATIONAL ELECTROTECHNICAL COMMISSION
138 ____________
140 OPC UNIFIED ARCHITECTURE –
142 Part 21: Device Onboarding
144 FOREWORD
145 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national
146 electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all
147 questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities,
148 IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS)
149 and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC
150 National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental
151 and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with
152 the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between
153 the two organizations.
154 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus
155 of opinion on the relevant subjects since each technical committee has representation from all interested IEC National
156 Committees.
157 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in
158 that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC
159 cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.
160 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to
161 the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and
162 the corresponding national or regional publication shall be clearly indicated in the latter.
163 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment
164 services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by
165 independent certification bodies.
166 6) All users should ensure that they have the latest edition of this publication.
167 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of
168 its technical committees and IEC National Committees for any personal injury, property damage or other damage of any
169 nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication,
170 use of, or reliance upon, this IEC Publication or any other IEC Publications.
171 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable
172 for the correct application of this publication.
173 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights.
174 IEC shall not be held responsible for identifying any or all such patent rights.
175 The main task of IEC technical committees is to prepare International Standards. However, a technical
176 committee may propose the publication of a technical report when it has collected data of a different
177 kind from that which is normally published as an International Standard, for example "state of the art".
178 International Standard IEC 62541-21 has been prepared by subcommittee 65E: Devices and integration
179 in enterprise systems, of IEC technical committee 65: Industrial-process measurement, control and
180 automation.
181 The text of this international standard is based on the following documents:
CDV Report on voting
65E/XX/CDV 65E/XX/RVC
183 Full information on the voting for the approval of this international standard can be found in the report
184 on voting indicated in the above table.
185 This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
186 Throughout this document and the other Parts of the series, certain document conventions are used:
IEC CDV 62541-21 © IEC 2023 vi
187 Italics are used to denote a defined term or definition that appears in the “Terms and definition” clause
188 in one of the parts of the series.
189 Italics are also used to denote the name of a service input or output parameter or the name of a structure
190 or element of a structure that are usually defined in tables.
191 The italicized terms and names are also often written in camel-case (the practice of writing compound
192 words or phrases in which the elements are joined without spaces, with each element's initial letter
193 capitalized within the compound). For example, the defined term is AddressSpace instead of Address
194 Space. This makes it easier to understand that there is a single definition for AddressSpace, not
195 separate definitions for Address and Space.
196 A list of all parts of the IEC 62541 series is included in IEC 62541-1 clause 4 Structure of the OPC UA
197 series and published under the general title OPC Unified Architecture, can be found on the IEC website.
198 The committee has decided that the contents of this publication will remain unchanged until the stability
199 date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to the specific
200 publication. At this date, the publication will be
201 • reconfirmed,
202 • withdrawn,
203 • replaced by a revised edition, or
204 • amended.
206 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.
1 IEC CDV 62541-21 © IEC 2023
213 OPC UNIFIED ARCHITECTURE
215 Part 21: Device Onboarding
218 1 Scope
219 This part defines the life cycle of Devices and Composites and mechanisms to verify their
220 authenticity, set up their security and maintain their configuration.
221 2 Normative references
222 The following documents, in whole or in part, are normatively referenced in this document and
223 are indispensable for its application. For dated references, only the edition cited applies. For
224 undated references, the latest edition of the referenced document (including any amendments
225 and errata) applies.
226 IEC 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts
227 IEC 62541-2, OPC Unified Architecture – Part 2: Security
228 IEC 62541-3, OPC Unified Architecture – Part 3: Address Space Model
229 IEC 62541-4, OPC Unified Architecture – Part 4: Services
230 IEC 62541-5, OPC Unified Architecture – Part 5: Information Model
231 IEC 62541-6, OPC Unified Architecture – Part 6: Mappings
232 IEC 62541-7, OPC Unified Architecture – Part 7: Profiles
233 IEC 62541-9, OPC Unified Architecture – Part 9: Alarms and Conditions
234 IEC 62541-12, OPC Unified Architecture – Part 12: Discovery and Global Services
235 IEC 62541-14, OPC Unified Architecture – Part 14: PubSub
236 IEC 62541-22, OPC Unified Architecture – Part 22: Base Network Model
237 IEC 62541-100, OPC Unified Architecture – Part 100: Device Model
239 ISO/IEC 11889, Information technology — Trusted platform module library
240 https://www.iso.org/standard/66510.html
241 802.1AR, Secure Device Identity
242 https://1.ieee802.org/security/802-1ar/
243 RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
244 https://tools.ietf.org/html/rfc3161
245 RFC 5280, Internet X.509 Public Key Infrastructure Certificate
246 https://tools.ietf.org/html/rfc5280
247 RFC 7515, JSON Web Signature (JWS)
248 https://tools.ietf.org/html/rfc7515
249 RFC 7518, JSON Web Algorithms (JWA)
2 IEC CDV 62541-21 © IEC 2023
250 https://tools.ietf.org/html/rfc7518
251 RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One
252 https://tools.ietf.org/html/rfc2045
253 RFC 4648, The Base16, Base32, and Base64 Data Encodings
254 https://tools.ietf.org/html/rfc4648
255 DIN 91406, Automatic identification of physical objects and information on physical objects in
256 IT systems
257 https://www.en-standard.eu/din-spec-91406-automatische-identifikation-von-physischen-
258 objekten-und-informationen-zum-physischen-objekt-in-it-systemen-insbesondere-iot-
259 systemen-text-deutsch-und-englisch/
261 3 Terms, definitions, and conventions
262 3.1 Terms and definitions
263 For the purposes of this document the following terms and definitions as well as the terms and
264 definitions given in IEC 62541-1, IEC 62541-2, IEC 62541-3, IEC 62541-4, IEC 62541-6,
265 IEC 62541-9 and IEC 62541-100 apply.
266 3.1.1
267 Application
268 a program that runs on a Device and communicates with other Applications on the network.
269 Note 1 to entry: Each Application has an identifier that is unique within the network.
270 Note 2 to entry: An OPC UA Application is an Application that supports OPC UA.
272 3.1.2
273 ApplicationUri
274 a globally unique identifier for an OPC UA Application running on a particular Device.
275 Note 3 to entry: The Application Instance Certificate has the ApplicationUri in the subjectAltName field.
276 3.1.3
277 Composite
278 a collection of Devices or Composites assembled into a single unit.
279 Note 1 to entry: Each Composite has a globally unique identifier.
280 Note 2 to entry: A Composite may act as a single Device when connected to a network.
281 Note 3 to entry: A Composite may appear as multiple Devices when connected to a network.
282 3.1.4
283 CompositeBuilder
284 an organization that creates Composites.
285 3.1.5
286 CompositeInstanceUri
287 a globally unique resource identifier assigned by a builder to a Composite.
288 3.1.6
289 DCA Client
290 a DCA which is a Client and supports PullManagement.
291 3.1.7
292 DCA Server
293 a DCA which is a Server and supports PushManagement.
3 IEC CDV 62541-21 © IEC 2023
294 3.1.8
295 Device
296 As defined in IEC 62541-100.
297 Note 1 to entry: For this document a Device also executes one or more OPC UA Applications.
298 Note 2 to entry: a generic computer or mobile device may be a Device if it has a DeviceIdentity Certificate
300 3.1.9
301 Device Configuration Application (DCA)
302 a Client or Server installed on a Device used to configure other applications installed on the
303 same Device.
304 Note 1 to entry: a DCA which is a Client uses PullManagement (see 7.2) to interact with the Registrar.
305 Note 2 to entry: the Registrar uses PushManagement (see 7.3) to interact with a DCA which is a Server.
306 3.1.10
307 DeviceIdentity Certificate
308 a Certificate issued to a Device that identifies the Device.
309 Note 1 to entry: All DeviceIdentity Certificates have the ProductInstanceUri as a subjectAltName.
310 Note 2 to entry: All DeviceIdentity Certificates are IDevID or LDevID Certificates as defined by 802.1AR.
311 Note 3 to entry: The ProductInstanceUri is the ApplicationUri when the DeviceIdentity Certificate is used to create a
312 SecureChannel.
313 3.1.11
314 Distributor
315 an organization that re-sells Devices and/or Composites.
316 Note 1 to entry: A Distributor may enhance Devices and Composites by adding customized products or services.
317 3.1.12
318 Manufacturer
319 an organization that creates Devices.
320 3.1.13
321 OwnerOperator
322 an organization deploying and operating a system that comprises of Devices, Composites or
323 other computers connected via a network.
324 3.1.14
325 Privilege
326 a named set of permissions or access rights which are needed to perform a task.
327 3.1.15
328 ProductInstanceUri
329 a globally unique resource identifier assigned by the manufacturer to a Device.
330 3.1.16
331 Registrar
332 an OPC UA Application that registers and authenticates Devices added to the network.
333 3.1.17
334 SystemIntegrator
335 an organization that installs and configures a system for an OwnerOperator that comprises of
336 Devices, Composites or other computers connected via a network.
337 3.1.18
338 SecureElement
339 a hardware component that protects Private Keys from unauthorized access and disclosure.
340 3.1.19
341 Ticket
342 a document that identifies a Device or Composite and has a DigitalSignature.
4 IEC CDV 62541-21 © IEC 2023
343 3.2 Abbreviations and symbols
344 API Application Programming Interface
345 ASN.1 Abstract Syntax Notation #1
346 CA Certificate Authority
347 CRL Certificate Revocation List
348 DCA Device Configuration Application
349 DER ASN.1 Distinguished Encoding Rules
350 DHCP Dynamic Host Configuration Protocol
351 DNS Domain Name System
352 ERP Enterprise Resource Planning
353 GDS Global Discovery Server
354 IDevID Initial Device Identifier
355 LDevID Locally Significant Device Identifier
356 LDS Local Discovery Server
357 mDNS Multicast Domain Name System
358 NAT Network Address Translation
359 PKCS Public Key Cryptography Standards
360 TLS Transport Layer Security
361 TPM Trusted Platform Module
362 UA Unified Architecture
363 URI Uniform Resource Identifier
364 URN Uniform Resource Name
5 IEC CDV 62541-21 © IEC 2023
366 4 Onboarding Model
367 4.1 Device Lifecycle
368 The Onboarding model is designed to allow the configuration of a Device to be managed over
369 the complete lifecycle of the Device from manufacture to decommissioning. The entire lifecycle
370 approach is needed because Devices, unlike PC-class computers, are often shipped with
371 automation software pre-installed and are connected directly to sensitive networks. This
372 requires a process to authenticate Devices before they are given access to a sensitive network.
373 The complete life cycle of a Device is shown in Figure 1.
Manufacturer
CompositeBuilder
Device Composite
Manufacture Assembly
Distributor
Distribution
Integrator
Application Device
Setup Onboarding
Operator
Configuration Operation
Decommisioning
375 Figure 1 – The Lifecycle of a Device
376 The actors in the Device lifecycle are described in Table 1.
377 Table 1 – The Actors in the Device Lifecycle
Actor Description
Device A computer that is able to communicate via a network. A Device has a unique
identifier and may have one or more Applications (see 3.1.4)
6 IEC CDV 62541-21 © IEC 2023
Actor Description
Composite A collection of Devices or Composites assembled into a single unit. Each Composite
has a unique identifier and may appear as a single Device on a network or it may
appear as multiple Devices (see 3.1.3).
Application A program that runs on a Device. Each Application has a unique identifier and
communicates with other Applications on the network (see 3.1.1).
OwnerOperator An organization deploying and operating a system that comprises of Devices,
Composites or other computers connected via a network (see 3.1.13).
Manufacturer An organization that creates Devices (see 3.1.12).
CompositeBuilder An organization that creates Composites (see 3.1.4).
Distributor An organization that re-sells Devices and/or Composites. A Distributor enhances
Devices and Composites by adding customized products or services before resale
(see 3.1.11).
SystemIntegrator An organization that installs and configures a system for an OwnerOperator that
comprises of Devices, Composites or other computers connected via a network (see
3.1.17).
RegistrarAdmin A user authorized to change the configuration of the Registrar.
SoftwareUpdateAdmin A user authorized to update the firmware running on a Device.
SecurityAdmin A user authorized to make changes to security configuration for Clients and Servers
running on the network.
379 The stages in the lifecycle for a single Device are described in Table 2. This information model
380 defines mechanisms to automate some of the tasks necessary for each stage.
381 Table 2 – The Stages in the Device Lifecycle
Stage Description
Device Manufacture A Device is created and a DeviceIdentity Certificate is assigned. This Certificate is
provided when the Device is transferred to other actors. During Device Manufacture,
Applications may be installed on the Device. A Ticket describing the Device is created
and signed by the Manufacturer.
Composite Assembly A Composite is created from Devices and a unique identity is assigned to the
Composite. This identity is provided when the Composite is transferred to other actors.
During Composite Assembly, Applications may be installed on the Devices contained in
the Composite. A Ticket describing the Composite is created and signed by the
CompositeBuilder.
Distribution The Device or Composite is stored until it is delivered to a CompositeBuilder,
SystemIntegrator, OwnerOperator or another Distributor.
Onboarding The SystemIntegrator connects a Device to the network and verifies that the identity
reported by the Device matches the identity in a Ticket provided by the Manufacturer or
CompositeBuilder.
Application Setup The SystemIntegrator configures the Applications running on the Device or Composite
so they can communicate with other Applications running in the system. This process
includes distributing TrustLists and issuing Certificates.
Configuration The OwnerOperator performs tasks that are not done while the Device is in full
operation, such as updating firmware, installing new Applications, or changing
Application configuration.
Operation The Device does the tasks it was deployed to do.
Decommissioning The Device has all access revoked and, if the Device is still functional, then it is reset
to the default factory settings.
383 The commonly understood concept of “Commissioning” is represented by the Onboarding,
384 Application Setup and Configuration stages.
385 The stages in the Device lifecycle map onto workflows that are defined in this specification. The
386 workflows are described in 4.2.
7 IEC CDV 62541-21 © IEC 2023
387 4.2 Concepts
388 4.2.1 Secure Elements
389 SecureElements are a hardware-based storage for cryptographic secrets that protect them
390 against authorized access and disclosure. The mechanisms defined for Device authentication
391 depend on PrivateKeys that are stored in SecureElements. PrivateKeys stored on Devices
392 without SecureElements can be stolen and reused on counterfeit Devices.
393 OwnerOperators may provision Devices without SecureElements if they have other ways to
394 ensure their authenticity.
395 4.2.2 Firmware and Applications
396 Every Device has multiple layers of hardware and software that are installed and managed at
397 different stages in the lifecycle by different actors. The layers are shown in Figure 2.
DCA Security Configuration Security Configuration2 Security Configuration3
DCA Configuration Application2 Configuration Application3 Configuration
Device Configuration
Application2 Application3
Application (DCA)
Applications
Protected Storage
Firmware (FirmwareVersion)
(IDevID PrivateKey)
Device (ModelName, HardwareVersion)
399 Figure 2 – Device Hardware and Software Layers
400 A Device has firmware that is generally not changed during normal operation. Firmware updates
401 may be provided by the Manufacturer to correct software bugs or patch security flaws. A Device
402 should have a mechanism to ensure the integrity of the system, including the firmware, during
403 the boot process. A Device should have a way to update firmware after onboarding in the
404 OwnerOperator’s system.
405 A Device should have SecureElement storage used for security sensitive elements such as
406 Private Keys. This storage cannot be backed up nor is it affect by a firmware update. The Private
407 Key of DeviceIdentity Certificates (IDevID and LDevID) shall be placed in this storage.
408 A Device shall have a Device Configuration Application (DCA) which is used for Device
409 authentication and setup of other Applications on the Device.
410 A Device may have storage used for Applications and their configuration. A Device should have
411 a mechanism to back up and restore configurations. A Device may support multiple Applications
412 which have their own configuration and security configuration.
413 A Device has storage for the Application security configuration that does not need to be in the
414 protected storage. This storage is separate from the storage for Applications and configurations.
415 Certificates, Trust Lists, administrator credentials are examples of information that is part of the
416 security configuration. The Device shall have mechanisms to ensure that only authorized actors
417 are able to alter the security configuration or access sensitive data such as the PrivateKeys. If
418 a Device supports multiple Applications, the set of authorized actors may be different for each
419 Application.
8 IEC CDV 62541-21 © IEC 2023
420 4.2.3 Transfer of Physical Control
421 Implicit in the Device lifecycle is the notion that Devices and Composites will be physically
422 delivered to different actors. The transfers of physical control that may occur are shown in
423 Figure 3.
Manufacturer
CompositeBuilder
Distributor
Integrator
OwnerOperator
425 Figure 3 – Possible Transfers of Physical Control
426 In many cases, the Distributor belongs to the same organization as the Manufacturer or
427 CompositeBuilder. Similarly, the Integrator and the OwnerOperator may be the same
428 organization.
429 When a transfer of physical control occurs, the supplier ships the equipment (a Device or
430 Composite) and an electronic Ticket (see 6) that describes the equipment. The receiver may
431 use the Ticket to authenticate the origin of the equipment using the mechanisms defined in this
432 standard or save it so it can be provided when the equipment is transferred to another actor.
433 While an actor has physical control, the actor may Install, Provision, Configure or Operate (see
434 Table 2) the equipment. For example, if an actor (e.g., a CompositeBuilder) makes changes to
435 a Device and then transfers this Device to another actor (e.g., an OwnerOperator) then those
436 changes may restrict what the new owner is able to do, i.e., CompositeBuilder may install an
437 Application used for maintenance that the OwnerOperator cannot access.
438 The workflows (see 4.3) describe this process in more detail.
439 4.2.4 Trust on First Use (TOFU)
440 The onboarding process defined in this document describes how an OwnerOperator can
441 authenticate Devices added to the network. This document does not define any mechanisms to
442 allow Devices to authenticate the network it is connected to. This implies that a Device
443 connected to a network will allow itself to be configured via any network that it is connected to.
444 This behaviour is called “Trust on First Use” or TOFU.
445 When first connected to a network the DCA will be in an initial state where it will either attempt
446 to discover a network service that it can get its configuration (PullManagement, see 7.2) or wait
447 for another application to provide its configuration (PushManagement, see 7.3).
448 Once the onboarding process completes the DCA is supplied with credentials that authorize
449 Applications that are allowed to make changes to its security configuration. Devices should
9 IEC CDV 62541-21 © IEC 2023
450 have a mechanism to return the DCA to an initial state which discards all configuration, including
451 all credentials and TrustLists that were assigned in a previous onboarding process.
452 The new state allows the TOFU onboarding process to start again. Note the initial state is not
453 the same as a factory reset which typically deletes all software installed on the Device. The
454 reset mechanism should require proof of physical possession of the Device to ensure it cannot
455 be exploited remotely.
456 The TOFU model exposes the Device to malicious actors that are running on the network. This
457 means the network used for configuration has to be protected to make it harder for a malicious
458 actor to gain access to the network. OwnerOperators should also have network services
459 designed to detect and eliminate malicious applications that attempt to interfere with the
460 onboarding process.
461 Devices may have other ways to assign the credentials provided by the onboarding process in
462 order to avoid the risks associated with TOFU.
463 4.2.5 SoftwareUpdateManager
464 The SoftwareUpdateManager is a system comp
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...