Which frameworks should teams align to when AI identities touch OT systems?

Why This Matters for Security Teams

When AI identities touch OT systems, the risk is not just access control drift. It is the possibility that an autonomous or semi-autonomous workload can issue commands, chain tools, or trigger processes faster than human review can contain. That shifts the question from “who is the user?” to “what is the workload allowed to do, right now, in this context?” NIST Cybersecurity Framework 2.0 remains the clearest baseline for organising that question across governance, asset visibility, and response, while OT-specific identity controls must be tighter at the point of action.

In practice, this is where many programmes discover that identity assurance and operational safety are inseparable. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames the compliance pressure, while the NIST Cybersecurity Framework 2.0 provides the governance language teams can map to OT. The practical challenge is that AI identities often sit between IT and OT tooling, so their privileges must be measurable, time-bound, and attributable without disrupting plant operations. In practice, many security teams encounter unsafe AI-to-OT access only after a workflow has already been allowed to execute once.

How It Works in Practice

For OT environments, the most defensible approach is to align AI identities to three layers: governance, trust, and runtime enforcement. Governance defines ownership and acceptable use. Trust establishes the AI identity as a workload, not a person, using cryptographic identity and short-lived credentials. Runtime enforcement decides whether a specific action is allowed at the moment it is requested. That is why ZTA principles matter here, but they need to be applied with OT constraints in mind, not copied from enterprise IT.

A workable operating model usually includes:

• Workload identity for the agent, so the system can prove what is acting, not just where it came from.

• Just-in-time access for narrow OT tasks, with short TTLs and automatic revocation after completion.

• Policy-as-code at decision time, so authorization can factor in asset criticality, command type, maintenance window, and operator approval.

• Immutable logging that records identity, intent, target asset, and outcome for audit and incident response.

That approach maps well to the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, especially where issuance, rotation, and retirement need to be provable. It also aligns with OT reality: commands should be tightly bounded, and any cross-zone action should be exceptional rather than normal. For identity-heavy attack patterns, NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs shows how quickly exposed credentials can be abused, which is relevant when AI tooling bridges business systems and plant networks. These controls tend to break down when legacy OT assets cannot support short-lived auth, because static service accounts become the fallback.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, so organisations have to balance plant uptime against security assurance. That tradeoff is especially visible in brownfield OT, where vendors, PLC gateways, and historian integrations may only support static credentials or coarse RBAC. Current guidance suggests compensating controls are acceptable in these environments, but there is no universal standard for this yet.

For that reason, teams should treat framework alignment as layered rather than singular. NIST CSF 2.0 is the organising baseline, ZTA is the architectural principle, and AI risk controls apply when the agent can make or influence decisions autonomously. NHIMG’s Top 10 NHI Issues is useful for prioritising common failure modes such as overprivileged credentials and weak lifecycle discipline, while the Ultimate Guide to NHIs — Standards helps teams map those risks to formal controls. In edge cases, a human approval step may be the only safe path for high-impact OT commands, especially where change windows, safety interlocks, or vendor limitations prevent true JIT enforcement. Best practice is evolving, but the security test stays the same: if identity, integrity, and auditability cannot be proven at action time, the AI should not be trusted with direct OT execution.

Related resources from NHI Mgmt Group

• How should teams secure non-human identities across cloud and SaaS?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams govern ecommerce AI agents that can touch payment systems?
• How should security teams combine AI code scanning with runtime security?