Part 21: Device Onboarding
| Document number | OPC 10000-21 |
|---|---|
| IEC designation | IEC 62541-21 |
| Colloquially | Part 21 |
| Group | Utility |
Part 21 defines how a device gets from factory state into a plant's trust domain without anyone hand-installing certificates. The device authenticates with a manufacturer-provisioned identity, a registrar in the plant checks it against an authorisation record, and the device receives operational credentials.
The problem it solves
Certificate management is the most expensive part of a secure OPC UA deployment, and most of the cost is the first step: a device out of its box has no plant identity, so somebody has to generate a certificate, get it into the device, and get the device's certificate into every peer's trust list. Multiply that by a few hundred devices and security becomes the reason a project slips. Part 21 defines a machine-to-machine path through that first step.
Two identities, in sequence
The mechanism rests on a device having two identities over its life. The first is provisioned by the manufacturer during production - an initial device identifier in the sense of the IEEE 802.1AR scheme, held in hardware where possible, that proves this is genuinely that manufacturer's device with that serial number. The plant trusts the manufacturer's certificate authority, so it can verify that claim without any prior relationship with the individual unit. The device then obtains a locally significant operational identity, which is the application instance certificate it uses for normal OPC UA work from then on.
The registrar and the authorisation record
A registrar in the plant is the counterpart. It accepts a device presenting its manufacturer identity, checks that this device is expected - typically against a record loaded from a purchase or commissioning list, so an unexpected device on the network is not silently enrolled - and then arranges for operational credentials and the plant trust list to be delivered. Manufacturer trust plus an authorisation record is what makes the process both automatic and controlled; either one alone would not be.
Where it hands over
Onboarding is a one-time transition, not a lifecycle. Once the device holds an operational certificate, everything afterwards - renewal before expiry, trust-list updates, revocation, and rotation after a key compromise - is the Global Discovery Server machinery in Part 12, in either its pull or push form. Part 21 is best understood as the missing first step that makes the Part 12 model usable at fleet scale rather than as a replacement for it.
What it defines
| Concept | What it is |
|---|---|
| Manufacturer-provisioned identity | The device's birth certificate, installed in production and ideally held in hardware. An initial device identifier in the IEEE 802.1AR sense, proving make and serial number. |
| Operational identity | The locally significant certificate the device receives during onboarding and uses as its OPC UA application instance certificate thereafter. |
| Registrar | The plant-side service that authenticates a new device against its manufacturer identity and drives the issuing of operational credentials. |
| Authorisation record | The plant's statement that this specific device is expected, so an unknown unit plugged into the network is not enrolled automatically. Usually derived from a purchase or commissioning list. |
| Manufacturer trust anchor | The plant's decision to trust a manufacturer's certificate authority. This is a supply-chain and procurement decision, and it is what makes zero-touch possible. |
| Trust-list delivery | Onboarding delivers the plant's trust list as well as the device's own certificate, so the new device can validate its peers rather than only be validated. |
| Handover to the GDS | Renewal, revocation and rotation are Part 12 responsibilities. Part 21 gets the device into the system; the GDS keeps it there. |
| Onboarding information model | The published nodeset representing the onboarding objects in an address space, at Opc.Ua.Onboarding version 1.05.04, so onboarding is driven over OPC UA itself. |
Do you need to read it?
Architects and security owners planning a deployment with more devices than an engineer can visit, and anyone writing a procurement requirement for new equipment. The device capability has to be specified at purchase - a device that ships without a manufacturer-provisioned identity can never be onboarded this way, and that is not something firmware adds later.
Traps that trace back to this part
- Zero-touch onboarding is a supply-chain arrangement before it is a network one. It requires devices that ship with a manufacturer identity and a plant that has decided to trust that manufacturer's certificate authority. Neither can be retrofitted at commissioning, so both belong in the purchase specification.
- Adoption is early. Most equipment on a plant floor today still needs a certificate installed by hand or through a vendor tool, so a design that assumes onboarding has to be checked device by device against the actual model and firmware rather than against the standard.
- Onboarding does not manage the certificate afterwards. A fleet that is onboarded and then left alone will hit its first expiry wall together, two or three years later. Plan the Part 12 renewal path at the same time as the onboarding path, not after it.
Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.