Identity and Privileged Access Management for OT

01Key takeaways

1. 01

   OT identity and access management exists to bind a real, accountable identity to every interaction with a control system, then limit what that identity can do.

2. 02

   Shared, local and service accounts are the dominant OT identity problem; they break attribution, resist rotation, and survive personnel changes.

3. 03

   Privileged access management reduces standing privilege through credential vaulting, session brokering, just-in-time elevation and recorded sessions.

4. 04

   MFA, RBAC and disciplined account lifecycle are achievable in most OT zones, but the design must respect safety, availability and legacy constraints.

5. 05

   IAM and PAM reduce who can reach a system; one-way transfer and segmentation reduce whether a path exists at all. They are complementary, not interchangeable.

02What OT identity and access management means

Identity and access management (IAM) in operational technology is the set of controls that decide which people, devices and processes may interact with control systems, and what they are permitted to do once authenticated. Privileged access management (PAM) is the subset that governs high-impact accounts — the ones that can change control logic, modify setpoints, push firmware, manage users or reconfigure infrastructure.

The distinction from IT is not the concept but the conditions. OT identity has to work around equipment that may not speak modern authentication protocols, around safety functions that must never be blocked by a login prompt, and around a culture where a shared operator login on a 24/7 console is normal. The goal is the same as IT: attribution, least privilege and accountability. The path to get there is different.

Short version: OT IAM decides who can reach what; OT PAM decides who can change what, and tries to make sure no one has that power standing idle by default.

03Why identity is the hardest problem in OT security

In most OT environments the weakest link is not an unpatched protocol stack — it is an account. Engineering workstations log in once and stay logged in. Vendor accounts are created for a commissioning project and never disabled. Service accounts carry passwords embedded in scripts and HMI projects. When an incident happens, logs show that operator01 did something at 3 a.m., but no one can say which human that was.

Threat actors understand this. The ICS-tailored techniques in the MITRE ATT&CK for ICS knowledge base repeatedly rely on valid accounts: adversaries use legitimate credentials for remote services, abuse engineering-workstation access, and pivot through trusted accounts rather than exploiting novel vulnerabilities. Stolen or shared credentials turn segmentation, firewalls and monitoring into obstacles that are simply walked around with a valid login.

• Shared operator and engineering logins make it impossible to attribute an action to a person.
• Long-lived vendor and contractor accounts create standing remote access no one is tracking.
• Hard-coded service-account passwords cannot be rotated without breaking automation.
• Local HMI and PLC accounts live outside any central directory and rarely change.
• Default and well-known credentials remain in service because changing them risks an outage.

04Shared, service and local HMI accounts

The defining IAM challenge in OT is the account that is not tied to one person. These accounts exist for good operational reasons — a control-room console cannot demand a fresh interactive login during a plant trip — but they corrode accountability and resist normal hygiene.

Shared interactive accounts

Common operator or engineering logins used by multiple staff on shared consoles. Useful for continuity, but break per-person attribution and rarely get their passwords changed.

Service and machine accounts

Non-human identities used by software to talk to historians, OPC servers, databases and SCADA components. Often carry static, embedded passwords that automation depends on.

Local device accounts

Credentials stored on individual HMIs, PLCs, RTUs and switches, outside any central directory. They are the hardest to inventory, rotate or disable centrally.

Vendor and remote-support accounts

Access granted to integrators and OEMs for maintenance. High privilege, intermittent use, and frequently left enabled long after the work is done.

The practical response is not to abolish these accounts — many cannot be removed — but to wrap them in management. Inventory every one of them. Bring shared and privileged credentials into a vault. Attach an individual identity at the point of checkout, so the shared login still works on the console but the person who retrieved it is recorded. Where local accounts cannot be centralized, at least document, rotate on a schedule, and monitor their use.

05How privileged access management works in OT

PAM addresses standing privilege — the credentials that sit unused but ready, waiting to be stolen or misused. Instead of engineers and vendors holding permanent administrative passwords, a privileged access system brokers access on demand and records what happens.

Credential vaulting

Privileged passwords and keys are stored in a hardened vault, not in scripts, spreadsheets or people's heads. The vault releases them under policy and rotates them after use.

Session brokering

Users connect to a target through a proxy that injects the credential, so the human never sees or types the actual password. The session can be recorded keystroke-by-keystroke.

Just-in-time elevation

Privilege is granted for a defined task and time window, then automatically revoked, so no account carries standing administrative rights between jobs.

Session recording and review

Privileged sessions are logged and, where feasible, video-recorded, giving auditable evidence of every command issued against a control system.

In OT this layers on top of, not instead of, network controls. A PAM broker and a jump server are related but distinct: the jump host is the controlled choke point that traffic must pass through, while PAM governs the credentials and sessions that flow across it. The two are strongest together — the bastion enforces the path, PAM enforces who and what.

06Role-based access control and least privilege

Least privilege means an identity holds only the access its function requires, and nothing more. In OT this is usually expressed through role-based access control (RBAC): roles such as operator, maintenance technician, control engineer, network administrator and read-only auditor, each mapped to a defined set of permissions on defined assets.

RBAC works well in OT because job functions are stable and well understood. An operator needs to acknowledge alarms and adjust permitted setpoints; only a control engineer should be able to change logic or download a new program to a PLC. Separating those roles limits the blast radius of a compromised account and supports separation of duties — the person who writes a change should not be the only person who can approve and apply it.

