Independent analysis by NHI Mgmt GroupSource article: Imprivata, “SCADA security: Best practices for evolving your manufacturing technology” (March 10, 2026)

TL;DR: SCADA systems now connect HMIs, PLCs, RTUs, enterprise platforms, and vendor remote access, which expands attack surface and makes identity governance central to manufacturing cybersecurity, according to Imprivata and IDC. Legacy OT assets and shared access practices turn connectivity into operational risk; isolation is no longer a sufficient control model.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on Imprivata's blog post: SCADA security has shifted from network isolation to identity-driven control because connected manufacturing environments now span HMIs, PLCs, RTUs, remote vendors, and enterprise systems.

Why it matters: It matters because IAM, PAM, and OT security teams now need to govern access paths that directly affect production, safety, and recovery, not just logons to IT systems.


Context

SCADA, or Supervisory Control and Data Acquisition, is the control layer that operators use to monitor and manage industrial processes in real time. In this article, the key problem is not SCADA itself but the governance gap created when once-isolated OT environments become connected to enterprise systems and remote access paths.

The article’s central claim is that manufacturing security can no longer rely on network separation alone. As SCADA environments connect HMIs, PLCs, RTUs, analytics platforms, and vendor access channels, identity becomes the control plane that determines who can reach production systems and how much damage they can do if access is misused.


Key questions

Q: What breaks when SCADA systems still rely on shared operator accounts?

A: Shared operator accounts break accountability, make forensic analysis harder, and turn access review into guesswork because no single person is tied to the action. In SCADA, that is especially dangerous because one command can affect machinery, production output, or safety. Identity governance only works when each operator has a unique, revocable credential tied to a defined role.

Q: Why does persistent vendor access increase SCADA risk?

A: Persistent vendor access creates a standing trust path into production systems, which means a maintenance account can outlive the job it was created for. That increases the chance of overprivilege, session misuse, and delayed revocation. In OT environments, the problem is not remote support itself but the absence of time-bound lifecycle control for delegated access.

Q: How should manufacturers govern identity across IT and OT environments?

A: Manufacturers should use one identity governance model across IT and OT, but enforce it through SCADA-specific controls such as unique user identities, role scoping, monitored vendor sessions, and controlled gateways for legacy devices. The key is to keep the access model consistent while adapting enforcement to systems that cannot support modern features internally.

Q: When do network segmentation and identity controls work best together in SCADA?

A: They work best when segmentation limits where access can reach and identity controls determine who may use the path. Segmentation without strong authentication still leaves a broad trust problem, while identity without segmentation can leave too much lateral movement once access is granted. The two controls are complementary, not interchangeable.


Technical breakdown

Why shared SCADA access breaks accountability

SCADA environments often still rely on shared accounts, especially on HMI stations used by operators and engineers. That model hides who performed an action, weakens incident attribution, and makes revocation almost impossible when someone changes role or leaves. In practice, a shared login is not just a convenience gap. It is an identity design flaw that removes traceability from systems where every command can affect physical operations. Role-based access only works when identities are unique and permissions are tied to a real person or governed service, not a common credential. The same logic applies to vendor access: if multiple outsiders use one account, you lose both accountability and control.

Practical implication: replace shared operator logins with individual identities and enforce per-user accountability on every SCADA access path.

How vendor remote access expands the SCADA attack surface

Vendor remote access is often kept permanently enabled so maintenance can happen quickly, but persistent connectivity creates an always-on trust path into production networks. Once a vendor session exists, it can become overprivileged, poorly monitored, or reused across jobs, which turns convenience into standing exposure. The issue is not remote access itself. It is unmanaged delegated access across environments that were not designed for continuous external connectivity. In SCADA, that can expose HMI control paths, PLC management interfaces, and RTU data channels. This is where PAM and time-bound access matter most, because the trust relationship should exist only for the duration of the task and under supervision.

Practical implication: time-box vendor access, record sessions, and remove standing remote paths into SCADA environments.

Why legacy PLCs and RTUs make modern authentication harder

Many PLCs and RTUs were engineered before modern authentication was a design requirement, so they may not support MFA, strong credential lifecycle controls, or granular authorisation. That means teams cannot simply import IT identity patterns and expect them to work unchanged. Instead, the control challenge becomes one of compensating governance: centralising access where possible, limiting blast radius, and isolating legacy devices behind controlled gateways. Security teams should treat these assets as identity-constrained endpoints that must be wrapped by stronger controls rather than directly exposed. The architectural lesson is that legacy OT often forces a layered model, not a perfect one.

Practical implication: place legacy OT assets behind controlled access layers instead of exposing PLCs and RTUs directly to broad network trust.


Threat narrative

Attacker objective: The attacker aims to disrupt production or alter industrial process behaviour by reaching control systems with enough access to change machine operation.

  1. Entry typically begins through connected enterprise systems, remote maintenance platforms, or reused SCADA credentials rather than through the industrial device itself.
  2. Escalation happens when shared HMI accounts, persistent vendor access, or weak segmentation let an attacker move from one control surface to another inside the OT environment.
  3. Impact follows when PLCs, RTUs, or HMI displays are manipulated, creating production disruption, equipment damage, safety risk, or environmental consequences.
  • Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Identity is now the SCADA control plane: once OT systems connect to enterprise platforms and remote vendors, isolation stops being the primary security boundary. The real question becomes who can authenticate into HMI, PLC, and RTU workflows, under what role, and for how long. Manufacturers that still think of SCADA security as a network-segmentation problem are governing the wrong layer. The implication is that production resilience now depends on access governance, not perimeter assumptions.

