Persistent vendor access breaks accountability, least privilege, and containment. A remote session that stays open beyond the maintenance task creates an unnecessary pathway into production systems, often with more privilege than the task needs. That makes it harder to trace activity, harder to revoke access cleanly, and easier for compromise to spread.
Why This Matters for Security Teams
Persistent SCADA vendor access is not just an inconvenience, it is a structural control failure. Industrial environments already depend on tightly timed maintenance windows, segmented networks, and highly privileged accounts, so a session that stays open after work is finished becomes an enduring attack path. The problem is especially acute for third parties because their access often sits outside normal joiner-mover-leaver processes and can escape routine review. NHI governance guidance from the Ultimate Guide to NHIs stresses that long-lived access and poor offboarding are among the most common causes of identity risk, and the OWASP Non-Human Identity Top 10 treats unmanaged non-human access as a core exposure class rather than an edge case. In practice, many security teams discover the issue only after a plant outage, vendor dispute, or forensic review reveals that the access was never truly closed.
How It Works in Practice
The control objective is simple: vendor access should exist only for the task, only for the minimum scope, and only for the minimum time. That means using just-in-time credential issuance, session approval, and automatic revocation when the maintenance job is complete. Current guidance suggests combining PAM, RBAC, and Zero Trust controls so that a vendor’s identity is verified, the request is checked at runtime, and the session is constrained to specific assets rather than broad network reach. For high-risk industrial access, this is often stronger when paired with ZSP, because standing privilege is what turns a routine support session into a persistent foothold.
Operationally, teams should expect three layers of control:
- Pre-approval for the maintenance window, asset list, and command scope.
- Time-bound access with continuous logging, command recording, and session termination rules.
- Post-task revocation plus secret rotation if any credential, token, or certificate was exposed.
The NHI perspective matters here because vendor accounts, service accounts, and remote tool credentials behave like non-human identities even when they are used by people. NHI program guidance from the 52 NHI Breaches Analysis and the broader Ultimate Guide to NHIs — Key Challenges and Risks both show that excessive privilege and weak visibility are what turn temporary access into a breach vector. These controls tend to break down when vendors use shared jump hosts or always-on remote support channels because individual accountability and session-level revocation become unreliable.
Common Variations and Edge Cases
Tighter access controls often increase operational friction, so organisations have to balance uptime against the risk of keeping a vendor session alive longer than necessary. In some plants, emergency support arrangements are unavoidable, and there is no universal standard for every outage scenario yet. Best practice is evolving toward break-glass access with explicit expiry, stronger monitoring, and documented post-incident review rather than permanent exceptions. The same logic applies when multiple vendors support the same platform: shared credentials and broad group memberships make it difficult to prove who did what, so intent-based authorisation becomes more useful than static permission sets.
One important edge case is remote troubleshooting during after-hours incidents. If the team cannot predefine the exact commands or assets, it should still issue the shortest possible access window and force re-authentication before any escalation. Another is legacy SCADA equipment that cannot support modern session controls. In those environments, compensating controls such as network isolation, jump server mediation, command whitelisting, and out-of-band logging become essential, but they remain weaker than true JIT access. The OWASP Non-Human Identity Top 10 and Ultimate Guide to NHIs both reinforce the same operational lesson: if access cannot be cleanly time-boxed and revoked, it should be treated as standing privilege, not temporary support.
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 | Standing vendor access is a rotation and revocation failure. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access governance map directly to vendor sessions. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of every vendor session. |
Limit vendor rights to task scope and review them after every maintenance window.
