TL;DR — OPC UA Part 21: Device Onboarding

Full spec: reference.opcfoundation.org/Onboarding/v105/docs

What Is It?

OPC UA Part 21 defines a secure, automated process to authenticate new industrial devices on a network and provision them with the certificates and trust lists they need to communicate. Think of it as "zero-touch provisioning" for OPC UA devices — from factory floor to production network.

The spec covers the entire device lifecycle: manufacture → distribution → onboarding → operation → decommissioning.

The Problem It Solves

Industrial devices (PLCs, sensors, gateways) are shipped with pre-installed software and connected directly to sensitive networks. Unlike PCs, they can't be manually configured one-by-one at scale. You need:

1. Proof the device is genuine (not counterfeit)
2. Automated certificate provisioning (no manual cert installs)
3. Software update enforcement before network access
4. Supply chain traceability across manufacturers, distributors, integrators

Key Concepts at a Glance

Device Lifecycle

flowchart LR
    M[🏭 Manufacture] --> D[📦 Distribution]
    D --> O[🔌 Onboarding]
    O --> AS[🔧 App Setup]
    AS --> C[⚙️ Configuration]
    C --> OP[✅ Operation]
    OP --> C
    OP --> DC[🗑️ Decommission]
    DC -.->|re-onboard| O

"Commissioning" = Onboarding + Application Setup + Configuration

Actors

Three Core Mechanisms

How Onboarding Works

Step-by-Step Overview

sequenceDiagram
    participant Mfr as 🏭 Manufacturer
    participant Admin as 👤 RegistrarAdmin
    participant Reg as 🖥️ Registrar
    participant DCA as 📱 Device (DCA)
    participant SUM as 🔄 SW Update Mgr
    participant CM as 🔐 Certificate Mgr

    Note over Mfr: Creates device with IDevID<br/>certificate + signed Ticket
    Mfr->>Admin: Delivers Ticket (out-of-band)
    Admin->>Reg: RegisterTickets()

    Note over DCA: Device connected to network
    DCA->>Reg: ProvideIdentities(DeviceIdentity certs)
    Reg->>Reg: Match cert → Ticket → Validate
    Reg-->>DCA: selectedIdentity + applicationId

    DCA->>Reg: Reconnect with selected DeviceIdentity cert
    Note over Reg: Proof of private key possession

    alt Software Update Required
        Reg-->>DCA: SoftwareUpdateManager endpoint
        DCA->>SUM: Connect, report version
        SUM->>DCA: Upload new firmware
        SUM->>Reg: UpdateSoftwareStatus(OK)
    end

    DCA->>Reg: GetManagers()
    Reg-->>DCA: CertificateManager endpoint

    DCA->>CM: StartSigningRequest (CSR)
    CM-->>DCA: DCA Certificate + TrustList
    Note over DCA: Now trusted on network!

    DCA->>Reg: RegisterManagedApplication()
    DCA->>CM: Request certs for each Application
    CM-->>DCA: App Instance Certificates + TrustLists

Pull vs Push Management

Tickets — The Supply Chain Glue

Tickets are digitally signed JSON-like documents that travel with a device through the supply chain:

flowchart LR
    M[🏭 Manufacturer<br/>Signs Ticket] -->|ships device + ticket| D[📦 Distributor<br/>May re-sign]
    D -->|ships device + ticket| I[🔧 Integrator<br/>May re-sign]
    I -->|uploads ticket| R[🖥️ Registrar<br/>Validates & matches]

Key properties:

• Contain the ProductInstanceUri (globally unique device ID, often a QR code too)
• Signed by the Manufacturer's certificate (from a well-known CA)
• Can have multiple signatures added by supply chain actors
• The Registrar only needs one trusted signature to validate
• For Composites: a CompositeIdentityTicket references child DeviceIdentityTickets

Trust on First Use (TOFU)

When first connected, a device has no TrustList and will accept any Registrar it finds. This is the TOFU model:

1. DCA connects to the first available Registrar
2. Once it receives a DCA Certificate + TrustList, it locks down and only trusts that Registrar
3. Physical reset required to re-enter TOFU state

