Identity for OT Environments Guide: Securing Access to Industrial Systems

Most OT networks still let one stolen corporate password, one default PLC credential or one vendor VPN account reach systems that move physical processes. The fix is not a single product but an identity architecture: which directory each zone trusts, where domain controllers sit, how shared and default accounts are contained, how vendors get in, where privileged credentials are vaulted, and how operators still sign in when the link to the corporate network is cut. This guide is the design view of those decisions for OT architects, IAM teams and plant security leads. It assumes the basics in the OT and ICS Identity and Access Guide; sector detail is in the Manufacturing Identity and OT Access Guide and the Critical Infrastructure Identity Security Guide.

Key takeaways

• Design identity per zone, not per site. Each IEC 62443 zone should have a defined identity store, a defined set of admin identities, and a conduit rule that says which identities may cross it.
• Trust flows down, never up. Nothing in the corporate directory should be able to administer OT identity; OT administrators should use devices and accounts at least as trusted as the systems they manage.
• Vendors enter through one brokered path. A single hardened access point in the DMZ, outbound-initiated and enabled only when needed, replaces per-vendor VPNs and remote tools.
• Shared and default accounts are contained, not ignored. Change every default, vault what must stay shared, and attribute use to a person through check-out records and shift rosters.
• Authentication must survive isolation. Plan cached logons, local authentication and offline-capable MFA so cutting the IT link during an incident does not lock out operators.

Identity zones and trust boundaries

IEC 62443 groups assets into zones with common security requirements and controls traffic between them through conduits. Foundational Requirement 1 of IEC 62443-3-3, identification and authentication control, covers human users (SR 1.1), software processes and devices (SR 1.2), account management (SR 1.3), authenticator management (SR 1.5) and access via untrusted networks (SR 1.13); FR2 use control covers authorisation enforcement (SR 2.1) and remote session termination (SR 2.6). The practical step is to write those down per zone. NIST SP 800-82 Rev. 3 asks for separate authentication mechanisms and credentials for the OT and corporate networks, and Microsoft's enterprise access model places the access control systems for legacy OT, including network access control, in the control plane, the highest-trust layer.

Whether the OT directory should trust corporate at all is a sector and size decision covered in the Manufacturing Identity and OT Access Guide. Whatever is chosen, treat any trust as a conduit: document it, monitor authentication across it, and be ready to cut it. See the IEC 62443 Guide and the Network Segmentation Guide.

Active Directory placement: OT forest, DMZ and site controllers

Active Directory is the most common identity store in Level 3 and it is also the most common route from IT into OT: ATT&CK lists Valid Accounts (T0859) and Remote Services (T0886) for ICS, and Domain Accounts (T1078.002) in enterprise. Getting the placement right matters more than any single setting.

• Separate OT forest: OT domain controllers, OT admin groups and OT Group Policy live in their own forest. Corporate Domain Admins have no rights there. This is the identity equivalent of the DMZ that SP 800-82 describes for traffic.
• No corporate DCs in the DMZ: placing a corporate domain controller or a domain-joined jump host from the corporate forest in the DMZ extends the corporate Tier 0 to the OT boundary. If DMZ servers need a directory, give the DMZ its own small domain or use the OT directory with a narrow, documented conduit.
• Tier 0 inside OT: OT domain controllers, the OT PAM vault, the remote access broker and the backup system for them are the OT control plane. Administer them only from OT privileged access workstations. Microsoft's model requires that lower planes cannot control higher ones, and the NCSC calls the same idea browse-down. See the Tiered Administration and Enterprise Access Model Guide.
• Read-only domain controllers at remote sites: an RODC stores no user or computer passwords by default, caches only accounts allowed by its Password Replication Policy, does not replicate changes outbound, and supports delegated local administration without domain rights. It suits small substations or pumping stations with weak physical security. Keep privileged accounts out of the allowed list, and remember an RODC forwards authentication for uncached accounts to a writable DC, so it does not by itself solve the isolated-site problem.
• Kerberos and NTLM hygiene: the same attacks that work in IT work in OT forests, and patch windows are longer. See the Kerberos Security Guide and the Active Directory and Entra ID Hardening Guide.

