NHIs in OT: Controller, Historian and Service Credentials

In most plants the credentials that can change a running process belong to machines, not people: PLC access passwords, historian collector accounts, OPC UA application certificates and the service accounts behind engineering and backup tools. They are rarely inventoried, often shared across sites, seldom rotated because a failed change stops production, and they sit outside the human access controls that OT identity programmes concentrate on. This guide covers machine identities in OT only: what they are, how to find them, how to strengthen each type without risking availability, and how to measure progress. Human, vendor and remote access are covered in the OT and ICS Identity and Access Guide and the directory architecture in the Identity for OT Environments Guide. It is written for OT security engineers, control system owners and the identity teams asked to bring OT into NHI governance.

Source note: protocol and advisory details below are summarised from the OPC Foundation, ODVA, Modbus Organization, CISA, NIST and Microsoft sources listed in the references, as checked in November 2026. Recommendations are NHI Mgmt Group practitioner guidance. Confirm against the official text before relying on it.

Key takeaways

Inventory from the engineering side first. Project files, controller protection settings, historian connection lists and OPC UA trust lists reveal more machine credentials than any IT scan.
Every device-level password is an identity. CISA's Unitronics advisory lists separate passwords for TCP/IP access, project upload, INFO mode and SD cards; each needs an owner and a value that is not the default.
Prefer protocol-native machine identity where it exists. OPC UA application instance certificates, CIP Security and the Modbus Security protocol on port 802 replace shared secrets with X.509 certificates.
Change only what has been tested against its consumer. A rotated historian password that the collector cannot pick up stops data flow; rotate in maintenance windows after a verified dependency map.
Where you cannot change a credential, contain it. Hard-coded and unchangeable credentials become recorded risks with segmentation, conduit filtering and monitoring for their use.

The machine identities in an OT environment

IEC 62443-3-3 places identification and authentication of software processes and devices, not only people, inside its first foundational requirement. In practice that means the following population, most of which lives at Purdue Levels 1 to 3 and in the IT/OT DMZ.

Identity	Examples	Credential form	Typical weakness
Controller access credentials	PLC, RTU and safety controller passwords for online access, program download and project upload	Password or protection level set in the engineering software	Default or blank; same value across every controller of a model
Device management accounts	HMI panels, managed switches, protocol gateways, serial servers	Local username and password, SNMP community strings	Vendor default, never changed after commissioning
Historian collector and interface accounts	Collector services reading from OPC or controller drivers and writing to the historian	Windows service account or historian-native account	Domain account with interactive logon and a password unchanged for years
Historian replication and DMZ accounts	Level 3 historian pushing to a DMZ or enterprise historian	Service account, database login or API credential	Same account valid on both sides of the DMZ, linking IT to OT
OPC UA applications	Servers on controllers and gateways, clients in SCADA, MES and historians	Application instance certificate plus a trust list	Self-signed certificates auto-accepted; security mode None allowed
OPC Classic and DCOM	Legacy OPC DA servers and clients	Windows accounts used for DCOM launch and access	Broad DCOM permissions granted to make connections work
Engineering and asset management service accounts	Backup and change management tools, OT asset inventory tools polling controllers, patch tools	Stored controller passwords, Windows and SNMP credentials	One tool holds every controller credential in the plant
Hard-coded credentials	Firmware and vendor application accounts	Fixed in the product	Owner cannot change them

Once the asset inventory exists, attach each of these to its asset, owner and consumers. See the OT Asset Visibility Guide and, for the general NHI model, the Non-Human Identity (NHI) Guide.

Building the OT NHI inventory

Active credential scanning against live controllers is the wrong first move. Most of the inventory can be assembled from records and configuration that engineers already hold, then confirmed with passive network monitoring.

Source	What it reveals	Who holds it
Controller project files and engineering software settings	Which controllers have access and upload protection set, and which do not	Control engineers, integrators
Historian interface and collector configuration	Data source connections, the accounts collectors run as, replication targets	Historian administrators
OPC UA certificate stores and trust lists	Which applications trust which, self-signed versus CA-issued certificates, expiry dates	SCADA and integration engineers
Windows services and scheduled tasks on Level 2 and 3 hosts	Service accounts, the run-as identity of SCADA, OPC and historian components	OT Windows administrators
OT directory (where one exists)	Service accounts, last logon, password age, logon rights	OT identity owner
Backup, change management and asset tools	Every credential the tool stores to reach devices	Tool owner
Passive network monitoring	Which machines actually talk to which, over which protocols, confirming consumers	OT security
Commissioning and vendor documentation	Default accounts, documented hard-coded credentials, required service accounts	Procurement, vendors

For each identity record: the asset and zone, the credential type, where the secret is stored, every consumer that would break if it changed, the owner, the last change date, whether it can be changed at all, and whether it crosses a conduit. The last two fields drive priority. See NHI Inventory Reconciliation.

Controllers and field devices

