OT and ICS Identity and Access Management Guide

Operational technology runs factories, pipelines, power, water, hospitals and transport, and its identity practices are often decades behind IT. Shared operator logins, default passwords on controllers, vendor accounts that never expire and remote access tools installed "temporarily" are common, partly because availability and safety come first and partly because much OT equipment was never designed for modern authentication. This guide is about one slice of OT security: who and what can log in, change logic or reach a controller, and how to prove it. It covers the identities found in OT, what IEC 62443, NIST SP 800-82 and recent joint government guidance require, controls that respect operational constraints, detection, metrics and a phased roadmap. It is written for OT security, identity and plant engineering teams; for OT security as a whole (architecture, protocols, monitoring, safety), see the OT Security Guide.

Key takeaways

Most OT compromises start in IT or through remote access. Joint CISA-led guidance warns that shared domains or credentials let attackers move from IT into OT, so a separate OT identity boundary gives the biggest early gain.
Vendor and integrator access is the highest-risk identity path. Broker it through one monitored route, enable it only for approved windows, require MFA and record the session.
Default and shared credentials are still how controllers fall. CISA's 2023 advisory on attacks against internet-facing PLCs found devices with default passwords or none at all.
Compensate where devices cannot authenticate. IEC 62443-3-3 and NIST SP 800-82 both expect compensating countermeasures (jump hosts, vaulting, physical controls, monitoring) rather than accepting anonymous access.
Safety sets the rules. Design emergency access, lockout policy and change windows with operations as co-owners.

Identities in OT environments

An OT estate holds far more identities than its staff list suggests, and many of them are non-human. NIST SP 800-82 Rev. 3 asks organisations to manage the credential life cycle (issuance, revocation and updates) for users, devices and processes across the OT environment.

Identity	Typical problem	First control
Operators on HMIs and consoles	Shared accounts, always-logged-in stations, no individual attribution	Attribute use through badge, shift log or vaulted checkout
Engineers and administrators	Domain accounts shared between IT and OT; standing rights to change logic	Separate OT accounts, just-in-time elevation
Vendors and integrators	Permanent remote accounts, shared credentials, tools outside change control	Brokered, time-boxed, recorded access
PLCs, RTUs and IEDs	No authentication, or default and hard-coded credentials	Change defaults; restrict who can reach and program them
Service accounts and applications	Broad rights, old passwords, used interactively by people	Inventory, owner, least privilege, rotation through a vault
Machine identities	Manual provisioning, expired certificates, no owner	Certificate inventory and a renewal process that cannot stop production
AI and analytics systems	Inbound access into OT for data, identity indistinguishable from other users	Push data out; give the AI system its own logged identity
Building, medical and connected devices	Vendor-managed with limited visibility	Inventory and segment. See the Device and IoT Identity Guide

MITRE ATT&CK for ICS records the attacker's view of this inventory. T0859 Valid Accounts notes that default credentials for control system devices may be publicly available and that overlapping credentials can let an adversary pivot "between the enterprise and operational technology environments". T1694 Insecure Credentials covers default and hard-coded credentials, which attackers favour because "they are typically forgotten about by system and device owners". For discovering these assets, see the OT Asset Visibility Guide.

Standards and guidance

IEC 62443

The ISA/IEC 62443 series sets requirements for industrial automation and control systems (IACS) and assigns them to asset owners, product suppliers, integrators and service providers. Part 3-3 groups system requirements under seven foundational requirements; identification and authentication control (FR 1) and use control (FR 2) carry most of the identity content, and the part also covers compensating countermeasures and least privilege. Part 2-4 sets security programme requirements for IACS service providers, which is where vendor and integrator access is addressed. For the full series, see the IEC 62443 Guide.

IEC 62443-3-3 requirement	What it means for identity in practice
SR 1.1 Human user identification and authentication	Named accounts for operators, engineers and vendors wherever the system supports them
SR 1.2 Software process and device identification and authentication	Service accounts, applications and devices authenticate too, not only people
SR 1.3 Account management; SR 1.4 Identifier management	Joiner, mover and leaver processes that reach OT and vendor accounts
SR 1.5 Authenticator management; SR 1.7 Strength of password-based authentication	Default passwords changed, shared secrets vaulted, password strength within device limits
SR 1.8 PKI certificates; SR 1.9 Strength of public key authentication	Certificate life cycle for secure protocols
SR 1.11 Unsuccessful login attempts	Lockout settings that cannot lock an operator out during an emergency
SR 1.13 Access via untrusted networks	Remote and vendor access controlled at the boundary
SR 2.1 Authorization enforcement; SR 2.6 Remote session termination	Role separation for operate, engineer and administer; remote sessions that can be ended
SR 2.8 Auditable events; SR 2.12 Non-repudiation	Logs that tie actions to an individual, even where accounts are shared