• Define roles around real OT job functions, not around individual people or convenience.
• Scope each role to specific zones and assets, not to the whole control network.
• Keep read-only roles genuinely read-only, including for safety and historian systems.
• Separate the ability to author a control-logic change from the ability to deploy it.
• Review role membership on a fixed cadence and remove access that is no longer justified.

07MFA and stronger authentication where feasible

Multi-factor authentication is one of the highest-value controls for OT remote and privileged access, and CISA and NIST guidance treat it as a baseline expectation for any path into a control environment. The realistic position for OT is MFA where feasible: applied firmly at the points where it does not endanger operations, and engineered carefully where it might.

Enforce MFA at the boundaries that matter most — remote access into the OT network, the jump server, the PAM broker, and administrative logins to engineering workstations and domain services. Be deliberate about where MFA must not sit in a safety path: a prompt for a second factor must never delay an operator's response to a plant emergency. The answer is usually to authenticate the operator strongly at session start and at privileged actions, not to interrupt time-critical control.

Treat phishing-resistant MFA — hardware security keys or certificate-based authentication — as the target for remote and privileged OT access. SMS and email one-time codes are better than nothing, but they are the controls attackers have learned to defeat.

08Account lifecycle and break-glass access

An identity program is only as good as its joiner-mover-leaver discipline. Every OT account should have a known owner, a reason to exist, and a defined end. In practice this is where OT most often fails: people change roles or leave, and their access lingers because no process connects HR or contract status to OT account state.

• Provision access from defined roles when someone joins, with an approval that is recorded.
• Adjust entitlements promptly when someone changes job function, removing what they no longer need.
• Disable accounts the moment a person, contractor or vendor engagement ends — same day, not next audit.
• Review dormant accounts on a schedule and disable anything unused beyond a set threshold.
• Reconcile the OT account inventory against directory, HR and contract records regularly.

Break-glass access is the deliberate exception. There must be a way to reach a system fast during a genuine emergency, even if the normal IAM stack is unavailable. The discipline is to make break-glass controlled rather than casual: a sealed, vaulted credential, dual authorization to release it, loud alerting whenever it is used, and a mandatory rotation and review afterward. A break-glass account that quietly becomes a daily shortcut is no longer an emergency control — it is an unmanaged privileged account.

09Standards, compliance and common pitfalls

OT identity controls map cleanly onto the major frameworks, which is useful both for design and for audit. The point of the mapping is not to chase certificates but to show that access decisions are deliberate and evidenced.

NIST SP 800-82 Rev. 3

The OT security guide expects identification, authentication and access-control tailored to OT constraints, including handling of shared and local accounts and least-privilege design.

NIST SP 800-53 (AC and IA families)

The Access Control and Identification and Authentication control families define account management, least privilege, separation of duties, session controls and authenticator strength.

ISA/IEC 62443

Foundational requirements for identification and authentication control (IAC) and use control (UC) drive zone-by-zone account, role and privilege requirements across the IACS lifecycle.

MITRE ATT&CK for ICS

Maps adversary techniques such as use of valid accounts and remote services, helping teams justify which identity controls block which attacker behaviors.

• Deploying a PAM vault but leaving the most dangerous service-account passwords hard-coded in HMI projects and scripts.
• Enforcing MFA on the main remote-access path while a forgotten vendor VPN or modem offers an unauthenticated way in.
• Building a clean RBAC model on paper, then granting everyone broad rights because tightening it once caused an outage.
• Treating break-glass as routine, so emergency credentials become shared daily logins with no alerting.
• Centralizing directory accounts but ignoring local PLC, RTU and switch credentials that no one rotates.
• Forgetting that the IAM and PAM management plane is itself a privileged target that needs its own isolation and monitoring.

10Where exposure reduction and one-way transfer fit

IAM and PAM answer the question of who may act and what they may do. They do not, by themselves, remove the paths an attacker could use if they obtained a valid credential. That is where architectural controls — segmentation, scheduled disconnection and one-way transfer — complement identity rather than competing with it.

The principle is to reduce reachability so that fewer interactions ever need a privileged identity in the first place. If telemetry, logs, historian data and PAM session recordings leave the OT zone over a one-way path, an attacker who steals an operator's credential on the IT side still has no network route back through that channel into the control system. The strongest identity program shrinks standing privilege; the strongest architecture shrinks the standing pathways. Used together — alongside controls such as an AIRGAPNET controlled connectivity pattern for one-way export and time-based isolation — they cover what neither can cover alone.

Identity controls assume an attacker might present a valid credential. Exposure-reduction controls assume the path itself should not exist. A serious OT design plans for both at the same time.

11A practical roadmap and closing thought

OT identity work rewards sequencing over big-bang projects. Start by knowing what you have, secure the most dangerous credentials first, then extend control outward without ever blocking a safety function.

• Inventory every account — human, service, local and vendor — and assign each an owner.
• Vault and rotate the highest-privilege credentials, starting with administrative and remote-support access.
• Enforce phishing-resistant MFA on remote, jump-server and privileged paths into OT.
• Formalize the RBAC model and the joiner-mover-leaver and break-glass procedures.
• Reduce reachability with segmentation and one-way transfer so fewer paths ever require privileged access.

The end state is not a single product. It is a state in which every action against a control system is tied to an accountable identity, privilege is granted only when needed and recorded when used, and the network leaves attackers with as few paths as possible to exploit even a stolen credential. Identity tells you who knocked. Architecture decides whether there was a door at all.

FAQFrequently asked questions

SRCSources of record