Device Onboarding - Hardware protected DeviceIdentity Certificates|OPC UA Standard|Forum|OPC Foundation

Forum Scope


Forum Options

Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
Device Onboarding - Hardware protected DeviceIdentity Certificates
Björn Leander
New Member
Forum Posts: 1
Member Since:
sp_UserOfflineSmall Offline
02/22/2024 - 08:30
sp_Permalink sp_Print


We're looking into the OPC UA 10000-21 part for device onboarding and are discussing how to understand some of the writings on the usage of DeviceIdentity certificates (IDevID or LDevID).

It seems quite clear that the expectation is that the DeviceIdentity certificate will be used as an application instance certificate for the DCA during the initial provisioning phase, i.e., before the registrar push new site-specific app.instance certificates to the DCA and the applications it can configure. From 7.3 Push Management:

"Each of the DeviceIdentity Certificates is returned in EndpointDescriptions returned by GetEndpoints." .. "If the Registrar finds an EndpointDescription that matches a valid Ticket it will create a new SecureChannel using that EndpointDescription."

It is also quite clear that the DeviceIdentity cert shall be hardware protected, e.g., using a TPM to store the private key of the DeviceIdentity certificate. From 5.1 Device Identity:

"... Devices should provide a SecureElement storage (for an example, see ISO/IEC 11889) to ensure the associated Private Keys cannot be copied off the Device."

All fine and dandy, but:

  • This will put some specific requirements on the clients expectations on the certificate on first use, as the DeviceIdentity cert will not be an app.instance certificate, e.g., no DNSname or IPAddress to validate. No big issue maybe - the Registrar is a specific application which could be coded to handle this.
  • It will require the DCA to be able to create secure channels using a certificate w. private key stored in TPM (or similar secure element storage). This is a bigger issue, as we have so far not found any of the available stacks supporting app.instance certificates w. key stored in secure storage. 

Are we understanding the specification right?

Anyone knows of support for part 21 in upcoming stack releases?




Randy Armstrong
Forum Posts: 1445
Member Since:
sp_UserOfflineSmall Offline
02/23/2024 - 04:36
sp_Permalink sp_Print

1) The IDevID should be used for bootstrapping only. For operation devices need to issued certificates for the system by the GDS/CertificateManager.

2) Few stacks support this secure element capability at this time but some do allow users to replace the certificate operations with their own code that could use a TPM.

3) There is a JWG which is focused on defining a standard API to secure elements that can be used by OPC UA applications:

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 14
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1347
Posts: 4567