CISA advisory AA23-335A shows the cost of leaving device credentials alone: IRGC-affiliated actors logged in to internet-connected Unitronics Vision PLCs that used default passwords or none, over TCP 20256, compromising at least 75 devices including at least 34 in US water and wastewater. CISA's mitigations go beyond the main password: set passwords for TCP/IP access, project file upload, INFO mode and SD cards, check controllers for default or missing passwords, and front devices that cannot do MFA with a gateway that can. The joint CISA, FBI, EPA and DOE primary mitigations for OT repeat the message: change default passwords immediately, starting with internet-facing devices that can control processes.

Unique per controller where the product allows: a single plant-wide controller password means one leak opens every line. Group by zone at minimum.
Separate read and write: where the controller offers protection levels, give monitoring tools read-only access and keep program download behind a vaulted credential checked out per change ticket.
Vault, do not document: controller passwords belong in an OT vault, not in spreadsheets, project file comments or panel doors.
Change after vendor work: integrators learn controller passwords during commissioning and support; change them when the work closes.
Record what cannot change: hard-coded or unchangeable credentials go on the risk register with compensating controls.

Protocol-native machine identity

Protocol	Machine identity mechanism	What to configure
OPC UA	Each application instance has an ApplicationInstanceCertificate exchanged when the SecureChannel is set up; the receiver checks it against an administrator-managed TrustList, which can hold CAs and their CRLs	Disable security mode None, stop auto-accepting unknown certificates, move from self-signed to CA-issued certificates managed centrally. See the OPC UA Security Guide
CIP Security (EtherNet/IP)	TLS for TCP traffic and DTLS for UDP, with devices authenticating by X.509 certificate or pre-shared key; devices can enrol their own certificate	Use certificates rather than pre-shared keys where supported; define trust domains as narrowly as operations allow
Modbus Security protocol	Modbus encapsulated in TLS on port 802, with X.509v3 certificates authenticating both client and server	Use where both ends support it; block plain Modbus TCP across conduits that the secure variant serves
OPC Classic (DCOM)	Windows accounts and DCOM permissions	Dedicated accounts, narrowed DCOM rights, or a tunnel or OPC UA wrapper. See the OPC Classic and DCOM Hardening Guide

Historians and data paths

The historian is where OT machine identity most often touches IT: collectors read from controllers, the Level 3 historian replicates to a DMZ or enterprise historian, and reporting tools query it. Each hop has a credential, and a single account valid on both sides of the DMZ quietly undoes the segmentation.

One account per function: separate collector, replication, administration and reporting identities, so a reporting credential cannot write tags or change interfaces.
No identity spans the DMZ: the OT historian authenticates to the DMZ with an identity that exists only for that conduit; enterprise users and tools read from the DMZ copy, never from Level 3.
Managed passwords on Windows: where the historian components run as Windows services on domain-joined hosts and support it, use group managed service accounts. Microsoft documents that Windows manages a gMSA's password, which the domain controller computes from keys supplied by the Key Distribution Service, and that gMSAs apply to Windows services, application pools, scheduled tasks and services that natively support them. See the Group Managed Service Accounts (gMSA) Guide.
Deny interactive logon: collector and replication accounts should not be able to log on locally or over Remote Desktop.
Read-only at source: collectors need read access to controller data, not write; where the driver or OPC server supports it, enforce read-only.

Engineering and tooling service accounts

The highest concentration of OT machine credentials is often inside a tool: backup and version control systems that pull controller programs, asset inventory tools that poll devices, patch distribution servers and remote access brokers. Compromise of that tool's service account or database is equivalent to compromise of every credential it stores.

Treat the tool as tier zero for OT: restrict who can administer it, put it in the zone it serves, and protect its database and backups as you would the OT vault.
Least privilege per task: a backup job needs upload rights, not download; an inventory tool needs read-only SNMP or protocol access.
Engineering workstation context: service accounts that run engineering software components on workstations should be local and unique per host. See the Engineering Workstation Security Guide and the LAPS Guide.
Owner and expiry: every service account has a named owner and a review date; accounts created for a project or vendor end with it. See the Service Account Security Guide.

Certificate lifecycle in OT

Moving to certificates replaces a rotation problem with an expiry problem: an expired OPC UA or CIP Security certificate stops communication as surely as a wrong password. OPC UA Part 12 (version 1.05.07, checked November 2026) defines a CertificateManager, typically combined with a Global Discovery Server, that manages certificates and TrustLists. Clients usually use pull management, calling the CertificateManager to request and update their certificates and TrustLists; servers usually use push management, where the CertificateManager calls methods on them. The CertificateManager should support onboarding, TrustList updates including revocation lists, revocation of a device or application, and renewal of expired or compromised certificates.

Issue from an OT CA: a CA dedicated to OT, offline root and an issuing CA reachable from Level 3, so certificate operations do not depend on IT connectivity. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Validity matched to maintenance: choose validity periods that renew comfortably inside planned maintenance cycles, and alert well before expiry.
Revocation that works offline: distribute CRLs through the TrustList update mechanism rather than relying on online checks from Level 1 and 2.
Trust lists as configuration: back up, version and change-control TrustLists like controller programs.