Shared, default and local accounts

CISA's primary mitigations for OT list changing default passwords immediately, and the CISA advisory AA23-335A shows why: actors linked to Iran's IRGC logged in to internet-exposed Unitronics PLCs that had default or no passwords over TCP 20256, compromising at least 75 US devices, 34 of them in water. ATT&CK v20 now records this pattern under Valid Accounts (T0859) and Internet Accessible Device (T0883).

For small sites without a directory, a vault that stores unique local passwords per device and logs every check-out gives most of the benefit of central identity. Large estates should aim for a directory in Level 3 and local accounts only below it.

Vendor and third-party remote access architecture

The CISA primary mitigations call for remote access over a VPN on a private connection with phishing-resistant MFA and least privilege per asset, role and scope of work, and for disabling dormant accounts. The NCSC-led secure connectivity principles for OT (published January 2026 with CISA and partner agencies) go further on design: route remote access through one hardened, reusable access path in the DMZ rather than a separate VPN endpoint per vendor, have external parties connect to a broker that relays to the asset so the asset is never directly exposed, initiate connections outbound from the OT side, and enable connections only when needed.

1. Identity at the edge: each vendor engineer has a named account in the broker, federated from the vendor's IdP or issued by you, with phishing-resistant MFA. No shared vendor accounts. See the Third-Party Access Guide.
2. Approval and time window: access is requested against a work order, approved by the asset owner, and opens only for the maintenance window.
3. Brokered session: the broker injects a vaulted credential for the target, so the vendor never learns the device or local admin password, and records the session.
4. Live supervision: high-risk work, such as logic downloads, is watched live by site staff with the ability to terminate, matching SR 2.6 remote session termination. See the Privileged Session Management Guide.
5. Closure: the window closes, the account is disabled, and the target credential rotates.

The NCSC principles also ask that you can revoke one third party's access during an incident while other connections keep running, which is only possible if each vendor has its own identity and path. Contracts should let you set and update these requirements over time. ATT&CK maps the threat to External Remote Services (T0822 for ICS, T1133 for enterprise). See the Remote Access Identity Guide.

OT privileged access management

PAM in OT is usually a separate instance inside the OT zone, not the corporate vault reached across the boundary. The decision guidance:

• Rotation with care: rotate only credentials whose change has been tested against the dependent application. A rotated historian service password that the collector cannot pick up stops data flow. Start with verify-only mode, then rotate in maintenance windows.
• Privileged access workstations: the NCSC principles favour administration through privileged access workstations, and limiting administration of critical or obsolete systems to local physical access.
• Just-in-time elevation: engineers hold standard accounts and receive group membership or a checked-out credential tied to a change ticket. See the JIT Access Guide.
• Break-glass: the NCSC principles state that break-glass use should trigger the highest criticality alarm; design and testing are in the Break-Glass Account Guide.

Offline and degraded-mode authentication

CISA lists the ability to operate OT manually as a primary mitigation, and the NCSC asks for an isolation plan. Identity is often the hidden dependency that breaks isolation: operators cannot sign in because a DC, an MFA cloud service or a licence server is on the far side of the cut.

• Directory reachable inside the zone: at least two writable OT DCs per site or per resilient zone, so isolating the site from the corporate WAN does not remove authentication.
• Cached logons: the Windows policy "Interactive logon: Number of previous logons to cache (in case domain controller is not available)" accepts 0 to 50 and defaults to 10; cached entries never expire. Microsoft notes the security trade-off: cached verifiers can be extracted and attacked offline, and 0 means nobody can sign in without a DC. On control room stations, keep caching for the operator accounts that must work during isolation; on admin and engineering hosts with resilient DCs, reduce it.
• Offline-capable MFA: smart cards and certificate-based logon against a local DC, or hardware tokens validated on site, keep MFA working when cloud MFA is unreachable. See the Smart Card and PIV/CAC Authentication Guide.
• No lockout on operator stations: SR 1.11 covers unsuccessful login attempts, but lockout on an HMI during an upset is a safety risk; prefer alerting and longer delays over hard lockout on operator roles.
• Test the cut: include an identity check in isolation exercises: disconnect the site link and confirm operators, engineers and break-glass all still work.

