No single standard covers AI in manufacturing, and if one phishing click can reach OT, the architecture is already broken. Gary Tillery of Skkynet and Matt Morris of EverLine answer audience questions on the specific standards stack, IT/OT boundary controls, and network-level solutions from the “It Can’t Happen to Me – Until It Does” session at the Industrial AI Summit 2026.
What Can You Use Now to Secure AI in OT?
Audience question: How do we tackle the nuance and rawness of this content? We understand we need to educate, but this is new territory and the answers so far are more about communication than substance.
Gary Tillery, CEO of Skkynet:
You’re right that a panel hour cannot carry the raw detail. The nuance is that OT risk is not a communication problem. It is consequence-driven: a bad change can stop a line or create a safety event, the installed base is old and vendor-specific, and the safe action is often to leave a vulnerable asset running until a planned outage. Education that stays at ‘be aware’ does not help a board or a plant manager decide.
What is usable now is a short stack, not a survey. Segment with IEC 62443 zones and conduits. Keep safety functions on the existing safety standard, IEC 61508, 61511, or 62061 / ISO 13849, and do not let a model or a remote tool write through that path. For AI, treat it as an advisor: OPC UA or the asset shell for meaning, a broker outside the prompt for any action, and ISO/IEC 42001 plus the NIST AI RMF for the claim that the system is still the one you approved after the model changes.
We used the hour to point at those decisions. The plant-level work, asset inventory, zone design, what is actually reachable from Level 3, which actions stay human-gated, is the follow-up, and it has to be done against your process, not a generic slide.
Which Specific Standards Cover AI in Manufacturing?
The short stack above names the decisions. The next question asks for the full reference.
Audience question: When you mentioned standards, could you please be specific? Are they just connectivity and data/system interoperability standards? What standards are needed for AI integration in manufacturing systems for interoperability, security, safety and trustworthiness?
Gary Tillery, CEO of Skkynet:
No single standard covers AI in manufacturing. Integration needs a stack: industrial interoperability and OT security underneath, functional safety as a hard boundary the model cannot cross, and an AI management system on top for trustworthiness. Agentic and generative systems are the largest gap; current standards still assume a bounded model, not a planner that selects tools. Below are some standards that I looked up after the panel was over and can be used in concert with the integration stack but this is not a complete list;
IEC 62541 (OPC UA) is the practical base: secure, vendor-neutral communication plus information models so AI reads machine state, not raw tags. Companion specs and the newer OPC UA-for-AI / MCP work extend that toward tool use, but the method call should stay inside the information model.
IEC 63278 (Asset Administration Shell) and the RAMI 4.0 stack give each asset a standardized digital representation. Pair it with ECLASS or a dictionary reference so retrieval is grounded in asset data rather than free text.
IEC 62443 is the control system. Place models, brokers, and tool gateways in zones and conduits; apply least privilege, authentication, and security levels to the AI path the same way as any other OT interface. IEC PAS 62443-1-6 covers the IIoT case. NIST SP 800-82 Rev. 3 is the OT guide and points at 62443 for the program.
The model must not hold standing credentials to PLCs or historians. Tool calls go through a broker outside the prompt, with short-lived, task-scoped credentials and an audit trail of who delegated the action.
ISO/IEC 27001 covers the enterprise IT side. It does not replace 62443 on the plant network.
IEC 62264 / ISA-95 defines the enterprise–control boundary (ERP, MES, control). ISO 23247 is the digital-twin framework for manufacturing. MQTT with Sparkplug B is the lightweight telemetry path; it is not a substitute for OPC UA semantics on control-relevant data.
ISO/IEC 42001:2023 is the certifiable AI management system (policy, risk, lifecycle, Annex A controls). ISO/IEC 23894 is the risk-management guidance; ISO/IEC 5338 is the AI lifecycle; the ISO/IEC 5259 series is data quality; ISO/IEC 22989 is the shared vocabulary.
NIST AI RMF (AI 100-1) plus the Generative AI Profile (AI 600-1) is the voluntary counterpart: Govern, Map, Measure, Manage. Use it to structure the work; use 42001 if a customer or regulator wants a certificate. They crosswalk.
Where the EU AI Act applies, safety components of products and certain industrial uses are high-risk: risk management, data governance, logging, human oversight, and accuracy/robustness. That aligns with 42001 and the safety split above; it does not replace IEC 61508 or 62443.
What Stops a Phishing Attack from Reaching OT?
IEC 62443 zones and conduits appear throughout that list. What happens when one employee clicks the wrong email?
Audience question: If one employee clicks the wrong email: What should stop that compromise at the IT/OT boundary? How do you prove that control works before an outage?
Matt Morris, VP of Security and Resilience at EverLine:
The premise is the problem. If a single click can reach OT, you don’t have a phishing problem, you have an architecture problem. Design assuming IT is already compromised, because statistically, somewhere, it is.
What should stop it:
- No trust that crosses the boundary. The real bridges are rarely firewalls. They’re a shared Active Directory, reused credentials, dual-homed engineering workstations, and always-on vendor remote access. Separate OT identity, no domain trust, no shared accounts.
- Brokered, not routed, connectivity. An IT/OT DMZ where data is pushed out through defined services, and nothing initiates inbound to OT. Zones and conduits in the IEC 62443 sense, with every conduit justified and owned.
- Gated remote access. Jump hosts with phishing-resistant MFA, session approval, recording, and time-boxed access.
- Hardened endpoints on the OT side. Application allowlisting on HMIs and engineering workstations, so even something that lands can’t execute.
- Detection at the conduit. OT-aware monitoring and tripwires in the DMZ, because prevention will eventually miss.
And the one most people skip: operational dependency. Colonial Pipeline’s OT was not compromised. They shut it down because they couldn’t bill or track product without IT. If OT can’t run without IT, your boundary is a fiction regardless of the firewall.
How you prove it before the outage:
- Assume-breach testing that starts from a compromised IT workstation, not from an external scan. Can the red team reach an OT asset, credential, or conduit? Run it in a lab replica or during maintenance windows, not blind against live control systems.
- Attack-path analysis against as-built configuration, not the network diagram. Diagrams lie; firewall rules and AD trusts don’t.
- Island-mode drills. Actually sever IT from OT and run operations for a defined period. That test surfaces the hidden dependencies no assessment will.
- Measure it. Time to isolate, percentage of conduits validated this year, number of undocumented dependencies found. If you can’t report those numbers, you haven’t proven anything, you’ve assumed it.
Gary Tillery, CEO of Skkynet:
Periodically testing the environment is important, and most customers will use companies that provide this exact service. This is always different per customer, per operation type and design of the network architecture overall.
Would a Dedicated Secure Network Reduce Risk?
All of the controls above assume you keep the existing network. What if you replace it entirely?
Audience question: If the internet is labeled as bad and no longer able to be secure in a post-AI world, would there then be a new network, new node system to mitigate risk? Think SIPR, secure networks like DoD.
Gary Tillery, CEO of Skkynet:
There are other software and hardware solutions in the market today. Skkynet has a software product designed specifically for this problem, Cogent DataHub, available as a free download. But even with this product, the network has to be designed to maximize the security of one network from infecting another connected network. The Cogent DataHub product does not have open ports in the firewall because it is outbound only so there is not an attack surface from either a bad actor or agent to the outside world or another connected network like from IT or another OT network. There are other hardware options like data diodes, and you can even combine data diodes with a product like Cogent DataHub for even more design choices.
Gary Tillery of Skkynet and Matt Morris of EverLine provided these answers after the “It Can’t Happen to Me – Until It Does” session at the Industrial AI Summit 2026. The session also featured Ian Bramson of Black & Veatch and Scott Christensen of GrayMatter. Sponsored by Skkynet.
Related from IIoT World