Decision guidance: rotate, replace or contain

Situation	Approach	Notes
Default or blank credential, changeable	Change now, starting with anything reachable across a conduit or from the internet	Matches the CISA primary mitigations
Shared password across many controllers	Split by zone or line, then per device as maintenance allows	Update the vault and the tools that use it in the same change
Windows service account with static password	Move to gMSA where supported; otherwise vault and rotate in a maintenance window	Test with the dependent application first
Protocol supports certificates	Replace shared secrets with CA-issued certificates and central lifecycle	Plan renewal before you plan rollout
Hard-coded or unchangeable	Contain: segment, filter at the conduit, monitor for use, press the vendor	Record as accepted risk with an owner
Small site, no OT vault	Unique strong passwords recorded in an access-controlled password manager, change after every vendor visit	Better than a spreadsheet; plan a vault when the site grows

Rolling it out

Agree ownership: operations co-own every change; the identity team owns the inventory and standards.
Build the inventory from the sources above, then confirm consumers with passive monitoring.
Triage: rank by reachability (internet, IT, DMZ, zone-internal), privilege (write or download versus read) and blast radius (one device or a fleet).
Fix defaults and blanks first, starting with anything internet or IT reachable.
Test every change offline: in a staging system or on a spare controller, confirm each consumer picks up the new credential or certificate.
Change in maintenance windows, with the previous credential recorded in the vault so the change can be reverted immediately if data stops flowing.
Introduce certificates for OPC UA and other capable protocols once the CA and renewal process are proven.
Bake it into commissioning: no sign-off until default credentials are changed, the identities are in the inventory and the vault holds the secrets.

Detection and measurement

Watch for machine credentials used from the wrong place: a historian replication account authenticating from a workstation, a controller program download outside a change window, a service account logging on interactively, an OPC UA connection from an untrusted or unknown certificate, or a new client appearing in a controller's connection list. ATT&CK for ICS records the relevant behaviours as Valid Accounts (T0859), Remote Services (T0886), External Remote Services (T0822) and Program Download (T0843); in the enterprise matrix, Domain Accounts (T1078.002) covers abuse of OT domain service accounts.

Inventory coverage: percentage of OT assets with their machine identities recorded and owned.
Default credentials remaining: count of devices still on vendor defaults or blank passwords (target zero for changeable devices).
Credential age: median age of OT service account and controller passwords, by zone.
Identities crossing conduits: number of machine identities valid in more than one zone or on both sides of the DMZ (should fall).
Certificate health: share of OPC UA endpoints using CA-issued certificates and security mode other than None; certificates expiring within 60 days.
Change-related outages: data or control interruptions caused by credential changes (shows whether testing is working).

Framework mapping

Control objective	NIST SP 800-53 r5	NIST CSF 2.0	ATT&CK
Inventory of devices and services	CM-8	ID.AM-01, ID.AM-02	T0859
Device authentication	IA-3	PR.AA-01	T0843
Service authentication	IA-9	PR.AA-01	T0886
Credential management and defaults	IA-5	PR.AA-01	T0859, T1078.002
Account ownership and review	AC-2	PR.AA-01	T0859
Certificates	SC-17	PR.AA-01	T0886
Monitoring of machine credential use	AU-12	DE.CM-03	T0822, T0859

For IEC 62443 security levels and component requirements, see the IEC 62443-3-3 and 4-2 Security Levels Guide. NIST SP 800-82 Rev. 3 is the US reference for OT security architecture and countermeasures.

Common failure patterns

Defaults on internet-reachable controllers: the Unitronics compromises in AA23-335A needed nothing more than a default or missing password.
Only the main password changed: upload, INFO mode or SD card passwords left at default, as CISA's advisory warns.
Historian account spanning IT and OT: one domain account used for collection, replication and reporting, giving an IT attacker a valid path into Level 3.
Auto-accepted OPC UA certificates: trust lists that accept any self-signed certificate, so certificate security exists on paper only.
Rotation without a dependency map: a password change that stops a collector or interface, after which the organisation stops rotating altogether.
The backup tool nobody counts: a change management or backup server holding every controller password, administered from the IT domain.

Practitioner checklist

Build an OT machine identity inventory from project files, historian configuration, trust lists and Windows services, then confirm with passive monitoring.
Record for each identity its owner, consumers, storage location, last change and whether it can change.
Change every changeable default or blank credential, starting with internet and IT reachable devices.
Set all device-level passwords, not only the main one, and vault them per controller or zone.
Separate historian collector, replication, admin and reporting identities; let none span the DMZ.
Move Windows-based OT services to gMSA where supported and deny interactive logon.
Disable OPC UA security mode None and certificate auto-accept; issue certificates from an OT CA.
Treat backup, change management and asset tools as tier zero for OT.
Test every credential change offline and keep the previous value for immediate rollback.
Track the six metrics above and report them to operations and security leadership.

NHIs in OT: Inventorying and Securing Controller, Historian and Service Credentials