Rolling out the architecture

1. Map identity to zones: for every zone list the identity store, admin identities, service accounts, vendor paths and trusts. Use the asset inventory. See the OT Asset Visibility Guide.
2. Close the worst paths first: remove internet-exposed device logins, change default passwords, and disable dormant vendor and VPN accounts.
3. Stand up the broker and OT vault in parallel with existing access: onboard one vendor and one site as a pilot, keeping the old path disabled but restorable.
4. Move admin rights into the OT forest: create OT admin groups, remove corporate groups from OT local administrators, and audit logons for two weeks before removing any trust.
5. Exercise isolation: cut the site link in a maintenance window and record which sign-ins failed.
6. Roll back safely: every change to authentication on running systems needs a tested reversal, such as re-enabling a disabled trust or reverting a GPO, agreed with operations before the window.

Detection and measurement

• Logons crossing zones: Windows event 4624 on OT hosts with a logon type 10 (remote interactive) or 3 (network) from sources outside the broker or OT PAWs.
• Corporate identities in OT: any authentication of a corporate account or group SID on OT systems, and event 4769 Kerberos service ticket requests crossing a trust.
• Privileged group changes: events 4728, 4732 and 4756 on OT DCs outside change tickets.
• Vendor sessions: broker sessions outside approved windows, and any remote tool traffic not passing through the broker.
• Break-glass and controller access: any break-glass check-out, and controller program downloads not tied to a work order.

Framework mapping

Common failure patterns

• Forgotten remote access accounts: in the Colonial Pipeline attack a legacy VPN account that had never been disabled, without MFA, gave ransomware operators access; the pipeline was shut down as a precaution even though no OT compromise was reported. Identity failures in IT stop OT operations.
• Corporate forest trusted by OT: a two-way trust or corporate admin groups in OT local administrators, so ransomware with Domain Admin in IT reaches HMIs.
• Jump host joined to the corporate domain: the DMZ jump server is administered from IT, which makes it a bridge rather than a boundary.
• Per-vendor VPNs and remote tools: each integrator installs its own tool, nobody owns the full list, and accounts outlive contracts.
• Isolation untested: the site link is cut during an incident and operators cannot sign in because MFA or the directory sat in IT.
• Rotation without dependency testing: PAM rotates a service account and historian or SCADA communications fail, after which rotation is switched off for good.

Practitioner checklist

• Document the identity store, admin identities, service accounts and allowed crossings for every OT zone.
• Remove corporate groups and accounts from OT systems and put OT administration in a separate forest or domain.
• Keep corporate domain controllers and corporate-joined hosts out of the DMZ.
• Treat OT DCs, the OT vault, the broker and their backups as OT Tier 0, administered from OT PAWs.
• Change all default passwords and record exceptions with compensating controls.
• Route all vendor access through one broker with named accounts, phishing-resistant MFA, time windows and recording.
• Vault local admin, controller and shared passwords, and rotate only after dependency testing.
• Configure cached logons and offline-capable MFA deliberately per station role.
• Run an identity isolation test at every site at least annually.
• Alert on cross-zone logons, corporate SIDs in OT and break-glass use.

Standards and references

• ISA: ISA/IEC 62443 Series of Standards
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• NCSC: Secure connectivity principles for operational technology
• CISA: Advisory AA23-335A on IRGC-affiliated actors exploiting PLCs
• Microsoft: Enterprise access model
• MITRE ATT&CK: External Remote Services (ICS)

Related NHI Mgmt Group resources: OT and ICS Identity and Access Guide · Manufacturing Identity and OT Access Guide · Critical Infrastructure Identity Security Guide · IEC 62443 Guide · Privileged Access Management Guide