OT Process Historian Security Guide

The process historian is the one OT system that almost everyone in the business wants to reach, which makes it the most connected server in the plant and one of the most attractive pivots between the corporate network and control systems. Historians run service accounts with read access deep into Level 2, accept connections from Level 4 users and feed reporting, cloud analytics and AI models. This guide is vendor-neutral and applies to any commercial or open source process historian: it covers how identity and access work, privileged administration, the service accounts and API tokens that integrations depend on, logging, a hardening baseline and the misconfigurations that recur. It is written for OT security engineers, control system and historian administrators, and security architects who already know the basics in the OT Security Guide.

Key takeaways

Treat the historian as a boundary system, not a data store. It reads from control networks and serves business users, so its accounts, interfaces and replication paths decide whether an IT compromise can reach OT.
Split the historian in two across the DMZ. Keep a site historian at Level 3, replicate outward to a DMZ copy over a one-way or outbound-only path, and let business users and IT systems query only the DMZ copy, as the NCSC secure connectivity principles describe.
Collector and interface service accounts are the crown jewels. They hold read (and sometimes write) access to OPC servers, controllers and SCADA databases; give each one its own identity, deny interactive logon and never reuse them across sites.
Retire legacy trust and shared logins. Host or IP based trust rules, shared administrator identities and default accounts are the most common ways attackers and over-privileged users get historian write access.
Integrity matters as much as availability. Historian data feeds operating decisions, regulatory reports and models; detect edits, deletions, backfills and tag configuration changes, and protect backups as you would any other OT recovery asset.

Where the historian sits and why it is targeted

Most plants run a layered historian design. A site or unit historian sits at Level 3 (site operations) and receives data from interface or collector nodes at Level 2 that poll OPC DA or OPC UA servers, SCADA databases, DCS gateways or controllers directly over Modbus, EtherNet/IP and similar protocols. An enterprise historian, or a replica, then serves engineers, laboratory and quality systems, reporting, MES and cloud analytics. The OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide covers the reference model; this section covers what it means for the historian.

The NCSC secure connectivity principles for OT (principle 4) set out the target pattern: industrial control protocols stay inside isolated OT segments, OT to IT exchange is brokered through a DMZ using secure protocols such as OPC UA over TLS, MQTT over TLS or HTTPS, the OT historian is replicated to a historian in the DMZ through a unidirectional transfer so there is no inbound connection from IT into OT, and IT systems query the DMZ historian through an authenticated HTTP based API rather than connecting to OT systems.

Component	Typical location	What an attacker gains	Primary control
Interface or collector node	Level 2 or 3, beside OPC or SCADA servers	Valid credentials and network paths to control servers and controllers	Dedicated service identity, read-only source permissions, host hardening, allowlisted outbound to the historian only
Site historian	Level 3	Process knowledge, tag maps, a trusted host inside OT	No direct access from Level 4; administration through a Level 3 jump host with MFA
DMZ historian replica	Level 3.5 (industrial DMZ)	Business-facing service with a replication link back into OT	One-way or outbound-only replication; read-only for business users
Web API and query services	DMZ or enterprise	Bulk data extraction, token theft, a route for injection into analytics	Strong authentication, scoped tokens, TLS, rate limits, logging
Cloud or analytics connector	DMZ, pushing outbound	Long-lived cloud credentials and a path from the internet	Outbound only, credentials in a vault, separate identity per connector
Engineering and client tools	Level 3 and Level 4 workstations	Cached credentials, write access to tags and data	Role based access, read-only by default, client version control

In MITRE ATT&CK for ICS, the historian is a target of T0811 Data from Information Repositories (adversaries mine historians for process knowledge before an attack) and a pivot for T0886 Remote Services and T0859 Valid Accounts.

How identity and access work in a process historian

Historians use a mix of authentication models, often all at once because of upgrades layered over many years. Know which ones are enabled on each server.

