Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Historian

Manage security

  • Last UpdatedFeb 04, 2026
  • 2 minute read

Starting from the 2023 R2 release, Historian is secure by default. This means that any client connecting to Historian for data storage or retrieval must be trusted by the server. There are several methods to establish a trust relationship between the client and server.

The preferred method involves using the AVEVA SMS system management server. When all nodes are configured with SMS, proper trust is established among all nodes under the same SMS. Historian can join SMS, and any client node can also join SMS, ensuring that all nodes share the same certificate and trust is automatically established.

If configuring SMS is not desired, an alternative method is to use a common root certificate installed across all systems. In this scenario, Historian will have the root certificate, which can be used to configure Historian. Each client will also have the same certificate, thereby establishing trust automatically.

Another option, if neither certificates nor SMS are used, is for Historian to create its own self-signed certificate during configuration. This self-signed certificate is bound to the Historian processes. Users can then take this certificate and install it on all nodes attempting to connect to Historian. Trust will be established between nodes because they share the same certificate.

If none of these certificates are present, communication will fail, resulting in a secure exception due to the lack of established trust. While there is an option to bypass this by choosing an untrusted connection in some cases, it is mandatory for clients unless they are developed using SDKs that allow bypassing the trust requirement. Applications such as data replay or OMI must have a trust relationship; otherwise, they cannot communicate.

The AVEVA Historian uses two security mechanisms:

  • Windows operating system security

  • Microsoft SQL Server security

    Important: SQL Server authentication is provided for backward compatibility only. For improved security, we recommend that you use Windows authentication.

    Note: During configuration, if you are upgrading from an earlier release, Historian requires that you change the passwords for any legacy default SQL logins, such as wwUser. When this is required, it is clearly indicated during configuration of security options.
    Setting SQL logins