Requirement names are from the IEC 62443-3-3:2013 table of contents; the full text is in the purchased standard.

NIST SP 800-82

NIST SP 800-82 Rev. 3 (September 2023) asks organisations to weigh "the increased risks of authenticated accounts from IT environments having access within the OT environment against the benefits of using centralized accounts", to use compensating countermeasures such as physical security where OT cannot support authentication, and notes that entering credentials during an emergency can delay an operator. The initial public draft of Revision 4 (21 September 2026) is restructured around NIST CSF 2.0; comments close on 30 November 2026.

Joint government guidance and regulation

Adapting Zero Trust Principles to OT (April 2026): CISA and four US federal partners set out identity, credential and access management (ICAM), jump hosts and PAM for OT.
Primary Mitigations to Reduce Cyber Threats to OT (May 2025): CISA, FBI, EPA and DOE ask operators to take OT off the public internet, change default passwords, use phishing-resistant MFA for remote access and disable dormant accounts.
Third-party ICS integrators (September 2026): an FBI and CISA fact sheet asks for least privilege, monitored remote access and authorised personnel listed in contracts.
Regulation: NIS2 Article 21(2) requires access control policies (point i), supply chain security (point d) and "the use of multi-factor authentication or continuous authentication solutions ... where appropriate" (point j). See the NIS2 Directive Guide.

Controls that work in OT

Separate IT and OT identity

Do not connect the two identity systems directly. The joint zero trust guidance says to avoid direct IT-OT trust relationships and that Active Directory used in OT should be entirely segmented, "ideally as a separate forest or domain".
No IT admin accounts in OT: do not let IT administrators log in to OT systems, or OT administrators to IT, without deliberate, logged elevation. See the Tiered Administration Guide.
Protect boundary systems as tier zero: jump hosts and DMZ servers that bridge IT and OT are prime targets.

Broker remote access

One entry point: the joint guidance "strongly" recommends a hardened jump host in the OT DMZ as the sole entry point for remote access, requiring MFA, patched, hardened and continuously monitored. See the Remote Access Identity Guide.
Time-boxed vendor access: enable vendor accounts only for approved maintenance windows and disable them automatically afterwards. NIST SP 800-82 suggests automatic timers for removing temporary remote access.
Record and watch: log all privileged sessions and push the logs out of OT without bi-directional control. See the Privileged Session Management Guide.
Remove unmanaged tools: take direct remote desktop, modems and unmanaged remote support software off OT networks.

Deal with shared accounts realistically

The joint guidance accepts that "privileged accounts may be shared accounts used by operators, with well-monitored break-glass accounts for emergency access". The aim is attribution, not purity.

Attribute: where the HMI supports it, use badge login or fast user switching.
Vault: where it does not, keep the shared credential in a vault, record who checked it out and when, and correlate with shift rosters. Vaulting also eases rotation.
Rotate on change: NIST SP 800-82 asks for procedures to change shared passwords when one is compromised or someone with access leaves.
Kill the defaults: change default passwords on every PLC, HMI, switch and gateway before deployment, and store them safely, since many OT systems have no password recovery.

Least privilege and privileged access

Separate roles: distinguish operator, engineer and administrator, and treat any account that can compromise safety or process integrity as privileged.
Just-in-time elevation: grant engineering rights for the duration of a change ticket. See the JIT Access Guide and the Privileged Access Management Guide.
MFA on change: the joint guidance recommends MFA to restrict firmware or logic changes for critical systems and on all privileged access from remote or external environments, noting that physical access is a common second factor in existing OT.
Service accounts: give historian, OPC and backup accounts owners and stop interactive use. See the Service Account Security Guide.

Authenticate devices and protocols

Legacy industrial protocols cannot confirm which device sent a message. CISA's February 2026 study of why operators have not adopted secure protocol versions (DNP3-SAv5, CIP Security, Modbus Security, OPC UA) found that "almost every operator interviewed mentioned challenges with deploying and maintaining PKI". CISA recommends signing communications, starting with remote access paths, boundaries between zones, firmware uploads and logic changes, and phasing in by signing first without dropping packets. Treat these certificates as owned machine identities. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Segment by zone and conduit