Model	How it works	Risk	Target state
Directory integrated (Windows or Kerberos)	Users and services authenticate with domain accounts; directory groups map to historian roles or identities	Inherits the security of the directory it trusts; an IT domain trust can expose OT	Use an OT domain or forest, map groups to roles, no direct mapping of enterprise admin groups
Local historian accounts	Username and password stored in the historian	Shared logins, weak rotation, no MFA, poor attribution	Disable or restrict to break-glass, vaulted and monitored
Host or IP based trust rules	Connections from a named host or address are granted an identity without user credentials	Anyone on that host or able to spoof the address inherits the access	Remove; replace with service accounts on directory authentication
Application or API tokens	Bearer tokens, API keys or client certificates for web and REST access	Long-lived tokens in scripts, spreadsheets and integration configs	Scoped, short-lived tokens or certificates issued per integration, stored in a vault
Anonymous or guest read	Unauthenticated read access for convenience	Bulk process data extraction with no attribution	Disabled

Authorisation is normally layered: server level rights (administer, configure, connect), object level rights on tags or points (read data, write data, read and write configuration), and rights on archives, analyses and event frames or batches. Build a small set of roles and map directory groups to them rather than granting rights to individuals:

Viewer: read data on approved tag sets only. The default for business users, and the only role exposed on the DMZ replica.
Engineer: read data and read configuration; write to calculated or manual entry tags in a defined scope.
Tag or interface administrator: create and change tags, interfaces and point sources; no server security rights.
Historian administrator: server configuration, archives and security; privileged and tightly held.
Service roles: one per collector, replication link, analytics engine and integration, each with the narrowest rights the function needs.

Where the historian trusts a directory, the identity design of that directory matters as much as the historian. See the OT and ICS Identity and Access Guide.

Admin roles and privileged access

Separate historian administration from Windows administration: the people who manage tags and archives do not need local administrator on the server, and server administrators do not need historian security rights for day-to-day work.
Remove built-in superuser use: most historians ship with a built-in administrative identity. Do not map people or services to it; keep it for break-glass, vault its credentials and alert on every use.
Administer from inside OT: run admin consoles from a hardened Level 3 jump host reached through your OT remote access path with phishing-resistant MFA, as recommended in the NCSC principle 5 guidance and the CISA, FBI, EPA and DOE primary mitigations for OT. See the OT Remote Access Guide.
Make vendor and integrator access user-aware: named accounts, time-bound approval and session recording for third parties who maintain interfaces. See the OT Third-Party and Integrator Access Guide.
Treat write rights as privileged: rights to edit, delete or backfill archived values, and to change tag configuration, change the plant record. Grant them through change control, not standing membership.
Tie access to joiners, movers and leavers: historian roles often outlive projects and contracts. Review them at least quarterly and on every role change.

Integrations, API tokens and service accounts

A mature historian may have dozens of machine identities: collectors, replication links, analytics engines, reporting connectors, MES and laboratory integrations, and cloud connectors. Each is a non-human identity that needs an owner and a lifecycle. See the Service Account Security Guide.

Integration	Identity pattern	Rights it should have	Rights it should not have
Collector or interface	Dedicated service account or managed service identity per node and source	Read on the source; write data to its own point source only	Interactive logon, admin rights on the historian, write to controllers unless explicitly engineered
Site to DMZ replication	Dedicated identity or one-way transfer with no return credentials	Push data outward	Any inbound session from the DMZ to the site historian
Web API or REST service	Service identity; delegated user authentication for callers	Read on approved tag sets per client	Server configuration, security rights
BI, reporting and spreadsheet tools	Per-application identity or the end user's own identity	Read on approved datasets	Write data, shared credentials embedded in workbooks
Cloud and AI analytics connector	Outbound-only connector with a workload identity or vaulted credential	Read on a defined export scope	Inbound listeners, standing write access

