Why do traditional IAM controls struggle in smart factories?

Why Traditional IAM Struggles on the Factory Floor

Traditional IAM assumes predictable users, planned approvals, and access decisions that can wait for a ticket or manager sign-off. Smart factories do not work that way. Robotic cells, PLCs, MES platforms, vendor maintenance tools, and IIoT services exchange credentials at machine speed, often across safety-critical and time-sensitive workflows. That creates a mismatch between office-style governance and operational reality.

The core problem is not just volume, but identity shape. Non-human identities outnumber human identities by 25x to 50x in modern enterprises, yet only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs — Standards. When teams cannot see what is active, they cannot reliably decide what is allowed. The result is policy drift: entitlements remain in place long after a line changes, a supplier leaves, or a machine is repurposed.

Current guidance from NIST Cybersecurity Framework 2.0 still applies, but factories require it to be operationalised around workload identity, not just user accounts. In practice, many security teams encounter excessive access only after a vendor remote session, production outage, or secrets leak has already exposed the gap.

How Identity and Access Decisions Need to Work in Practice

Smart factories need identity controls that can keep pace with autonomous systems, short-lived processes, and tightly coupled OT dependencies. That means replacing static standing access with JIT credential provisioning, enforcing ZSP where possible, and tying each action to workload identity rather than a shared account. In practical terms, a machine or service should prove what it is, receive only the access needed for the current task, and lose that access automatically when the task ends.

This is where RBAC alone usually falls short. RBAC is useful for coarse grouping, but it cannot express intent-based authorisation well enough for dynamic industrial workflows. A packaging robot might need write access to one API during commissioning, read-only access during normal operation, and no access during maintenance lockout. That decision is better made at request time using policy-as-code, not by permanently assigning a broad role. Emerging practice also favours ephemeral secrets over long-lived static credentials because TTL matters differently when workloads operate continuously and can chain actions faster than a human can intervene.

NHIMG research shows why this matters operationally: 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks. Those conditions are especially dangerous in factories because a leaked token can be reused by vendor tools, scripts, or connected edge devices with very little friction. See Azure Key Vault privilege escalation exposure for a concrete example of how privilege paths can expand when secrets governance is too permissive.

• Use workload identity primitives such as SPIFFE or OIDC tokens for cryptographic proof of the workload, not the operator.
• Issue JIT credentials per task and revoke them automatically when the job completes or the process is interrupted.
• Evaluate policy at request time so vendor sessions, service-to-service calls, and machine actions are judged with full context.
• Prefer short-lived secrets with rotation and revocation workflows that work even when OT systems are intermittently connected.

These controls tend to break down when legacy OT systems require persistent service accounts and cannot tolerate frequent token exchange because the environment was never designed for dynamic credentialing.

Where the Standard Answer Breaks Down in Real Plants

Tighter identity control often increases operational overhead, so organisations have to balance safety, uptime, and auditability against complexity. That tradeoff is real in brownfield plants, where equipment vendors may insist on fixed credentials, air-gapped segments, or maintenance windows that make JIT harder to implement.

There is no universal standard for every OT edge case yet. Best practice is evolving toward Zero Trust Architecture, but factories often need phased adoption: start with vendor access, service accounts, and secrets management, then expand to machine identities and inter-cell workflows. NIST Cybersecurity Framework 2.0 helps structure that journey, while Ultimate Guide to NHIs — Standards provides the NHI-specific governance lens.

Another common edge case is shared tooling across IT and OT. A single CI/CD pipeline, historian connector, or remote support agent may cross trust boundaries and inherit permissions that were never intended for production control. In those environments, the practical fix is to separate identities by function, constrain blast radius with least privilege, and treat secrets exposure as an incident response issue, not just an IAM cleanup task.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• When should organizations review access controls?
• Why do traditional IAM and IGA tools struggle with NHIs?