The Onboarding model is designed to allow the configuration of a Device to be managed over the complete lifecycle of the Device from manufacture to decommissioning. The entire lifecycle approach is needed because Devices, unlike PC-class computers, are often shipped with automation software pre-installed and are connected directly to sensitive networks. This requires a process to authenticate Devices before they are given access to a sensitive network.

The complete life cycle of a Device is shown in Figure 1.

Figure 1 – The Lifecycle of a Device

The actors in the Device lifecycle are described in Table 1.

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).
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.

The stages in the lifecycle for a single Device are described in Table 2. This information model defines mechanisms to automate some of the tasks necessary for each stage.

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.

The commonly understood concept of “Commissioning” is represented by the Onboarding, Application Setup and Configuration stages.

The stages in the Device lifecycle map onto workflows that are defined in this specification. The workflows are described in 4.2.

SecureElements are a hardware-based storage for cryptographic secrets that protect them against authorized access and disclosure. The mechanisms defined for Device authentication depend on PrivateKeys that are stored in SecureElements. PrivateKeys stored on Devices without SecureElements can be stolen and reused on counterfeit Devices.

OwnerOperators may provision Devices without SecureElements if they have other ways to ensure their authenticity.

Every Device has multiple layers of hardware and software that are installed and managed at different stages in the lifecycle by different actors. The layers are shown in Figure 2.

Figure 2 – Device Hardware and Software Layers

A Device has firmware that is generally not changed during normal operation. Firmware updates may be provided by the Manufacturer to correct software bugs or patch security flaws. A Device should have a mechanism to ensure the integrity of the system, including the firmware, during the boot process. A Device should have a way to update firmware after onboarding in the OwnerOperator’s system.

A Device should have SecureElement storage used for security sensitive elements such as Private Keys. This storage cannot be backed up nor is it affect by a firmware update. The Private Key of DeviceIdentity Certificates (IDevID and LDevID) shall be placed in this storage.

A Device shall have a Device Configuration Application (DCA) which is used for Device authentication and setup of other Applications on the Device.

A Device may have storage used for Applications and their configuration. A Device should have a mechanism to back up and restore configurations. A Device may support multiple Applications which have their own configuration and security configuration.

A Device has storage for the Application security configuration that does not need to be in the protected storage. This storage is separate from the storage for Applications and configurations. Certificates, Trust Lists, administrator credentials are examples of information that is part of the security configuration. The Device shall have mechanisms to ensure that only authorized actors are able to alter the security configuration or access sensitive data such as the PrivateKeys. If a Device supports multiple Applications, the set of authorized actors may be different for each Application.

Implicit in the Device lifecycle is the notion that Devices and Composites will be physically delivered to different actors. The transfers of physical control that may occur are shown in Figure 3.

Figure 3 – Possible Transfers of Physical Control

In many cases, the Distributor belongs to the same organization as the Manufacturer or CompositeBuilder. Similarly, the Integrator and the OwnerOperator may be the same organization.

When a transfer of physical control occurs, the supplier ships the equipment (a Device or Composite) and an electronic Ticket (see 6) that describes the equipment. The receiver may use the Ticket to authenticate the origin of the equipment using the mechanisms defined in this standard or save it so it can be provided when the equipment is transferred to another actor.

While an actor has physical control, the actor may Install, Provision, Configure or Operate (see Table 2) the equipment. For example, if an actor (e.g., a CompositeBuilder) makes changes to a Device and then transfers this Device to another actor (e.g., an OwnerOperator) then those changes may restrict what the new owner is able to do, i.e., CompositeBuilder may install an Application used for maintenance that the OwnerOperator cannot access.

The workflows (see 4.3) describe this process in more detail.

The onboarding process defined in this document describes how an OwnerOperator can authenticate Devices added to the network. This document does not define any mechanisms to allow Devices to authenticate the network it is connected to. This implies that a Device connected to a network will allow itself to be configured via any network that it is connected to. This behaviour is called “Trust on First Use” or TOFU.

When first connected to a network the DCA will be in an initial state where it will either attempt to discover a network service that it can get its configuration (PullManagement, see 7.2) or wait for another application to provide its configuration (PushManagement, see 7.3).

Once the onboarding process completes the DCA is supplied with credentials that authorize Applications that are allowed to make changes to its security configuration. Devices should have a mechanism to return the DCA to an initial state which discards all configuration, including all credentials and TrustLists that were assigned in a previous onboarding process.

The new state allows the TOFU onboarding process to start again. Note the initial state is not the same as a factory reset which typically deletes all software installed on the Device. The reset mechanism should require proof of physical possession of the Device to ensure it cannot be exploited remotely.

The TOFU model exposes the Device to malicious actors that are running on the network. This means the network used for configuration has to be protected to make it harder for a malicious actor to gain access to the network. OwnerOperators should also have network services designed to detect and eliminate malicious applications that attempt to interfere with the onboarding process.

