Manufacturing’s IT/OT boundary becomes the auth-layer boundary.
The enterprise IAM stack ends at the OT firewall. Agentic systems on the plant floor will force the agent-identity category to land here first, before it lands in the carpeted-office stack.
Every enterprise has two identity worlds, separated by a single architectural fact: the OT firewall. Above the firewall, in the carpeted office, identity is mature. Entra ID, Okta, RBAC, MFA, SSO. Every action by every employee is authenticated, authorized, logged, and revocable. Below the firewall, on the plant floor, identity is primitive. Service accounts shared across shifts, vendor logins last rotated when the line was commissioned, PLC programming credentials in a sticky note on the controller. The two worlds have coexisted because the OT side did not connect to the network in any meaningful way.
That is changing. Agents that traverse the IT/OT boundary will force the agent-identity category to land at the boundary first, before it lands in the office stack. The reason is straightforward: the office-side auth gap is small (Microsoft Entra Agent ID solves it) and the plant-side auth gap is enormous, urgent, and unsolved. Whoever ships agent identity at the IT/OT boundary in the next 24 months captures the manufacturing operator base for the next decade. This piece argues why and what to do about it.
Why the boundary is the inflection point.
The OT side has no native identity primitives that can hold an agent.
Enterprise IAM evolved through three generations: directory services, federated identity, conditional access. None of those generations propagated below the OT firewall. The plant floor still runs on shared service accounts, hardcoded credentials in PLC firmware, and vendor-default passwords on devices commissioned in 2009. An agent that needs to read MES data, write to a controller, or coordinate with a supplier system has no native identity primitive on the OT side. Operators are currently solving this by putting the agent on the IT side and giving it broad service-account access through the firewall — which is precisely the over-scoped pattern that fails silently until it doesn’t.
The OT side has higher consequences for getting it wrong.
An over-scoped agent in the carpeted office writes a wrong email or pulls a wrong report. An over-scoped agent on the plant floor changes a setpoint, opens a relay, or reroutes a flow. The blast radius of an OT identity failure is physical, regulatory, and immediate. This raises the price of solving the problem and shortens the window before regulators move on it (NIS2 in EU, CIRCIA in US, IEC 62443). The OT side is structurally where agent identity becomes mandatory first.
Microsoft has a structural lead but not a complete answer at the boundary.
Microsoft Entra Agent ID solves the IT-side problem cleanly. Pushing it across the OT firewall requires partnership with the OT vendor base — Rockwell, Siemens, Aveva, Schneider, Honeywell — and that partnership is incomplete. The first vendor (Microsoft, OT incumbent, or independent) to ship credible IT/OT agent identity at the boundary captures a category nobody else is positioned to take. Operators should plan for that vendor to emerge in the 18–24 month window.
Operators cannot wait for the vendor to arrive.
The agentic deployments are happening now, with or without proper boundary identity. The operator who ships agents through the OT firewall on shared service accounts in 2026 has built technical debt that will cost an order of magnitude more to remediate when the proper layer arrives. The pragmatic move is to deploy agents only where the boundary identity question can be answered cleanly today — even if that constrains scope.
The strongest argument against this position.
The strongest counter is that the OT side will continue to use air-gap and segmentation patterns rather than native identity, and that agents will live entirely on the IT side reading replicated OT data. This is the conventional approach and it works for read-only use cases. It breaks the moment the agent needs to write — change a setpoint, dispatch a work order, reroute a flow. Read-only agents are a useful starting place but a low ceiling. The operator who treats read-only as the destination is building a smaller version of what bounded autonomy can do, and ceding the higher-value write-side workflows to whichever competitor solves the boundary identity problem first.
Three things to do this quarter.
01 · Audit which agentic pilots in your roadmap require write access across the IT/OT boundary. If any do, the boundary identity question is on your critical path, whether you have noticed or not.
02 · Engage Microsoft and your OT vendor base on agent identity at the boundary, jointly. Make it clear that this is a procurement criterion for the next OT refresh cycle. The vendors will move when the customer signal is loud enough.
03 · Until the boundary layer ships cleanly, constrain agent write access to OT systems to specifically scoped, audited, time-limited delegations. Treat every write as if the auditor will ask, “who specifically said this agent could change this setpoint?” — because eventually they will.