Shared operator access is a governance failure, not just an inconvenience: shared HMI credentials remove attribution, complicate recovery, and make privilege reviews meaningless because no individual identity is being governed. This is a direct conflict with NIST-CSF access authorization expectations and with every lifecycle process that depends on knowing who holds what access. The field should stop treating shared logins as a legacy habit and start treating them as an accountability defect. Practitioners need individual identity per operator task.

Persistent vendor access creates identity debt in OT environments: vendor sessions that remain enabled after the maintenance window outlive the business need that justified them. That is a form of delegated access without lifecycle offboarding, and it is one of the clearest ways SCADA environments accumulate hidden risk. The issue is not remote support itself but the absence of a governed expiration point for access that touches production. Practitioners should assume every standing vendor path increases blast radius until it is time-boxed and supervised.

Legacy PLC and RTU constraints force compensating controls around the device, not inside it: many industrial assets cannot enforce modern authentication, so the governance model has to shift outward to gateways, monitored jump points, and strict role scoping. This is where manufacturing security diverges from standard IT IAM. The sector needs to recognise that some OT identities can only be controlled indirectly, which makes lifecycle discipline and access containment the real enforcement mechanism.

SCADA access containment: the useful concept here is not generic zero trust but the narrower idea of keeping industrial access paths short, visible, and revocable. That means treating every identity into production as a temporary operating condition, not a default entitlement. Teams that cannot see, scope, and revoke access at the point of use are not governing SCADA identity at all. The implication is straightforward: control should follow the production task, not the network zone.

What this signals

SCADA cybersecurity is becoming an identity governance problem: as manufacturing environments connect to enterprise systems and remote vendors, the old assumption that isolation can carry the security model no longer holds. The practical shift is toward access governance at the point of use, because the blast radius of a compromised identity now reaches production systems.

SCADA access control needs to be lifecycle-managed, not just configured: unique identities, role-based permissions, time-bound vendor sessions, and revocation when the task ends are now operational requirements. Teams that leave standing access in place are not just increasing exposure, they are building hidden operational debt into the plant’s control environment.


For practitioners

  • Replace shared HMI logins Give each operator and engineer an individual identity, then map roles to only the SCADA functions required for that job. Shared credentials should be removed because they erase attribution and slow incident investigation.
  • Time-box vendor remote access Approve vendor sessions only for the maintenance window, require session recording, and revoke access immediately after the task ends. Persistent remote paths should not remain open between service events.
  • Wrap legacy PLC and RTU access Place older PLCs and RTUs behind controlled gateways or jump hosts so modern authentication and monitoring can be enforced outside the device. Do not expose legacy OT endpoints directly to broad trust zones.
  • Align SCADA access reviews with production roles Review who can reach HMIs, PLCs, RTUs, and centralized SCADA software against current operational duties, not historic assignments. Revoke any access that no longer maps to an active production responsibility.

Key takeaways

  • SCADA environments now depend on governed identity paths because shared access and persistent vendor connections undermine accountability and increase production risk.
  • The main exposure is not abstract IT compromise but the ability to reach HMIs, PLCs, and RTUs with more privilege than the task requires.
  • Manufacturers should treat access lifecycle, session oversight, and device containment as the controls that make modernization possible without losing operational control.

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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-05 — Overprivileged NHIPersistent vendor access and shared accounts create overprivileged machine and service access patterns in SCADA.
NHI-01 — Improper OffboardingThe article stresses revoking access when vendor or operator need ends, which is a lifecycle failure mode.
Recommendation — Reduce SCADA blast radius by removing standing overprivileged access paths for non-human identities and vendors. Offboard SCADA access promptly when roles change or maintenance ends so credentials do not outlive the task.
CIS Controls v8CIS-5 — Account ManagementUnique accounts, role scoping, and revocation are core to the article's identity control argument.
Recommendation — Apply account management controls to eliminate shared credentials and enforce individual SCADA identities.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article centers on governing who can access SCADA systems and what they are allowed to do.
Recommendation — Review SCADA permissions against active duties and remove entitlements that no longer match operational need.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe article describes credential misuse and movement across connected SCADA environments as core threat paths.
Recommendation — Hunt for reused credentials and constrain lateral movement paths from enterprise IT into OT control systems.

Key terms

  • SCADA: Supervisory Control and Data Acquisition systems collect operational data and let operators control industrial processes in real time. In connected environments, SCADA is no longer just control software. It becomes an identity and access surface where credentials, remote sessions, and network paths can affect physical production.
  • Human-Machine Interface: A Human-Machine Interface is the screen or console operators use to observe and control industrial systems. In SCADA, the HMI is often the first identity checkpoint for production actions, which makes shared accounts, weak authentication, and poor logging especially dangerous for accountability.
  • Programmable Logic Controller: A Programmable Logic Controller is an industrial device that executes control logic for machinery and processes. PLCs are often trusted to run continuously, so unauthorized access can alter physical behaviour quickly. In modern SCADA governance, PLC access must be tightly scoped and traceable.
  • Vendor Remote Access Session: A vendor remote access session is a live connection that allows a third party to reach internal systems from outside the organization. These sessions must be tracked, differentiated from internal access, and disabled when no longer needed, because unmanaged remote access creates a direct path into critical infrastructure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org