Devices may have other ways to assign the credentials provided by the onboarding process in order to avoid the risks associated with TOFU.

The SoftwareUpdateManager is a system component that provides updates to firmware or software running on a Device. The SoftwareUpdateManager may implement the standard model defined in OPC 10000-100, however, it often will be specific to the Manufacturer. This document defines APIs that allow any SoftwareUpdateManager to coordinate with the components defined in this document.

The SoftwareUpdateManager is an important part of the onboarding process because it is necessary to ensure that Devices with out-of-date firmware are not allowed on the network. The interactions between the SoftwareUpdateManager and the other components are described in clause 7. The SoftwareUpdateManager may not be present in systems where the OwnerOperator has other mechanisms in place to ensure the Devices have up to date firmware.

Registrars and DCA Servers need to restrict access to many of the features they provide. These restrictions are described either by referring to well-known Roles which a Session must have access to or by referring to named Privileges which are assigned to Sessions using mechanisms other than the well-known Roles. Privileges are needed because not all restrictions can be expressed simply by granting Role permissions on Nodes. For example, authenticated Devices are granted the ability to update only their own information which means the decision on granting access can depend on the values of the arguments passed to a Method call rather than the permissions on the Method Node. The well-known Roles used in this document are listed in Table 3.

Table 3 – Well-known Roles for Onboarding

Name	Description
RegistrarAdmin	The Role grants rights to manage the Tickets known the Registrar and approve Devices when automatic authentication was not possible.
SoftwareUpdateAdmin	The Role grants rights to set the software status for a Device.
SecurityAdmin	The Role grants the right to changes the security configuration of a Registrar or a DCA Server. For the DCA Server this includes the right to set the location of the Registrar or to force the Server to restart the authentication process.

The Privileges used in this document are listed in Table 4.

Table 4 – Privileges for Onboarding

Name	Description
DeviceSelfAdmin	The Device has rights to modify its own registration.
DCA	The Client is a DCA that has rights to request Certificates and TrustLists for Applications that it has been granted rights to.

For a detailed description of Roles, see OPC 10000-3.

Distribution is the process of transferring physical control of Devices and Composites from one organization to another. This transfer of physical control is accompanied by the electronic transfer of Tickets as described in 6.2.

Onboarding is the process where a Device or Composite is connected to the network managed by an organization. When this happens the authenticity of the Device is verified via interactions with a Registrar running on the network.

Every Device has a Device Configuration Application (DCA) which interacts with the Registrar using the interactions described in PullManagement (7.2) or PushManagement (7.3). These interactions are secured with a DeviceIdentity Certificate.

After authentication completes, the DCA is issued a Certificate by the Registrar that allows the DCA to configure other Applications running on the Device. The Registrar is responsible for determining if a DCA is authorized to request Certificates on behalf a specific Application. For example, the DCA rights may be limited to Applications with the same hostname as the DCA.

During Onboarding, the Device may need to have software updated before the process can complete. The DCA uses the software update model described in OPC 10000-100 to manage the software update process.

Application Setup is the process of issuing an Application Instance Certificate and a TrustList to one or more Applications running on a Device that will allow the Applications to communicate with other OPC UA Applications running on the network. These mechanisms are provided by the CertificateManager Information Model and are described in OPC 10000-12.

During the Onboarding step, the DCA is issued a Certificate that allows it to request or accept Certificates on behalf of any Application running on the Device. If the DCA is a Client it can connect to CertificateManager and request the additional Certificates and TrustLists without the need for additional approvals. If the DCA is a Server the CertificateManager can locate Applications within the DCA AddressSpace and provide Certificates and TrustLists to them.

Some Applications on a Device could have access rights that prevent the Integrator or OwnerOperator from changing the setup for the Application. This could occur if Applications are used for maintenance or protect intellectual property.

Configuration occurs when the Applications running on the Device are installed, modified, backed up or restored. Configuration is also the mode that allows a new Device to be dropped in as a replacement for an existing Device that is no longer functioning.

Some Devices may allow individual Applications to be configured while other Applications continue in Operation state described in 4.3.5.

Operation occurs when one or more Applications on a Device are running normally performing whatever task it was deployed to do. In this stage it is possible to update the TrustList and/or renew the Application Instance Certificate using the CertificateManager PushManagement or PullManagement described in OPC 10000-12. Some Devices may allow the Application configuration to be changed while in this stage.

Decommissioning is the final state for the Device where it is reset to an initial state to ensure that all sensitive data is deleted. Any permissions granted to the Device on the OwnerOperator network are revoked.

The DeviceIdentity Certificates and their associated PrivateKeys are not affected by a reset.

A Device that was Decommissioned by mistake can be Onboarded again as described in 4.3.2.

In some cases, the OwnerOperator may wish to prevent the Device from being used again by removing/destroying the SecureElement or some other method to physically disable the Device.