Why do third-party identities create so much risk in industrial environments?

Why This Matters for Security Teams

Third-party identities are risky in industrial environments because they often sit at the boundary between OT availability and enterprise IT convenience. A vendor account that exists for maintenance, telemetry, or remote support can end up touching controllers, HMIs, file shares, and cloud portals with far more reach than an internal user would normally get. The result is not just access sprawl, but a harder problem: access that persists long after the original job is complete. NHI Management Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which makes supplier access a structural risk rather than an edge case.

That matters because industrial environments rarely tolerate broad privilege reviews at the same pace as enterprise IT. The NIST Cybersecurity Framework 2.0 emphasises governance, access control, and continuous oversight, but third-party identities often bypass all three when support is urgent. In practice, many security teams discover the exposure only after a remote support path, shared credential, or stale service account has already been used as the easiest route into production systems.

How It Works in Practice

Third-party identities create risk when the access model is designed for speed instead of containment. A contractor may need a temporary VPN, a vendor may receive a service account for patching, and an integrator may be granted access through a shared jump host. Each step can be defensible on its own, but together they create a path that is difficult to inventory, difficult to monitor, and often too permissive for the actual task.

Current guidance suggests treating these identities as high-risk assets and managing them with the same discipline used for privileged infrastructure access. The practical controls usually include:

• Unique identities for each vendor, partner, or system integration, never shared logins.
• Just-in-time access with short TTLs, so privileges expire when the work window closes.
• Strong authentication tied to workload or person, depending on whether the identity is human or machine.
• Session recording and command-level logging for remote support paths.
• Periodic attestation by both the asset owner and the business sponsor.

Industrial teams also need to distinguish between authentication and authorisation. A third party may authenticate successfully but still require context-aware checks before touching safety-related systems, changing firmware, or exporting process data. The OWASP Non-Human Identity Top 10 is useful here because it frames excessive privilege, missing rotation, and weak lifecycle controls as recurring failure modes rather than isolated exceptions.

Real-world incidents often start with legitimate maintenance access and then expand through reused credentials, forgotten accounts, or exposed secrets in support tooling. NHIMG’s 52 NHI Breaches Analysis shows how quickly identity sprawl becomes a breach pathway when governance lags behind operational need. These controls tend to break down when suppliers insist on persistent access to legacy OT assets because the environment lacks modern federation, granular logging, or safe alternatives.

Common Variations and Edge Cases

Tighter third-party controls often increase operational overhead, so organisations have to balance resilience against maintenance urgency. That tradeoff becomes especially visible in plants that rely on OEM support, where restricting access too aggressively can slow recovery from outages or increase downtime risk.

Not every third-party identity should be handled the same way. A vendor technician logging into a workstation is not the same as a machine-to-machine integration pulling telemetry, and a cloud-based service account used for predictive maintenance is not the same as a contractor’s remote support session. Best practice is evolving toward separate governance for human, machine, and service identities, but there is no universal standard for this yet. The safest approach is to apply least privilege, explicit ownership, and time-bound access to every case, then raise the bar further for systems connected to safety or production control.

Industrial environments also need strong offboarding discipline. A vendor relationship may end while the account remains active, or a temporary emergency access path may never be removed. The Top 10 NHI Issues and the NIST SP 800-63 Digital Identity Guidelines both reinforce a simple operational rule: identity proofing and lifecycle management matter as much as the initial grant of access. For plants with remote support dependencies, the weakest point is usually not the login itself but the forgotten exception that remains valid months later.

Related resources from NHI Mgmt Group

• Why do third-party identities create disproportionate risk in modern access environments?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why do third-party vendors create so much identity risk?