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.