One identity per function and site: a shared "historian service" account across all collectors means one stolen password opens every source.
Deny interactive and remote desktop logon for service accounts through group policy, and alert when one logs on interactively.
Store secrets properly: remove passwords and tokens from interface configuration files, scripts and spreadsheet connections; use a vault or the platform's protected credential store. See the Secrets Management Guide.
Plan rotation around operations: collectors buffer data when disconnected, so rotation can be scheduled in a maintenance window without data loss if buffering is sized and tested first.
Prefer secure protocols to the sources: OPC UA with signing and encryption in place of OPC DA, which depends on DCOM, follows the NCSC principle 4 recommendation; keep a migration roadmap where legacy protocols remain.

Logging and detection

NCSC principle 7 calls monitoring the last line of defence and recommends threat-led logging, baselining and continuous monitoring of data flows between segments. Historian traffic is highly regular, which makes anomalies easy to spot.

Source	What to log	Detection idea
Historian security and audit log	Logons, failed logons, role and mapping changes, security setting changes, use of built-in admin identities	Any change to mappings or trusts outside a change ticket
Historian configuration audit	Tag and point creation, deletion and edits, interface configuration, archive operations	Bulk tag deletion or creation; new point sources
Data edit audit	Edits, deletions, backfill and manual entries to archived values	Edits to regulated or safety related tags; edits by service accounts
Windows event logs	Logon events by service accounts, new services, scheduled tasks	Interactive logon by a collector account; new remote access tools
Network monitoring	Flows between collectors, site historian, DMZ replica and Level 4	Any inbound session from IT to the site historian; new protocols on historian ports
API gateway or web server	Caller identity, token, query size and rate	Large exports outside normal reporting times; queries for tags a client never uses

Coordinate with planned maintenance: NCSC principle 7 warns that rules muted during maintenance must be re-enabled afterwards, and that business processes should confirm maintenance activity is genuine. See the OT Network Security Monitoring Guide.

Metrics that show it is working:

Percentage of historian service identities that are unique, owned and vaulted.
Number of host or IP based trust rules and local shared logins remaining (target zero outside documented break-glass).
Count of inbound connections from Level 4 to the site historian per month (target zero).
Percentage of data edits and tag configuration changes traced to an approved change record.
Time to detect a use of the built-in administrative identity.
Time since last successful historian restore test.

Hardening baseline

Inventory first: list every historian server, collector, replica, client tool, API, connector and identity, with owners. The OT Asset Visibility Guide covers discovery methods that are safe in OT.
Fix the architecture: stand up or confirm a DMZ replica, move business users to it, and close direct Level 4 access to the site historian. Where risk is high, enforce one-way replication in hardware. See the Data Diodes and Unidirectional Gateways Guide.
Audit authentication: enable the historian's audit logging, then list trust rules, local accounts, anonymous access and role mappings. Run in audit mode for a few weeks to learn which connections each rule really serves before removing it.
Migrate identities in rings: start with one unit or one non-critical collector, replace its trust rule or shared login with a dedicated service account, verify data continuity and buffering, then roll site by site. Keep the old rule disabled, not deleted, for a defined rollback period.
Harden hosts: remove unused services and ports, apply application allowlisting where supported, enforce TLS on client and API connections with certificates from a managed PKI, and patch on the OT cadence in the OT Patch Management Guide.
Restrict network paths: collectors may reach only their sources and the historian; the site historian accepts only collectors, admin jump hosts and the replication link.
Protect recovery: back up archives and configuration offline, test restores, and keep the ability to run without the historian, in line with the CISA, FBI, EPA and DOE advice to practise manual operations. See the OT Backup, Recovery and Golden Image Guide.

Decision guidance

