Access Control & Identity Management in OT

Ask an IT security team how they manage identity, and the answer usually runs through a single directory: one account per person, multi-factor authentication (MFA) everywhere, automatic disablement the moment HR marks someone terminated. Ask an OT team the same question, and the honest answer is messier — and the mess is not incompetence. It is the predictable result of building identity controls for equipment that was never designed to have any.

This lesson is an SME-level walkthrough of why identity and access management (IAM) is genuinely harder in an industrial control system (ICS) than in a typical office network, and what a defensible OT identity program does about it anyway. Before we get to roles, privileged access, or MFA, it's worth naming the constraints up front, because every technique in this lesson exists specifically to work around one of them:

• Shared, generic logins are common at the operator level. A control room HMI often stays logged into one "Operator" session across an entire shift rotation, because logging out mid-shift risks missing an alarm.
• Many field devices have no concept of a user at all. A PLC's engineering port frequently supports a single shared password — or nothing — not per-person accounts, so "who has access" and "who logged in" can be two different questions.
• Vendors need real, but temporary, access. A relay or drive vendor may need hands-on control of a live device for a two-hour troubleshooting call, then never again — a pattern IT identity systems, built around long-lived employee accounts, don't handle gracefully by default.
• You cannot lock someone out during a safety event. A control that would be reasonable on a laptop — session timeout, forced re-authentication, account lockout after failed attempts — can itself become the hazard if it fires while an operator is responding to an alarm.
• Equipment outlives identity systems. A relay or RTU commissioned in 2008 may still be in service in 2030, long after the vendor's original authentication scheme (if any) is obsolete, while the plant's IT directory has been replaced two or three times over.
• Deprovisioning lags. Disabling someone's corporate Active Directory account does nothing to a local account on an isolated engineering workstation that was never synchronized to that directory in the first place.

Learning objectives

By the end of this 4-hour session, you will be able to:

1. Explain why identity and access management in an ICS/OT environment differs from a typical IT environment, citing at least two OT-specific constraints.
2. Identify appropriate operator, engineer, and vendor roles and apply role-based access control (RBAC) to a described plant network.
3. Evaluate the shared-console problem and propose a compensating control that restores individual accountability without disrupting continuous operations.
4. Configure, in simulation, a least-privilege access request that matches a privileged access management (PAM) and jump-host architecture for a remote vendor session.
5. Evaluate where multi-factor authentication is appropriate on a control network and where it introduces unacceptable operational risk.
6. Design a provisioning-to-deprovisioning identity lifecycle checklist that closes the OT deprovisioning gaps discussed in this lesson.

Role-based access control (RBAC) assigns permissions to a named role — Operator, Controls Engineer, Vendor Support Technician — rather than to each person individually, so that everyone who fills that role inherits the same, pre-approved permission set. The companion principle, least privilege, says that whatever role a person is assigned, the actual permissions granted should be the minimum needed to do that specific job — not the minimum for the role in the abstract, and not "whatever's convenient to provision." RBAC answers which permission set does this job need; least privilege answers has this person actually been given more than that. The two work together, but they are not the same question, and a defensible OT access program checks both.

In a plant, three broad role families cover most accounts, and each has a different natural ceiling on what it should be able to do:

• Operators — view process data, acknowledge alarms, and change setpoints within a pre-approved safe range from an HMI. They should not be able to modify PLC logic, change alarm thresholds outside policy, or reach the engineering network.
• Controls engineers — configure and modify PLC/RTU logic, tune loops, and manage firmware, typically scoped to the specific line, unit, or system they are responsible for — not the whole plant by default.
• Vendors / support technicians — need deep, sometimes privileged access to a specific device for a specific, time-limited reason, and almost never need standing access at all.

Worked example — role matrix, Ironwood Precision Manufacturing

Ironwood Precision Manufacturing (fictional) runs a CNC machining line with a small PLC-based SCADA system. Its identity team maintains one role matrix that both the plant and IT security refer to when provisioning any new account:

Notice that the Vendor Tech column is never "No" across the board and never "Yes" without a qualifier — vendor accounts are the row where least privilege has to be enforced hardest, because a vendor's business relationship with the plant, unlike an employee's, has no natural deprovisioning trigger like an exit interview.

Four terms, one toolkit

The rest of this lesson builds out four techniques faculty often blur together. Each answers a different question:

Each card is a button: press Enter or Space to flip it. All four definitions also print in full.

Walk into almost any control room and you'll find at least one HMI station logged into a single, generic operator session that has been open for months. This is the shared console problem: an OS or application session shared across an entire shift rotation, so that whatever any operator does — acknowledge an alarm, change a setpoint, silence a horn — is attributed to "Operator," not to a specific person. From a pure IT standpoint this looks like a glaring control gap. From an operations standpoint, it is often a deliberate, defensible choice: logging out to switch users mid-shift risks a missed alarm during the seconds the screen is unavailable, and some HMI software doesn't support fast user-switching at all.

The wrong fix is to treat this as a simple policy violation to be stamped out — "just require individual logins" ignores the real operational constraint that created the shared session in the first place. The right fix preserves the always-available session while restoring individual accountability through a layer on top of it.

Worked example — Cascade Summit Electric, Substation 12 control room

At Cascade Summit Electric (fictional), the SCADA HMI at Substation 12 stays logged into a shared Windows session called SUB12-OPR across all three shifts, because the HMI application does not support fast user-switching without a full restart. The identity team's compensating design:

• The Windows OS session stays shared, as operations requires — but every operator badges in with an RFID proximity card at station start, which sets an "active operator" flag inside the SCADA application itself.
• Every alarm acknowledgment, setpoint change, and override is timestamped and tagged with the currently active operator's name at the application layer, independent of the shared OS login.
• If no badge tap has occurred in the current shift window, the application flags every action in that period as unattributed — a finding, not a silent gap.
• The shared account's password is still rotated and known only to the identity team, and it is never used to log into anything else, so a compromised shared credential can't be replayed against the engineering network.

Two failure modes to watch for when reviewing a shared-console design: first, a paper sign-in sheet at the console is not a substitute for either fix — it isn't enforced, isn't tamper-evident, and nobody checks it until after an incident. Second, rotating the shared password on a schedule improves hygiene but does nothing for accountability — it doesn't tell you who did what, only that the same password isn't stale.

Privileged access management (PAM) is the practice of brokering high-privilege credentials — engineering-level logins, PLC programming access, firewall admin — through a system that checks credentials out for a defined purpose and window, records what happens during the session, and revokes access automatically when the window closes. PAM exists because standing privileged accounts are exactly the accounts an attacker or a careless insider does the most damage with, and a plant's most privileged accounts are often the ones handed out most casually — to whichever vendor called last.

A jump host (also called a bastion host) is the single, hardened, closely monitored server that all remote sessions into the OT environment must pass through — never a direct path from the outside world to a PLC or HMI. A jump host does not, by itself, grant any privilege; it is the choke point where identity, PAM, and logging all converge before a session is allowed to continue inward.

Remote access in an OT context refers narrowly to any session that originates outside the control network's trust boundary — a vendor connecting from their own office, an engineer working from home, corporate IT reaching into a plant historian. Every remote access path should terminate at a jump host, never inside the control zone itself.

Worked example — a vendor troubleshooting call at Ironwood

A protective relay at Ironwood Precision Manufacturing throws an intermittent fault code. The relay vendor's support engineer needs hands-on access to the device's configuration software to diagnose it. The session that follows:

1. The plant's controls engineer opens a scheduled access request in the PAM system: specific device, specific two-hour window, specific vendor account.
2. The vendor authenticates to the jump host in the OT DMZ from their own network, over an approved remote-access gateway, with MFA required at this step.
3. The PAM broker checks out a scoped credential for the target relay's configuration port — the vendor never sees or types the actual device password.
4. The session is screen-recorded and keystroke-logged for the full two hours, viewable later by the controls engineer if needed.
5. At the end of the two-hour window, the PAM broker automatically revokes the checked-out credential and terminates the session, whether or not the vendor is finished.
6. No standing VPN account, no long-lived password, and no direct route from the vendor's laptop to the relay ever existed.

Multi-factor authentication (MFA) requires two or more independent proofs of identity — something you know (a password), something you have (a token or authenticator app), or something you are (biometrics) — before granting access. In IT, the guidance is close to "use it everywhere you can." In OT, that advice can be actively dangerous if applied without thinking about where the authentication event actually happens.

The deciding question is not "is this device important?" — everything in a control system is important. The deciding question is: does adding a second authentication factor introduce a delay or a failure mode that is worse than the risk it mitigates, at this specific point in the network? A general-purpose gateway with a keyboard and time to spare is a good MFA candidate. A touchscreen an operator is stabbing at mid-alarm is not.

Worked example — MFA placement at Cascade Summit Electric

Where a device genuinely cannot support MFA — most Level 0/1 field equipment — the compensating control isn't "skip authentication," it's pushing the strong authentication requirement upstream to the nearest point that can enforce it: the jump host or engineering workstation gating access to that device. This is the same logic as Section 3's PAM broker — the control lives where it can actually be enforced without breaking the physical process.

Provisioning is the process of creating an account and granting it a role's permissions, gated on the prerequisites being genuinely met — background check, safety training, a signed access request — before the account exists, not after. Deprovisioning is the reverse: disabling or removing access when it's no longer justified, whether because of termination, role change, or a vendor's contract ending. In a well-run IT environment, both halves run through one directory and largely take care of themselves. In OT, provisioning tends to get real attention because it's tied to a visible event (a new hire's first day); deprovisioning is where programs quietly fail, because OT accounts often live outside the systems that trigger deprovisioning in the first place.

Worked example — a new controls engineer at Ironwood, hire to termination

Vendor accounts deserve their own lifecycle note: because a vendor relationship has no exit interview, the trigger for deprovisioning has to be contractual and calendar-based — a defined contract end date, a PAM session that expires automatically (Section 3), and a periodic vendor-account audit — rather than waiting on an event that will never come from the vendor's side.

The fields both worlds need are identical — a role, a least-privilege scope, an authentication method, an expiration trigger. What differs is which of those fields a plant can fill in automatically versus which one requires a person to remember to check, because the underlying device was never built to report its own account state to anyone.

⚠ Simulation only — no real accounts, no live directory, no actual credentials are created or transmitted.

This builder models a single access request against the fictional Cascade Summit Electric, Substation 12 network. Choose a requestor role, the network zone the account needs to reach, how long the access should last, the authentication method, and the privilege level requested. Select Provision account and the tool will evaluate the combination the way an identity reviewer would — flagging least-privilege violations, MFA placed where it doesn't belong (or missing where it should be required), and access durations that don't match the requestor's role. Provision a few different combinations, including at least one you expect to be flagged, and compare the reasoning in the results panel.

A remote vendor access policy is the short document that answers, before the phone rings, exactly how a vendor gets in, what they can touch, and how the access ends. Without one, every vendor request gets negotiated from scratch under time pressure — usually while a line is down and nobody wants to be the person who says no.

Standards, guidance, and video