IEC 62443 groups assets into zones and controls communication between them through conduits. Pair segmentation with identity: only named, authenticated identities should cross a conduit, and every crossing should be logged. For segmentation design, see the Network Segmentation and Microsegmentation Guide and the Zero Trust Identity Guide.

AI systems in OT

Joint guidance from CISA, ASD's ACSC and partners (December 2025) on integrating AI into OT asks operators to prefer push-based or brokered architectures "without granting persistent inbound access", to route any new connection through the existing DMZ or jump host, to limit active control by AI without a human in the loop, and to configure logging so "the logged AI identity is distinct from any typical machine or user identifiers". See the Zero Trust for AI Agents Guide.

Planning around operations

OT constraint	Identity control affected	Practical approach
Operators need immediate access in an emergency	Login prompts, MFA, session lock	Physical access control to the room, local break-glass with audit, no MFA at the console itself
Lockout could stop an operator mid-incident	Unsuccessful login policy	Alert on failed attempts instead of locking critical consoles
Policies pushed from a domain can break HMIs	Auto-logoff, password replacement	Exclusion lists by machine, as NIST SP 800-82 warns
Devices support one shared account or none	Individual authentication	Jump host with MFA in front, vaulted credential, network restriction
Expired certificates could halt communication	Secure protocols	Signing before encryption; renewal tracking with alerts well ahead of expiry

Test before production: trial authentication changes in staging or a maintenance window, never on a running process.
Design break-glass for safety: the joint guidance calls emergency access "non-negotiable" and asks for documented procedures and break-glass accounts "with limited lifespans and stringent auditing". See the Break-Glass Account Guide.
Co-own policy: make plant managers, operators and engineers co-owners of access policy, with agreed escalation when a control could affect safety.
Practise manual operation: CISA's primary mitigations ask operators to keep and test the ability to run OT manually, which also limits the damage a compromised identity can do.

Detection and monitoring

Identity detections in OT should fire when behaviour breaks the approved access model and stay quiet during approved shifts, vendor windows and commissioning, which MITRE calls an "operational-fidelity gate".

Default or hard-coded credentials in use: successful authentication to ICS applications or network device interfaces with known vendor credentials (MITRE T1694).
Remote access out of pattern: ICS-role accounts logging in to the remote access gateway from an unusual location, then connecting into the ICS zone (MITRE T0822 External Remote Services).
Internet logons to devices: CISA's PLC advisory asks operators to monitor for unexpected or unusual access to devices from the internet.
Vendor sessions outside windows: any vendor connection outside an approved ticket, or from an unregistered device.
IT credentials in OT: any IT domain account authenticating to an OT system.
Logic and firmware changes: program downloads or mode changes not linked to a change record.
New accounts: accounts created on controllers, HMIs or the OT domain outside provisioning; T0859 notes adversaries create accounts for backup access.

For tooling and response, see the ITDR Guide and the OT Incident Response Guide.

Lessons from incidents

Colonial Pipeline (2021): the CEO told the US Senate that attackers used a legacy VPN profile the company no longer used, which did not have multi-factor authentication. The company shut down the pipeline as a precaution.
Ukraine power grid (2015): MITRE records that Sandworm Team used valid accounts to move through VPN connections and dual-homed systems to HMI workstations.
Unitronics PLCs (2023): CISA reports that IRGC-affiliated actors compromised internet-connected PLCs at US water facilities "likely by compromising internet accessible devices with default or no passwords", then set upload passwords that stopped operators reprogramming them remotely.
Industrial integrator (2025): according to FBI analysis, foreign actors inside a US industrial automation company's network in March and April 2025 searched for "customers" and "SCADA" and staged about 800 files of customer ICS information.
Jaguar Land Rover (2025): a cyberattack halted production at sites in the UK, China, India and Slovakia for weeks; the access route has not been published.
Stryker (2026): a source told BleepingComputer the attacker compromised an administrator account, created a new Global Administrator and used Intune to wipe nearly 80,000 devices. Device management consoles that reach OT-adjacent endpoints are privileged infrastructure.

Common failure patterns

One domain for IT and OT: a single Active Directory trust lets stolen IT credentials reach HMIs, the path joint guidance warns about.
Permanent vendor accounts: remote support accounts left enabled between visits, shared among a vendor's staff and never reviewed.
Defaults left in place: controllers commissioned with factory passwords and exposed to the internet, as in the Unitronics campaign.
Dormant remote access: VPN profiles that nobody uses but nobody disabled, the Colonial Pipeline entry point.
Shared accounts without attribution: a station logged in for years, so no action can be tied to a person after an incident.
IT policy pushed blindly: lockout or auto-logoff applied from the domain, prompting exemptions that are never removed.
Break-glass that is never tested or reviewed: emergency credentials known to many people, unchanged and unmonitored.