Software firewall rules or hardware one-way transfer: NCSC principle 5 suggests outbound-only connectivity enforced by network policy at its simplest, and hardware controls such as data diodes for high-threat or high-risk environments. Choose hardware where the site is safety critical, regulated as critical infrastructure, or where a configuration error must not be able to re-open an inbound path.
Single historian or site plus DMZ replica: once more than a handful of IT systems or cloud services need data, a DMZ replica is simpler to secure than a growing list of firewall exceptions into Level 3.
Directory integrated or local accounts: directory integration gives attribution and joiner, mover and leaver control, but only if the directory is an OT-scoped one. Joining historians to the enterprise domain trades convenience for exposure to every enterprise compromise.
Small versus large estates: a single site can manage roles by hand with quarterly reviews; multi-site estates need roles defined centrally, identity governance for historian groups and automated detection of new trust rules.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	MITRE ATT&CK for ICS
DMZ replica and one-way paths	SC-7 Boundary Protection	DE.CM-01	T0886 Remote Services, T0866 Exploitation of Remote Services
Service accounts and roles	AC-2 Account Management, AC-6 Least Privilege	PR.AA-05	T0859 Valid Accounts
Credentials in configs and tokens	IA-5 Authenticator Management	PR.AA-05	T0859 Valid Accounts
Audit logging and review	AU-6 Audit Record Review, Analysis, and Reporting, SI-4 System Monitoring	DE.CM-01	T0811 Data from Information Repositories, T0802 Automated Collection
Backups and restore	CP-9 System Backup, CP-10 System Recovery and Reconstitution	PR.DS-11, RC.RP-01	T0882 Theft of Operational Information (data exfiltrated from archives)

In ISA/IEC 62443 terms, the historian, its DMZ replica and the replication link are separate zones joined by a conduit; ANSI/ISA-62443-3-2 covers the risk assessment that sets their target security levels and ISA-62443-3-3 the system security requirements. See the IEC 62443-2-1 Asset Owner Security Programme Guide.

Common misconfigurations

Business users connect straight to the site historian: a firewall rule added for one reporting tool becomes a standing route from Level 4 into Level 3, and the replica is bypassed.
Trust rules nobody can explain: legacy host or IP trusts that grant administrative or write identities to whole subnets. Audit, then replace with service accounts.
Shared collector accounts with domain admin rights: installed years ago "to make it work", with passwords that never change and appear in interface configuration files.
Dormant remote access accounts: vendor or project accounts left enabled without MFA. The Colonial Pipeline ransomware attack began with an unused VPN account without MFA; the operator then shut down the pipeline as a precaution, showing how an IT side compromise can halt operations when IT and OT dependencies are not understood.
Credentials in spreadsheets and BI connections: service passwords or API keys embedded in workbooks that are emailed and copied across the business.
No audit of data edits: archived values can be changed or backfilled without a trace, so integrity of regulatory and quality reports cannot be shown after an incident.

If you suspect the historian or its remote access path is already compromised, follow If your OT remote access and historian is compromised.

Practitioner checklist

Inventory every historian server, collector, replica, API, connector and the identities each uses, with named owners.
Route all business and cloud access through a DMZ replica fed by a one-way or outbound-only path; block inbound Level 4 sessions to the site historian.
Remove host or IP based trust rules, anonymous read and shared local logins; keep any break-glass identity vaulted and alerted.
Give each collector, replication link and integration its own service identity with read-only source rights and no interactive logon.
Move secrets out of interface configs, scripts and workbooks into a vault; rotate on a schedule tested against collector buffering.
Map directory groups from an OT-scoped directory to a small set of historian roles; review membership quarterly.
Enable and forward historian security, configuration and data edit audit logs, plus Windows logon events, to the OT SOC.
Administer only from a Level 3 jump host with phishing-resistant MFA and recorded third-party sessions.
Back up archives offline, test restores and practise operating without historian data.

Standards and references

Related NHI Mgmt Group resources: OT Security Guide · OT and ICS Identity and Access Guide · OT Remote Access Guide · Service Account Security Guide

OT Process Historian Security Guide: Securing Process Historians Between IT and OT