TL;DR: OT security must move beyond asset visibility toward cyber-physical context, governed response, and AI-assisted analysis, according to Armis, because knowing an exposed device exists is not enough without understanding what it controls and what can safely be automated. The control question is no longer detection alone, but whether operational decisions can be accelerated without losing accountability.
At a glance
What this is: This is Armis’s analysis of why operational technology security needs asset intelligence, process context, and governed automation rather than IT-style visibility alone.
Why it matters: It matters because IAM, NHI, and security teams supporting OT-adjacent environments need to understand how automation, approvals, and evidence flows change when security actions can affect physical processes.
Context
Operational technology security is not the same problem as enterprise IT security. In plants, hospitals, ports, and other critical environments, an exposed asset is only the starting point; the real question is what that asset controls, what failure would mean, and who can safely act on it.
This article sits at the intersection of cyber-physical security, governance, and automation. Where OT platforms, security workflows, or AI-assisted analysis influence access and response decisions, the identity and authority of the system making those decisions becomes part of the control problem, not just the asset problem.
Armis frames that difference around governed autonomy rather than raw speed. That is a familiar pattern in critical environments: the more consequential the environment, the more important it becomes to preserve approval, evidence, and operational context alongside automation.
Key questions
Q: What breaks when OT security is treated like IT security?
A: OT security breaks when teams rely on generic vulnerability handling instead of process context. An exposed device is not just a patching issue if it sits on a production control path or supports a safety-critical dependency. Without operational context, teams overreact to low-impact issues and underreact to exposures that can affect availability, safety, or change control.
Q: Why does process context matter more than vulnerability severity in OT?
A: Because the same vulnerability can have very different consequences depending on what the asset controls. A medium-severity issue on a controller that governs production can matter more than a higher-severity issue on a non-critical device. OT teams need to rank risk by operational role, dependency, and likely disruption, not by score alone.
Q: What do teams get wrong about autonomous security operations?
A: Teams often confuse speed with control. A system can act quickly and still be governance-poor if it cannot justify its recommendations, show its evidence trail, or remain within a bounded response scope. The right question is not whether it works fast, but whether its decisions are accountable.
Q: How should organisations govern non-human identities across their environment?
A: Start by inventorying every machine identity, assigning a human owner, and tying each one to a business purpose. Then apply routine access review, least privilege, and revocation for stale accounts. NHIs should be governed as accountable identities, not as background infrastructure that can be left unmanaged.
Technical breakdown
Why OT exposure management depends on process context
In OT, exposure data without process context creates false confidence. A controller, historian, engineering workstation, or connected device may all be vulnerable, but the operational risk depends on what the asset controls, what upstream and downstream dependencies exist, and whether the environment can tolerate disruption. Cyber exposure management therefore has to combine inventory, vulnerability data, protocol intelligence, and operational context. That is why generic severity scoring is not enough. An exposure on a production control path is materially different from the same issue on a spare asset in maintenance. Security decisions in these environments are really safety and continuity decisions.
Practical implication: build prioritisation around what each asset controls, not just what CVSS says.
How governed automation changes response in cyber-physical systems
Governed automation means machines can assist with detection, correlation, recommendation, and routing, while consequential actions still pass through accountable approval. In OT, that distinction matters because blocking traffic, isolating a device, or changing segmentation can affect production and safety. The right model is not full autonomy and not manual-only operations, but policy-bound automation that carries evidence with the recommendation. If the system can show why an action is suggested, what traffic was observed, and who approved it, teams can move faster without losing operational control. That is especially important when many systems are too complex for human-only triage at speed.
Practical implication: require automated recommendations to carry evidence, ownership, and approval context before execution.
Why cyber-physical systems security is becoming an identity and governance problem
As OT platforms connect to broader asset, change, compliance, and response workflows, the authority of the system becomes central. The issue is no longer only whether an asset is exposed, but which system can create tickets, approve changes, trigger isolation, and record evidence. That creates an identity governance problem around service accounts, workflow permissions, and delegated operational authority. In other words, cyber-physical security increasingly depends on who or what is allowed to decide, not just what is allowed to connect. This is where OT security intersects with IAM and NHI governance in a genuine way.
Practical implication: inventory and constrain the non-human identities that can initiate OT response or change workflows.
Threat narrative
Attacker objective: The objective is to reach and influence operational control paths in ways that create disruption, unsafe conditions, or uncontrolled change.
- Entry occurs when exposed OT assets, connected devices, or undocumented dependencies are discovered in a complex operational environment.
- Escalation occurs when teams lack the context to distinguish a harmless exposure from a control-path risk, causing delayed or misprioritised response.
- Impact follows when a consequential OT change is made without enough operational evidence, potentially disrupting production or safety-critical processes.
Breaches seen in the wild
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cyber-physical security is now a governance problem, not just a visibility problem. OT teams do not fail because they cannot see assets; they fail because they cannot reliably interpret exposure in the context of process criticality, dependency chains, and acceptable action. That shifts the control question from discovery to decision quality. Practitioners should treat OT security as a governed operating model, not a scan result.
Autonomy in OT only works when the system preserves accountability. Faster analysis and routing are useful, but consequential actions in critical environments still need evidence, approvals, and traceability. The market is moving toward security workflows that can recommend, document, and route decisions without absorbing authority from operators. Practitioners should require any autonomous security flow to keep the human decision point intact where impact is material.
Cyber-physical systems security now has a non-human identity dimension. Once security platforms can open tickets, trigger change, approve remediation, or initiate isolation, those workflows become actors in their own right. That means service accounts, workflow permissions, and delegated automation rights must be governed as carefully as human admin access. Practitioners should bring NHI controls into OT change and response design, not bolt them on later.
Process-aware risk is the named concept this market needs. Exposure scores alone do not tell OT teams what matters. Process-aware risk means evaluating vulnerabilities in relation to the asset’s operational role, the traffic it carries, and the change it could trigger. That is the only defensible basis for selective automation in environments where wrong action is as dangerous as inaction. Practitioners should replace generic prioritisation with process-aware governance.
AI in OT security will be judged by control, not by inference quality. The article is right to frame AI as a way to accelerate discovery and recommendation, but the governance question is whether AI preserves operational certainty. In critical infrastructure, the value of AI is bounded by the quality of its evidence, the scope of its permissions, and the clarity of its escalation path. Practitioners should evaluate AI through control integrity, not model enthusiasm.
What this signals
Process-aware risk is the better model for OT security because generic severity scores cannot express production impact. Once teams tie exposure to what an asset actually controls, they can separate noisy findings from change-worthy ones and reduce the chance of automating the wrong response.
Governance has to move with automation. As more OT security workflows are delegated to systems, the permissions, approvals, and evidence trails behind those workflows need the same scrutiny as human admin access, especially where a single action can affect physical operations.
For practitioners
- Map OT exposure to process criticality Prioritise vulnerabilities by what the asset controls, what dependencies it supports, and the production or safety impact of disruption. Replace generic severity-only queues with a process-aware triage model for critical environments.
- Require evidence-carrying remediation workflows Make every recommended segmentation, isolation, or change action include the supporting traffic evidence, affected asset context, and the owner responsible for approval or rejection.
- Constrain non-human change authority Review the service accounts and workflow identities that can create tickets, trigger containment, or update OT records, then scope those permissions to the minimum required operational role.
- Link cyber exposure to compliance evidence Build reporting that connects asset intelligence and response records to the evidence needed for IEC 62443, NERC CIP, NIS2, and sector-specific audits.
Key takeaways
- OT security fails when exposure data is detached from the process the asset supports, because the same vulnerability can carry radically different operational consequences.
- The article’s central argument is that governed automation, not blind autonomy, is the only acceptable way to accelerate OT response in critical environments.
- Identity governance becomes relevant in OT whenever non-human systems can create tickets, trigger containment, or approve change, because those actors are now part of the control plane.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | OT automation and workflow access depend on tightly governed permissions and entitlements. |
| Recommendation — Apply PR.AA-05 to constrain which systems can trigger OT response or change actions. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s governance model depends on controlling workflow identities and delegated access. |
| Recommendation — Use CIS-5 to inventory and restrict the accounts that can approve or execute OT changes. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is central when security automation can affect physical systems and operations. |
| Recommendation — Enforce AC-6 so automated OT workflows only hold the authority required for their role. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Access control governance underpins who can act within connected OT security workflows. |
| Recommendation — Implement A.5.15 to govern approval and execution rights in OT security processes. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Non-human workflow identities can overreach once they can initiate response or change actions. |
| Recommendation — Review OT workflow identities for NHI-05 and reduce any unnecessary operational authority. | ||
Key terms
- Cyber-Physical System: A cyber-physical system combines software, networking, and physical processes that influence real-world operations. In security terms, compromise can affect availability, safety, and production continuity, which is why containment and resilience controls matter as much as detection.
- Process-Aware Risk: A risk model that scores exposures by the operational process an asset supports, not just by technical severity. It helps OT teams decide which findings can wait and which ones could disrupt production, safety, or essential services if ignored.
- Governed automation: A governed automation is a workflow that executes a task without giving the requester broad standing access. It uses policy checks, structured inputs, and audit records so the organisation can approve outcomes while keeping privilege narrow and traceable.
- Continuous Cyber Threat Exposure Management: Continuous cyber threat exposure management is a programme for discovering, validating, analysing, and remediating security exposure on an ongoing basis. It focuses on what is actually exploitable, not just what is theoretically vulnerable. The value comes from combining exposure data, control testing, threat intelligence, and business context into one prioritised workflow.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the controls that govern both human and non-human access.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org