With the TOFU, all that is needed for secure onboarding is preloading a list of known DevIDs into the registrar that could be sent via any mechanism. 

You also need to think about the risk profile: what exactly can be done with a device that configured by a rogue registrar? It won't have certificate that would allow it to talk to anything else. It would not have configuration information. Since the factory owner has physically possession a h/w reset can fix the problem while they hunt down the rogue.

However, while continuous monitoring and honeypots are useful detective measures, they cannot guarantee that a DCA will never be provisioned with malicious credentials and TrustLists. Furthermore, these are compensating security controls that place an additional burden on the Owner Operator and its infrastructure. Some factory environments may be well-equipped to handle these operational costs, while others may not be, or may simply require stronger security guarantees.

OPC-10000-21 Section 4.2.4 states: "Devices may have other ways to assign the credentials provided by the onboarding process in order to avoid the risks associated with TOFU."

The way I understand this, it effectively puts the responsibility on the Owner Operator to implement an alternative, mutually authenticated onboarding procedure if TOFU does not satisfy the security requirements of a particular factory environment.

My question is: Wouldn't it make sense for OPC UA to standardize an alternative onboarding mechanism that also authenticates the Registrar? Not to replace the existing TOFU mechanism, but to provide a standardized alternative for environments requiring stronger security guarantees.

After all, placing the responsibility on individual Owner Operators to develop their own solutions for mutually authenticated onboarding could lead to inconsistent implementations and potentially introduce additional security vulnerabilities.

IOW - TOFU is not "good enough". It is a complete solution that addresses the needs of factory operators which are distinctly different from the needs of telcom network providers which were the primary use case for BRSKI.

Factory operators have plenty of remedies to protect against the possibility of a rogue registrar running on their networks including continuous monitoring and honeypot devices.

https://github.com/OPCFoundati.....oModel.xml

<opc:ObjectType SymbolicName="PictureType" BaseType="ua:BaseObjectType">
  <opc:Children>
    <opc:Property SymbolicName="YellowThing" TypeDefinition="YellowType" ModellingRule="Mandatory" AccessLevel="ReadWrite" />
    <opc:Object SymbolicName="Indigo_Placeholder" TypeDefinition="BrightnessType"  ModellingRule="MandatoryPlaceholder">
      <opc:BrowseName>&lt;Indigo&gt;</opc:BrowseName>
      <opc:ReferenceType>ua:HasComponent</opc:ReferenceType>
    </opc:Object>
  </opc:Children>
</opc:ObjectType>

Rebuilt and ran the DemoModel Test Server:
https://github.com/OPCFoundati...../DemoModel

The AccessLevel on the PictureType->YellowThing node was set correctly.

What will not happen is the YellowThing AccessLevel is not set if you create an instance of PictureType because setting that value correctly requires additional code to be added to the Server. 

I'm the developer of OpenUaExplorer, a free and open-source OPC UA desktop client for Windows, Linux, and macOS.

The project is built with Qt and is intended as a practical tool for browsing, inspecting, and troubleshooting OPC UA servers.

It currently supports address space browsing, reading node values, subscriptions, historical data, trends, server discovery, security configuration, and certificate management.

I'm sharing the project here because I'd appreciate technical feedback from the OPC UA community, particularly regarding interoperability with different server implementations.

I'm especially interested in:

• Compatibility with OPC UA servers from different vendors
• Issues related to endpoint discovery, security policies, and certificates
• Subscription and historical data behavior
• Missing functionality useful for OPC UA diagnostics

The source code and releases are available on GitHub:

https://github.com/sanny32/Ope.....UaExplorer

The project is open source under the MIT license.

Any feedback, bug reports, or interoperability test results would be greatly appreciated.

Thank you!

2) The provisioning process should already make it clear that the DCA and other applications running on the Device are assigned ApplicationInstance Certificates and TrustLists. This process can ensure the applications can connect to the SKS.

I am reading OPC-10000-14 PubSub V1.05.06.

Section "5.4.5.3 Key acquisition handshakes" states:

"The Publisher or Subscriber use keys provided by a Security Key Service (SKS) to secure messages exchanged via the Message Oriented Middleware. [...] To pull keys, the Publisher or Subscriber creates an encrypted connection and provides credentials that allow it access to the SecurityGroup."

Pushing the keys via the SetSecurityKeys Method also talks about the establishment of this encrypted connection between SKS and key-target.

My Question: are there any details on how exactly this encrypted connection is to be established? Is this like the default OPC UA secure channel between Client and Server that is mutually authenticated with Application Instance Certificates? Meaning, prior to using PubSub, any Publisher/Subscriber needs to connect with an SKS via Client/Server secure channel to get the keys for subsequent PubSub use? If this is so, then would the onboarding procedure described in OPC-10000-21 to provision new applications with Application Instance Certificates also apply to devices wishing to use the PubSub architecture? Do Publishers and Subscribers need an Application Instance Certificate? Or does PubSub specify a different onboarding procedure to establish the initial trust anchor for new devices?

I'd appreciate any clarification 🙂

Thanks for the answer!

I am examining the node for EXOAnalogInputType in PredefinedNodes in my NodeManager (which derives from CustomNodeManager2). I drill down to the child node representing the Unit property, and its AccessLevel is set to 1 (CurrentRead) rather than the expected 3 (CurrentReadOrWrite) according to the model design file in the post above.

I can't find any trace of this value in the address space, neither in the corresponding type nor in instances created from that type.

Why is AccessLevel a valid property in a ModelDesign file if its value is ultimately ignored?

The project is public and MIT so anyone who has the job maintaining old systems can share fixes and the OPC-F will review them and provide updated signed installers if they are deemed necessary.

This should be sufficient to support the community as long as needed.

In Pull Management (Section 7.2), the DCA calls

on the Registrar to register managed Applications and obtain their ApplicationIds. The Registrar decides whether the DCA has the authorization to manage these Applications.

In Push Management, Section 7.3 describes that the CertificateManager can discover Applications through

objects exposed in the DCA's AddressSpace and push Certificates and TrustLists for those Applications.

My question is: How does the CertificateManager in Pull management know which Applications the DCA is actually authorized to manage?

I'd appreciate any clarification.