Framework mapping

This is an indicative NHI Mgmt Group alignment, not an official mapping. IDs were checked against the NIST CSF 2.0 text, the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 list (control level), an ISO/IEC 27001:2022 Annex A control list and the OWASP NHI Top 10 2025.

Control area	IEC 62443-3-3	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP NHI
Identity inventory and life cycle	SR 1.3, SR 1.4	PR.AA-01, ID.AM-08	AC-2, IA-4	A.5.16	5	NHI1
Human, device and process authentication	SR 1.1, SR 1.2	PR.AA-03	IA-2, IA-3	A.8.5	6	NHI4
Default and shared credentials	SR 1.5, SR 1.7	PR.AA-01	IA-5, IA-5(1), AC-2(9)	A.5.17	4, 5	NHI7, NHI10
Least privilege and role separation	SR 2.1	PR.AA-05	AC-3, AC-6, AC-6(5)	A.5.15, A.5.18, A.8.2	6	NHI5
Remote and vendor access	SR 1.13, SR 2.6	PR.AA-05, GV.SC-05, DE.CM-06	AC-17, MA-4, PS-7	A.5.19, A.5.20	6, 15	NHI3
Zones, conduits and the IT/OT boundary	SR 5.1, SR 5.2	PR.IR-01	SC-7	A.8.20, A.8.22	12, 13	NHI8
Audit and monitoring	SR 2.8, SR 6.2	DE.CM-03, PR.PS-04	AU-2, AU-6, SI-4, AC-2(12)	A.8.15, A.8.16	8, 13	No direct item
Emergency access	SR 1.11	PR.AA-05	AC-14, AC-2	A.5.18	5	No direct item

Metrics that show progress

Metric	What it shows	Target direction
OT devices still on default credentials	Exposure to the simplest attacks	Down, towards zero
OT assets reachable from the internet	Attack surface CISA asks operators to remove	Down, towards zero
Remote access paths not through the broker or jump host	Unmanaged routes into OT	Down, towards zero
Vendor accounts enabled outside approved windows	Standing third-party access	Down
Privileged and remote sessions recorded	Attribution and forensic readiness	Up, towards 100%
IT domain accounts with rights in OT	Strength of the IT/OT identity boundary	Down, towards zero
Shared credentials vaulted with checkout records	Attribution where individual accounts are impossible	Up
Logic or firmware changes with a matching change record	Control over the most dangerous action	Up, towards 100%

Implementation roadmap

Phase	Actions	Outcome
First 30 days	Find internet-exposed OT assets and remote access paths; list vendor accounts; change default passwords on exposed devices; disable dormant remote accounts	The easiest routes in are closed
Days 31 to 90	Stand up a single brokered remote access path with MFA and recording; vault shared and vendor credentials; agree break-glass procedures with operations; start the OT identity inventory	Remote and vendor access is controlled and attributable
Days 91 to 180	Separate the OT domain or forest from IT; introduce role separation and just-in-time elevation for engineering changes; deploy the detections above; add integrator requirements to contracts	Stolen IT credentials no longer reach OT; privileged change is time-bound
Beyond 180 days	Specify secure protocols and certificate management in procurement; phase in signing; give AI and analytics systems their own identities with push-based data flows; review against IEC 62443 and regulation yearly	Devices and machines authenticate, not only people

To benchmark the wider programme, see the OT Security Maturity Model.

Practitioner checklist

Inventory OT identities: operators, engineers, vendors, devices, service accounts, certificates and AI systems.
Remove OT assets from the public internet and change every default password.
Separate OT identity from the IT domain and protect boundary systems as tier zero.
Route all remote and vendor access through one jump host with MFA, approval, time limits and recording.
Vault shared credentials and attribute every checkout to a person and shift.
Separate operator, engineer and administrator roles, with just-in-time elevation for changes.
Require MFA for logic and firmware changes and for all privileged remote access.
Design, document and test break-glass access with operations.
Alert on default credentials, IT accounts in OT and vendor sessions outside windows.
Give AI and analytics systems distinct identities and no persistent inbound access.

Standards and references

Related NHI Mgmt Group resources: OT Security Guide · IEC 62443 Guide · Remote Access Identity Guide · Third-Party Access Guide · Privileged Access Management Guide

OT and ICS Identity and Access Guide