⚠️ Security implication: The network used for onboarding must be protected against rogue Registrars.

Information Model Summary

Registrar Server (DeviceRegistrarType)

DeviceRegistrar
├── ProvideIdentities()      ← DCA sends its DeviceIdentity certs
├── UpdateSoftwareStatus()   ← SoftwareUpdateManager reports status
├── RegisterDeviceEndpoint() ← Admin registers device for PushMgmt
├── GetManagers()            ← Returns CertMgr & SWUpdateMgr endpoints
├── RegisterManagedApplication() ← DCA registers apps it manages
└── Administration (DeviceRegistrarAdminType)
    ├── RegisterTickets()     ← Upload Tickets for expected devices
    ├── UnregisterTickets()   ← Remove Tickets
    ├── TicketAuthorities     ← TrustList for Ticket signing CAs
    └── DeviceIdentityAuthorities ← TrustList for DeviceIdentity CAs

Device Server (ProvisionableDeviceType)

ProvisionableDevice
├── IsSingleton              ← true if DCA = the only app
├── RequestTickets()         ← Registrar reads device Tickets
├── SetRegistrarEndpoints()  ← Admin tells device where Registrar is
└── <ApplicationName>        ← ApplicationConfigurationType instances

Key Takeaways

1. Registrar is the gatekeeper — no device gets on the network without matching a valid Ticket
2. Tickets bridge the supply chain — digitally signed docs that travel with devices from factory to site
3. DeviceIdentity Certificates (IDevID/LDevID) prove hardware origin, stored in secure elements
4. DCA is the on-device agent — handles all onboarding communication with the Registrar
5. Software updates are mandatory — the SoftwareUpdateManager can block network access until firmware is current
6. TOFU is the default — first Registrar wins, so protect your onboarding network
7. Part 21 extends Part 12 (GDS) — the CertificateManager from GDS issues the actual operational certificates
8. Composites (machines) are first-class citizens with their own identity and nested Tickets
9. Pull (Client) or Push (Server) — two models depending on device capabilities
10. Decommissioning resets to factory state but preserves DeviceIdentity (can re-onboard)

How GDS (Part 12) and Device Onboarding (Part 21) Are Linked

Part 21 does not replace Part 12 — it extends it. The GDS CertificateManager (Part 12) remains the authority that issues Application Instance Certificates, manages TrustLists, and handles certificate lifecycle (renewal, revocation). What Part 21 adds is the authentication layer that happens before a device is allowed to talk to the CertificateManager at all.

In practice, the Registrar (Part 21) acts as a gatekeeper in front of the CertificateManager (Part 12). The flow is:

1. Registrar authenticates the device — matches its DeviceIdentity Certificate against a Ticket, verifies origin
2. Registrar registers the device with the CertificateManager on its behalf (the DCA never calls RegisterApplication directly)
3. Registrar issues a DCA Certificate — a short-lived cert that grants the DCA permission to request operational certificates
4. DCA contacts the CertificateManager (Part 12) using the DCA Certificate to get Application Instance Certificates and TrustLists via the standard GDS Pull/Push workflows

The Registrar and CertificateManager are expected to share a common backend — applications and certificates created via the Registrar are visible to the CertificateManager. In many deployments, they run as the same server. The GetManagers() method on the Registrar returns the CertificateManager endpoint so the DCA knows where to go.

In short: Part 21 answers "is this device allowed on my network?", Part 12 answers "here are the certificates and trust lists it needs to communicate".

Relationship to Other Parts

flowchart TB
    P12[Part 12 - GDS<br/>CertificateManager<br/>TrustLists, Certs]
    P21[Part 21 - Onboarding<br/>Registrar, Tickets<br/>Device Authentication]
    P100[Part 100 - DI<br/>SoftwareUpdateManager]
    P4[Part 4 - Services<br/>Discovery, SecureChannel]

    P21 -->|uses CertificateManager| P12
    P21 -->|uses SoftwareUpdate model| P100
    P21 -->|uses Discovery & Security| P4
    P12 -->|uses Services| P4

Roles & Privileges