Secrets and Credentials in the OPC Router
This page summarizes where credentials and certificates are stored in the OPC Router, how they are protected, and how this relates to in-house key management. It is intended for IT security and operations teams and consolidates the details from the linked pages to facilitate a risk assessment.
Applies to OPC Router 5.7 and later.
Basic Principle: Secrets Are Separate from Engineering
In the OPC Router, credentials are not fields in the engineering configuration, but rather independent secrets stored in a secret store. The engineering configuration merely references a Key; the value itself is stored elsewhere. This has a practical consequence: The location where a secret is stored is interchangeable—and it can be located entirely outside the product. A project can thus be shared, backed up, and moved between environments without the credentials being transferred along with it.
Storage of Credentials
| Store | Where | Writable by the product |
|---|---|---|
internal | File in the configuration directory—by default on Windows C:\ProgramData\inray\OPC Router 5\config, in the container at /data/config | Yes—created and maintained via Web Management |
env | Environment variables of the service process | No—the source is read-only |
The OPC Router stores values in the internal store in an encrypted form; see Storage and Encryption. However, the level below is crucial for risk assessment: The protective effect of this store stands or falls with the access rights to the configuration directory.
Treat the configuration directory as classified material and restrict access to the service account—it is the line of defense that you yourself control.
Make a connection to your own key management system
If you use a secret manager—such as HashiCorp Vault, Kubernetes Secrets, Docker Secrets, systemd-Credentials, or a cloud vault—then the “env” store is the built-in connection for this purpose: You specify the value as an environment variable for the service process; the OPC Router reads it but never writes it back. This means that rotation, auditing, and access control remain entirely under your control. For information on how environment variables are passed to the container, see Configurable Environment Variables.
If the value of an environment variable changes on the system or in the container, the running OPC Router does not automatically adopt it—only a restart of the services will read the new value; see Stores.
Certificates and Private Keys
You manage certificates for OPC UA communication via the certificate manager: your own certificates, which the OPC Router uses to authenticate itself, and trusted certificates from the peer devices. At the file system level, they are located in the configuration directory, in separate folders for your own key pairs, trusted peer devices, and issuer certificates. Additionally, certificates can be automatically obtained and renewed from a Global Discovery Server via OPC UA GDS (Enterprise license required).
Your own key pairs are software keys stored in the file system and do not have their own password protection. Their security depends on the security of the configuration directory: Anyone who can read it can impersonate this router when communicating with OPC UA peers. Therefore, treat it with the same security measures as you would for credentials themselves, including backups and access logging.
Binding the private key to hardware—such as a TPM, smart card, or key vault—is currently not available for the router’s communication certificates.
Logging In to Web Management
User management in Web Management is completely separate from project secrets and is based on ASP.NET Core’s identity management.
| Mechanism | Implementation |
|---|---|
| Password storage | No password is stored; only a derived value: PBKDF2 with HMAC-SHA512, 210,000 iterations, 128-bit salt per account |
| Account Lockout | Activated after multiple failed login attempts; account is locked for a period of time |
| Two-Factor Authentication | Two-factor authentication is not available for local accounts. The path to achieving this is federation: Your identity provider’s multi-factor authentication policy then applies to all federated logins |
| Federation | Microsoft Entra ID and Windows authentication; see login options |
| Session | Inactivity timeout can be configured centrally; validity period can be overridden per user, see Automatic Logout |
| Authorization | Role-based via user roles |
Federate login to Entra ID. Your password policy, multi-factor authentication requirements, and account lifecycle will then apply, and the router will not store any password-related data for these accounts. Limit local accounts to emergency access only and monitor their use.
Data Sharing: Backup, Export, Redundancy
Secrets can leave the system in three places.
Project Backup and Export
You can specify whether authentication data is included in the automatic project backup using the “Include authentication data in project backup” option in the basic settings. When exporting a project, the OPC Router writes the values of referenced secrets only if you select this option; these values can optionally be encrypted with a password.
Without a password or passphrase, the values appear in plain text in the backup or export file; see Secrets during Export and Import. Assign one as soon as such a file leaves the computer, is shared, or is stored, and treat the file as confidential material thereafter.
Redundancy Check
During synchronization, the primary and secondary systems authenticate each other using a pre-shared key, which, like any other secret, is stored in the internalstore—subject to the same rules for modification, deletion, export, and versioning. For details, see Secure Redundancy.
Recommended Operational Measures
In order of effectiveness. The first measure has the greatest impact: it removes the mystery from the product.
- Import credentials from your own secret manager—via the
envstore instead of theinternalstore. Rotation, auditing, and access control remain entirely under your management. - Harden the configuration directory – Restrict access to the service account and administration at the file and volume levels. Classify it as confidential material, including in the backup strategy.
- Protect the certificate directory like credentials – it contains the system’s private identity and has no password protection of its own. Restrict access to the service account, log read events, and include the contents in the certificate rotation schedule.
- Login via Entra ID – to ensure your password and multi-factor authentication policies are enforced. Limit local accounts to emergency access only.
- Create backups and exports only with a password or passphrase—and then treat the files with the same security classification as the secrets themselves.
- Do not set the log level to "Debug" during operation—diagnostic levels generate detailed logs. Treat log and diagnostic files as potentially containing secrets and restrict access to them; see Log Files and the Event Log.