Security teams should govern SCADA access as a single identity problem across operators, engineers, vendors, and connected systems. That means unique credentials, role-based access, monitored sessions, and strict revocation when access is no longer required. If access is still shared or persistent, the programme cannot prove accountability or contain lateral movement effectively.
Why This Matters for Security Teams
SCADA access is not just an IT access-review problem. It spans operators, maintenance engineers, integrators, OEM vendors, remote support channels, and machine-to-machine service accounts that bridge OT and enterprise networks. If those identities are shared, persistent, or impossible to trace, security teams lose accountability and create a path for lateral movement from IT into safety-critical environments. That is why NHI governance, not just user access control, has to frame the programme, as reflected in the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
The practical risk is amplified by the scale of over-privilege in identity estates. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which is directly relevant when a single SCADA support account can reach multiple PLCs, historians, or engineering workstations. In SCADA environments, that overreach is rarely caught by perimeter tools alone. In practice, many security teams encounter SCADA identity exposure only after a vendor session, a maintenance exception, or an incident review has already exposed the gap.
How It Works in Practice
Governing SCADA access well means treating every path into OT as a distinct identity, session, and privilege decision. Start by inventorying all human and non-human identities that can touch the environment, then classify them by function: operator, engineer, vendor, emergency support, service account, and integration account. From there, enforce RBAC where roles are stable, but use JIT access and time-bound approvals for anything elevated or infrequent. For remote vendor access, current guidance suggests pairing PAM with session recording, command filtering, and explicit ticket linkage so access can be traced to a maintenance event.
Workload identity matters as much as user identity for integrations that poll historians, write alarms, or move data between zones. Secrets should be short-lived and rotated, not embedded in scripts or left in shared vault paths. That aligns with the identity-risk patterns described in the Top 10 NHI Issues and the OWASP guidance in OWASP Non-Human Identity Top 10.
- Give each operator, vendor, and service account a unique identity.
- Use PAM plus JIT for privileged OT sessions, not standing access.
- Record and review all remote access into SCADA zones.
- Rotate secrets and revoke them automatically when a task ends.
- Apply least privilege across both IT jump hosts and OT endpoints.
Where environments depend on always-on vendor tunnels, legacy HMI software, or shared engineering workstations, these controls tend to break down because the technical stack was never designed for per-session identity enforcement.
Common Variations and Edge Cases
Tighter SCADA access often increases operational overhead, requiring organisations to balance safety and availability against speed of response. That tradeoff is real in plants with 24/7 operations, patch windows measured in hours, or vendors who can only support older controllers through fixed tools. In those cases, best practice is evolving rather than universal: some environments can enforce JIT and session approval everywhere, while others need compensating controls such as brokered access, break-glass procedures, and stronger monitoring at zone boundaries.
Legacy OT is the biggest exception. Older PLCs, historians, and engineering packages may not support modern identity federation or short-lived secrets, so teams often need a wrapper pattern: authenticate the person or workload outside the device, then mediate access through a jump host or secure remote access gateway. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here, because revocation and offboarding are where many SCADA programmes fail. For audit and governance expectations, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps translate identity control into evidence.
The edge case to watch is third-party support that mixes human and machine access in one account or one tunnel. That pattern hides accountability and makes incident containment much harder, especially when a maintenance vendor reuses credentials across multiple sites.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | SCADA accounts need rotation and revocation discipline to avoid standing access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to separating IT and OT SCADA pathways. |
| NIST Zero Trust (SP 800-207) | Zero trust supports continuous verification across IT and OT boundaries. |
Map every SCADA role and service account to least-privilege entitlements and review them regularly.
Related resources from NHI Mgmt Group
- How should security teams govern app identity modernization across multi-cloud environments?
- How should security teams govern access on shared devices in manufacturing environments?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern non-human identities in cloud environments?
