What breaks when manufacturing access controls do not account for OT dependencies?

Why This Matters for Security Teams

Manufacturing access control fails when it is designed around office IT, while the real blast radius sits in OT, plant-support applications, maintenance tooling, and supplier connections. Attackers rarely need direct PLC access on day one. They often start with a service account, vendor tunnel, or API key and then move toward systems that coordinate production, quality, and downtime recovery. That is why NHI governance must cover identity reach across operational dependencies, not just user authentication inside the corporate boundary.

NHIM Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is especially relevant in manufacturing where integrators and OEMs often retain persistent access. In practice, many security teams discover OT exposure only after a supplier account or shared secret has already been used to touch production support systems, rather than through intentional identity design.

How It Works in Practice

The first step is to map identity dependencies across the full production chain. That means documenting which non-human identities can reach historians, MES platforms, remote maintenance portals, backup systems, patch tooling, file transfer gateways, and cloud services that feed plant operations. A useful control is to treat each of these as a distinct workload or service identity, not as an extension of a human admin account. The OWASP Non-Human Identity Top 10 is a strong reference for the failure modes that appear when secrets are long-lived, over-privileged, or poorly inventoried.

In manufacturing environments, the most effective controls are usually layered:

• Use short-lived credentials for vendor support and automation tasks, with automatic expiry after the approved maintenance window.
• Bind access to workload identity where possible, so the system proves what it is before it is allowed to act.
• Separate OT-facing secrets from corporate IT secrets, including different vaulting, rotation, and approval paths.
• Enforce step-up approval for actions that can affect uptime, safety, or production scheduling.
• Log identity-to-asset paths so incident responders can see which service account touched which line-support system.

This is not only about access removal. It is about ensuring that a supplier account used for firmware updates cannot later reach backup servers, remote desktop brokers, or engineering workstations that bridge into plant networks. The NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is explicit that excessive privilege and poor visibility are recurring causes of identity-driven exposure. These controls tend to break down when legacy OT protocols, shared vendor jump hosts, or always-on remote support channels cannot support modern identity enforcement.

Common Variations and Edge Cases

Tighter access control often increases operational friction, so organisations have to balance uptime and vendor responsiveness against reduced attack surface. That tradeoff is especially sharp in plants with older controllers, air-gapped segments, or maintenance windows that cannot tolerate frequent re-authentication.

Best practice is evolving for these environments. There is no universal standard for retrofitting identity-native controls into every OT asset, so many teams start with the highest-risk paths first: remote support, shared admin accounts, and third-party connectivity. NHI Mgmt Group has shown that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which helps explain why manufacturing teams should prioritise where a leaked credential would actually reach production.

Edge cases also appear when safety systems, plant engineering tools, and SaaS supply-chain services all depend on the same upstream identity. In those cases, security teams should not assume one control plane can manage everything. A practical approach is to set separate trust zones for IT, OT, and supplier access, then verify whether a given identity can traverse from one zone to another before production change windows begin.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• What breaks when access controls do not account for AI correlation risk?
• What breaks when service account permissions are over-provisioned?
• Who should own passkey recovery and fallback access controls?