By Ross O'Brien, ChCSP, Director, ControlShield Ltd I keep being asked the same question in different forms. Does AI break IEC 62443? Are security levels (SLs) obsolete? Should every zone now be SL 3? My short answer is no, no, and not automatically. The security level model is a way of reasoning about threats and capability. AI doesn't replace that reasoning; it changes the inputs. If you set your target security levels a few years ago and haven't looked since, it's worth another look. I cover AI in the hands of attackers, AI inside the systems we build, AI used by defenders, and what that means for the seven foundational requirements, then finish with recommendations and a checklist. Where I'm giving my own judgement rather than the standard or published guidance, I say so. A quick reminder: what a security level is IEC 62443-3-3:2013 defines security levels for a system in terms of the attacker it is meant to resist, judged on four things: means, resources, skills and motivation. In plain terms, as summarised in the International Society of Automation (ISA) Global Cybersecurity Alliance (ISAGCA) Quick Start Guide: SL 1: protection against casual or accidental violation. SL 2: protection against deliberate attack using simple means, low resources, generic skills and low motivation. SL 3: protection against deliberate attack using sophisticated means, moderate resources, skills specific to industrial automation and control systems (IACS), and moderate motivation. SL 4: as SL 3, but with extended resources and high motivation. There are three types of security level. The target (SL-T) is what a zone or conduit needs, and comes out of the risk assessment in IEC 62443-3-2:2020. The capability (SL-C) is what a system or component can deliver natively when properly configured, defined for systems in 62443-3-3 and for components in IEC 62443-4-2:2019. The achieved level (SL-A) is what you actually have once the system is built and running. Keep those three separate. Most of the confusion I see about AI and 62443 comes from mixing them up. Part 1: AI as an attacker capability The SL definitions describe attackers by what they bring. AI changes what attackers bring. The UK National Cyber Security Centre (NCSC) assessment Impact of AI on cyber threat from now to 2027 is direct about this. It judges that AI will almost certainly keep making parts of intrusion operations more effective, and that AI-enabled tools will highly likely spread to a wider range of state and non-state actors. It notes that the gap between disclosure and exploitation of a vulnerability has already shrunk to days and that AI will almost certainly shorten it further, with an increased threat to critical national infrastructure, particularly operational technology (OT) with lower levels of security. There is now a public example. In November 2025 Anthropic reported disrupting an espionage campaign in which attackers used its coding agent to attempt intrusions into roughly thirty organisations, including chemical manufacturers, succeeding in a small number of cases. By Anthropic's account the AI did most of the operational work, with humans stepping in at a handful of decision points. It was data theft from business systems, not an attack on a control system, but the lesson for OT is clear enough. So what does this do to the SL ladder? My view: Skills and means are being compressed. Reconnaissance, reading vendor documentation, writing exploit code and making sense of a captured configuration file are all getting easier for less skilled people. Some capability that used to mark an SL 3 attacker is moving down towards SL 2 actors. Resources stretch further. One capable operator with good tooling can now do the work that used to need a team. That blurs "moderate" and "extended" resources. Motivation hasn't changed. AI doesn't make anyone more interested in your substation or water treatment works. The definitions are unchanged. What has moved is which real-world attackers fit each one, and that matters when you set SL-T under 62443-3-2. If your risk assessment said "the credible threat here is an opportunist with generic skills, so SL 2 is enough", ask whether that still holds when an opportunist can get IACS-specific help from an AI tool. That is not an argument for SL 3 everywhere. It is an argument to re-test the threat assumption, record why you kept or changed the target, and look hardest at zones reachable from the internet, vendor remote access or the corporate network. Part 2: AI inside the system AI is also turning up inside OT architectures: predictive maintenance on historian data, anomaly detection, optimisation tools, vendor cloud platforms, and engineering or operator "copilots" built on large language models (LLMs). The joint guidance Principles for the Secure Integration of Artificial Intelligence in Operational Technology, published on 3 December 2025 by the US Cybersecurity and Infrastructure Security Agency (CISA) and the Australian Signals Directorate's Australian Cyber Security Centre with partner agencies including the UK NCSC, is the best public reference I've seen. It maps typical uses onto the Purdue model: predictive machine learning (ML) models in the operational levels (0 to 3), LLMs at the business levels (4 and 5), often working on data exported from OT. Put every AI function in a zone, on purpose. An AI service is an asset with a function, a data flow and a trust level, and it belongs in the zone and conduit model like anything else. If the model runs in a vendor's cloud, the conduit leads to an untrusted zone, however it's sold to you. A recent ISA article by Kalaichelvi Easwaran argues that AI engines should be treated as high-risk zones by default. I think that's the right starting position. Prefer data out, not access in. The CISA guidance recommends push-based or brokered architectures that move data out of OT without persistent inbound access, and one-way transfer where data must reach business networks. That fits zone boundary protection and stops the AI system becoming a standing attack path into control zones. Don't confuse SL-C with SL-A. A component's SL-C claim under 62443-4-2 covers the component as designed and configured. It tells you very little about a cloud model the component calls, or about a model that will be retrained next quarter. Ask the supplier exactly what is inside the boundary of their claim. Ask about the development lifecycle. IEC 62443-4-1:2018 sets secure development lifecycle requirements for product suppliers, from security requirements and design through verification, defect and patch management to end of life. AI features are part of the product. The NCSC and CISA Guidelines for secure AI system development cover similar ground for AI specifically. The questions I'd ask: how do you threat model the model, how do you test it before release, how do you handle a defect in behaviour rather than code, and how do you tell customers when the model changes? Treat model changes as changes. A new model version, training data set or prompt template can change behaviour without any code changing. That belongs in management of change, tested like a firmware update. Part 3: AI used by defenders AI is useful on our side too: passive asset discovery, anomaly detection, alert triage and log summaries. The CISA guidance lists anomaly and threat detection among its example uses. The limits matter: It's only as good as its data. A model trained on someone else's network can miss what matters on yours, with its quiet traffic and proprietary protocols. False alarms cost more in OT. The CISA guidance warns that AI alarm errors add to operator cognitive load and can cause unnecessary downtime. Over-reliance erodes skills. The same guidance flags staff losing the manual skills they need when the AI is unavailable or wrong. The tool becomes a target. A platform with wide visibility of your OT network is valuable to an attacker. The 62443 point: AI-assisted defence does not change what a security level means. SL 3 is still defined by the attacker it resists. What AI can change is the cost of achieving and sustaining it, because continuous monitoring, timely response and a reliable inventory become cheaper. In my view that is the real benefit. It makes a higher SL-T, where the threat justifies one, more affordable; it doesn't replace the controls behind it. One practical note. An article on ISA's own site reminds readers that the 62443 standards are licensed and may not be uploaded into ChatGPT or other third-party AI tools. If your team uses AI assistants for compliance work, make sure they know. Part 4: the seven foundational requirements under AI pressure IEC 62443-3-3:2013 groups its system requirements (SRs) under seven foundational requirements (FRs). The table is my own assessment of where AI adds pressure, not text from the standard; only the SR titles come from 62443-3-3. Foundational requirement How AI changes the pressure (author's assessment) FR 1 Identification and authentication control (IAC) AI services, agents and application programming interfaces (APIs) need their own identities and credentials (SR 1.2 Software process and device identification and authentication). AI-written phishing raises pressure on human authentication, particularly remote access (SR 1.13 Access via untrusted networks). FR 2 Use control (UC) Agents and copilots must have least privilege and no authority beyond what a human in the same role would have (SR 2.1 Authorisation enforcement). Their actions must be auditable (SR 2.8 Auditable events). FR 3 System integrity (SI) New integrity risks: poisoned training data, manipulated models and prompt injection. Model files and configuration need integrity checks like any other software (SR 3.4 Software and information integrity). Anything AI suggests must pass input validation before it reaches control (SR 3.5 Input validation). FR 4 Data confidentiality (DC) Historian and engineering data sent to AI services may be retained or used for training. Engineering data such as network diagrams and logic is highly valuable to attackers (SR 4.1 Information confidentiality). FR 5 Restricted data flow (RDF) The biggest change in practice. Every AI data flow is a conduit, often to an untrusted zone. Push-only or one-way designs and strict zone boundary protection matter (SR 5.1 Network segmentation, SR 5.2 Zone boundary protection). FR 6 Timely response to events (TRE) Attack timelines are getting shorter, so detection and response must keep up (SR 6.2 Continuous monitoring). AI helps with triage, but people must remain accountable for the response. FR 7 Resource availability (RA) AI workloads must not compete with control functions for bandwidth or compute (SR 7.2 Resource management). A failed or withdrawn AI service must fail safe, with a tested fallback to normal operation (SR 7.4 Control system recovery and reconstitution). Practical recommendations These are my recommendations, drawing on the guidance listed at the end. Revisit your SL-T assumptions. Re-run the threat part of your 62443-3-2 risk assessment with AI-assisted attackers in mind. Record the reasoning, whether or not the target changes. Treat AI services as conduits to untrusted zones. Every connection to a vendor cloud, model API or analytics platform gets a conduit definition, a named owner and boundary protection. Favour push-only or one-way designs. Ask suppliers hard questions. What AI features are in the product, and can the asset owner turn them off? Does it work without the vendor cloud? Where are models hosted? Will the software bill of materials (SBOM) cover AI components? How will you notify us of model changes or behaviour defects? The CISA guidance covers most of these. Control data flows to AI services. Decide which data can leave OT, in what form, to whom, and whether it can be used for training. Put that in the contract, not just the design. Bring models under management of change. Model versions, training data and prompts are configuration. Test changes off-line before they reach production. Keep a human in the loop. The CISA guidance says AI such as LLMs almost certainly should not be used to make safety decisions in OT, and recommends limiting active AI control without a human in the loop. My rule is simple: AI does not write to the control layer without engineering approval. No setpoint, logic or alarm changes unless a named engineer authorises them through the normal process. Keep safety separate. Safety instrumented functions stay independent of any AI function. AI failure modes, and how to bypass the AI, belong in your safety and incident response procedures. Log AI decisions. Record inputs, outputs and actions with timestamps, under an identity distinct from users and other systems, as the CISA guidance recommends. What to do this quarter List every AI function in, or connected to, your OT environment, including features built into products you already own. Mark each one on your zone and conduit drawings. If it isn't on the drawing, it isn't controlled. Re-test the threat assumptions behind SL-T for internet-reachable, remote-access and IT-connected zones. Send your main OT suppliers a short set of AI questions (features, cloud dependency, data use, SBOM, change notification, ability to disable). Add AI models, training data and prompts to your management of change procedure. Confirm in writing that no AI function can write to the control or safety layer without engineering approval. Check that AI activity is logged under its own identity and reaches your monitoring. Brief your team that licensed standards and sensitive engineering data must not be pasted into public AI tools. What is the standard, and what is my judgement From the standards: the SL 1 to SL 4 definitions, the SL-T, SL-C and SL-A distinction, the seven FRs and the SR titles (IEC 62443-3-3:2013, with component SL-C in IEC 62443-4-2:2019); SL-T set through risk assessment of zones and conduits (IEC 62443-3-2:2020); supplier development lifecycle (IEC 62443-4-1:2018). For asset owner security programmes, IEC 62443-2-1:2024 (edition 2.0) has replaced the 2010 edition. From published guidance: the threat trends (NCSC), the architecture, vendor, oversight and logging recommendations (CISA and partners), and the ISA and ISAGCA material cited. My judgement: that AI is compressing the skills and means axes of the SL definitions, the FR table above, treating AI services as untrusted-zone conduits by default, and the "no writes to the control layer without engineering approval" rule. ISA's November 2025 position paper, Industrial AI and Its Impact on Automation, also puts 62443 at the centre of securing AI-enabled systems, and I agree. Zones, conduits, target levels and the foundational requirements all still work. What AI changes is the threat we assume when we set targets, the number of conduits we manage, and the cost of sustaining a high level. Use the framework properly and AI fits within it. Sources UK National Cyber Security Centre, Impact of AI on cyber threat from now to 2027. https://www.ncsc.gov.uk/report/impact-ai-cyber-threat-now-2027 CISA, ASD's ACSC and partner agencies, Principles for the Secure Integration of Artificial Intelligence in Operational Technology (3 December 2025). https://www.cisa.gov/resources-tools/resources/principles-secure-integration-artificial-intelligence-operational-technology UK National Cyber Security Centre and CISA, Guidelines for secure AI system development. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign (13 November 2025). https://www.anthropic.com/news/disrupting-AI-espionage ISA Global Cybersecurity Alliance, ISA/IEC 62443 Quick Start Guide. https://isagca.org/hubfs/2023%20ISA%20Website%20Redesigns/ISAGCA/PDFs/ISAGCA%20Quick%20Start%20Guide%20FINAL.pdf ISA, ISA Explores Industrial AI's Impact on Automation in a New Position Paper (November 2025). https://www.isa.org/news-press-releases/2025/november/isa-explores-industrial-ai-s-impact-on-automation Kalaichelvi Easwaran, Securing New Threats: Industrial AI-Powered Applications and Autonomous Agents, ISA (October 2026). https://www-prod.isa.org/web/acom/article/securing-new-threats-industrial-ai-powered-applications-autonomous-agents Mohannad AlRasan, ISA/IEC 62443 and Risk Assessment: New Horizons in the AI Revolution, ISA (May 2024). https://www-prod.isa.org/web/acom/article/isa-iec-62443-risk-assessment-ai-revolution ISA, ISA/IEC 62443 Series of Standards. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards IEC Webstore: IEC 62443-2-1:2024, IEC 62443-3-2:2020, IEC 62443-3-3:2013, IEC 62443-4-1:2018, IEC 62443-4-2:2019. https://webstore.iec.ch/en/publication/62883
By Ross O'Brien, ChCSP, Director, ControlShield Ltd I keep being asked the same question in different forms. Does AI break IEC 62443? Are security levels (SLs) obsolete? Should every zone now be SL 3? My short answer is no, no, and not automatically. The security level model is a way of reasoning about threats and capability. AI doesn't replace that reasoning; it changes the inputs. If you set your target security levels a few years ago and haven't looked since, it's worth another look. I cover AI in the hands of attackers, AI inside the systems we build, AI used by defenders, and what that means for the seven foundational requirements, then finish with recommendations and a checklist. Where I'm giving my own judgement rather than the standard or published guidance, I say so. A quick reminder: what a security level is IEC 62443-3-3:2013 defines security levels for a system in terms of the attacker it is meant to resist, judged on four things: means, resources, skills and motivation. In plain terms, as summarised in the International Society of Automation (ISA) Global Cybersecurity Alliance (ISAGCA) Quick Start Guide: SL 1: protection against casual or accidental violation. SL 2: protection against deliberate attack using simple means, low resources, generic skills and low motivation. SL 3: protection against deliberate attack using sophisticated means, moderate resources, skills specific to industrial automation and control systems (IACS), and moderate motivation. SL 4: as SL 3, but with extended resources and high motivation. There are three types of security level. The target (SL-T) is what a zone or conduit needs, and comes out of the risk assessment in IEC 62443-3-2:2020. The capability (SL-C) is what a system or component can deliver natively when properly configured, defined for systems in 62443-3-3 and for components in IEC 62443-4-2:2019. The achieved level (SL-A) is what you actually have once the system is built and running. Keep those three separate. Most of the confusion I see about AI and 62443 comes from mixing them up. Part 1: AI as an attacker capability The SL definitions describe attackers by what they bring. AI changes what attackers bring. The UK National Cyber Security Centre (NCSC) assessment Impact of AI on cyber threat from now to 2027 is direct about this. It judges that AI will almost certainly keep making parts of intrusion operations more effective, and that AI-enabled tools will highly likely spread to a wider range of state and non-state actors. It notes that the gap between disclosure and exploitation of a vulnerability has already shrunk to days and that AI will almost certainly shorten it further, with an increased threat to critical national infrastructure, particularly operational technology (OT) with lower levels of security. There is now a public example. In November 2025 Anthropic reported disrupting an espionage campaign in which attackers used its coding agent to attempt intrusions into roughly thirty organisations, including chemical manufacturers, succeeding in a small number of cases. By Anthropic's account the AI did most of the operational work, with humans stepping in at a handful of decision points. It was data theft from business systems, not an attack on a control system, but the lesson for OT is clear enough. So what does this do to the SL ladder? My view: Skills and means are being compressed. Reconnaissance, reading vendor documentation, writing exploit code and making sense of a captured configuration file are all getting easier for less skilled people. Some capability that used to mark an SL 3 attacker is moving down towards SL 2 actors. Resources stretch further. One capable operator with good tooling can now do the work that used to need a team. That blurs "moderate" and "extended" resources. Motivation hasn't changed. AI doesn't make anyone more interested in your substation or water treatment works. The definitions are unchanged. What has moved is which real-world attackers fit each one, and that matters when you set SL-T under 62443-3-2. If your risk assessment said "the credible threat here is an opportunist with generic skills, so SL 2 is enough", ask whether that still holds when an opportunist can get IACS-specific help from an AI tool. That is not an argument for SL 3 everywhere. It is an argument to re-test the threat assumption, record why you kept or changed the target, and look hardest at zones reachable from the internet, vendor remote access or the corporate network. Part 2: AI inside the system AI is also turning up inside OT architectures: predictive maintenance on historian data, anomaly detection, optimisation tools, vendor cloud platforms, and engineering or operator "copilots" built on large language models (LLMs). The joint guidance Principles for the Secure Integration of Artificial Intelligence in Operational Technology, published on 3 December 2025 by the US Cybersecurity and Infrastructure Security Agency (CISA) and the Australian Signals Directorate's Australian Cyber Security Centre with partner agencies including the UK NCSC, is the best public reference I've seen. It maps typical uses onto the Purdue model: predictive machine learning (ML) models in the operational levels (0 to 3), LLMs at the business levels (4 and 5), often working on data exported from OT. Put every AI function in a zone, on purpose. An AI service is an asset with a function, a data flow and a trust level, and it belongs in the zone and conduit model like anything else. If the model runs in a vendor's cloud, the conduit leads to an untrusted zone, however it's sold to you. A recent ISA article by Kalaichelvi Easwaran argues that AI engines should be treated as high-risk zones by default. I think that's the right starting position. Prefer data out, not access in. The CISA guidance recommends push-based or brokered architectures that move data out of OT without persistent inbound access, and one-way transfer where data must reach business networks. That fits zone boundary protection and stops the AI system becoming a standing attack path into control zones. Don't confuse SL-C with SL-A. A component's SL-C claim under 62443-4-2 covers the component as designed and configured. It tells you very little about a cloud model the component calls, or about a model that will be retrained next quarter. Ask the supplier exactly what is inside the boundary of their claim. Ask about the development lifecycle. IEC 62443-4-1:2018 sets secure development lifecycle requirements for product suppliers, from security requirements and design through verification, defect and patch management to end of life. AI features are part of the product. The NCSC and CISA Guidelines for secure AI system development cover similar ground for AI specifically. The questions I'd ask: how do you threat model the model, how do you test it before release, how do you handle a defect in behaviour rather than code, and how do you tell customers when the model changes? Treat model changes as changes. A new model version, training data set or prompt template can change behaviour without any code changing. That belongs in management of change, tested like a firmware update. Part 3: AI used by defenders AI is useful on our side too: passive asset discovery, anomaly detection, alert triage and log summaries. The CISA guidance lists anomaly and threat detection among its example uses. The limits matter: It's only as good as its data. A model trained on someone else's network can miss what matters on yours, with its quiet traffic and proprietary protocols. False alarms cost more in OT. The CISA guidance warns that AI alarm errors add to operator cognitive load and can cause unnecessary downtime. Over-reliance erodes skills. The same guidance flags staff losing the manual skills they need when the AI is unavailable or wrong. The tool becomes a target. A platform with wide visibility of your OT network is valuable to an attacker. The 62443 point: AI-assisted defence does not change what a security level means. SL 3 is still defined by the attacker it resists. What AI can change is the cost of achieving and sustaining it, because continuous monitoring, timely response and a reliable inventory become cheaper. In my view that is the real benefit. It makes a higher SL-T, where the threat justifies one, more affordable; it doesn't replace the controls behind it. One practical note. An article on ISA's own site reminds readers that the 62443 standards are licensed and may not be uploaded into ChatGPT or other third-party AI tools. If your team uses AI assistants for compliance work, make sure they know. Part 4: the seven foundational requirements under AI pressure IEC 62443-3-3:2013 groups its system requirements (SRs) under seven foundational requirements (FRs). The table is my own assessment of where AI adds pressure, not text from the standard; only the SR titles come from 62443-3-3. Foundational requirement How AI changes the pressure (author's assessment) FR 1 Identification and authentication control (IAC) AI services, agents and application programming interfaces (APIs) need their own identities and credentials (SR 1.2 Software process and device identification and authentication). AI-written phishing raises pressure on human authentication, particularly remote access (SR 1.13 Access via untrusted networks). FR 2 Use control (UC) Agents and copilots must have least privilege and no authority beyond what a human in the same role would have (SR 2.1 Authorisation enforcement). Their actions must be auditable (SR 2.8 Auditable events). FR 3 System integrity (SI) New integrity risks: poisoned training data, manipulated models and prompt injection. Model files and configuration need integrity checks like any other software (SR 3.4 Software and information integrity). Anything AI suggests must pass input validation before it reaches control (SR 3.5 Input validation). FR 4 Data confidentiality (DC) Historian and engineering data sent to AI services may be retained or used for training. Engineering data such as network diagrams and logic is highly valuable to attackers (SR 4.1 Information confidentiality). FR 5 Restricted data flow (RDF) The biggest change in practice. Every AI data flow is a conduit, often to an untrusted zone. Push-only or one-way designs and strict zone boundary protection matter (SR 5.1 Network segmentation, SR 5.2 Zone boundary protection). FR 6 Timely response to events (TRE) Attack timelines are getting shorter, so detection and response must keep up (SR 6.2 Continuous monitoring). AI helps with triage, but people must remain accountable for the response. FR 7 Resource availability (RA) AI workloads must not compete with control functions for bandwidth or compute (SR 7.2 Resource management). A failed or withdrawn AI service must fail safe, with a tested fallback to normal operation (SR 7.4 Control system recovery and reconstitution). Practical recommendations These are my recommendations, drawing on the guidance listed at the end. Revisit your SL-T assumptions. Re-run the threat part of your 62443-3-2 risk assessment with AI-assisted attackers in mind. Record the reasoning, whether or not the target changes. Treat AI services as conduits to untrusted zones. Every connection to a vendor cloud, model API or analytics platform gets a conduit definition, a named owner and boundary protection. Favour push-only or one-way designs. Ask suppliers hard questions. What AI features are in the product, and can the asset owner turn them off? Does it work without the vendor cloud? Where are models hosted? Will the software bill of materials (SBOM) cover AI components? How will you notify us of model changes or behaviour defects? The CISA guidance covers most of these. Control data flows to AI services. Decide which data can leave OT, in what form, to whom, and whether it can be used for training. Put that in the contract, not just the design. Bring models under management of change. Model versions, training data and prompts are configuration. Test changes off-line before they reach production. Keep a human in the loop. The CISA guidance says AI such as LLMs almost certainly should not be used to make safety decisions in OT, and recommends limiting active AI control without a human in the loop. My rule is simple: AI does not write to the control layer without engineering approval. No setpoint, logic or alarm changes unless a named engineer authorises them through the normal process. Keep safety separate. Safety instrumented functions stay independent of any AI function. AI failure modes, and how to bypass the AI, belong in your safety and incident response procedures. Log AI decisions. Record inputs, outputs and actions with timestamps, under an identity distinct from users and other systems, as the CISA guidance recommends. What to do this quarter List every AI function in, or connected to, your OT environment, including features built into products you already own. Mark each one on your zone and conduit drawings. If it isn't on the drawing, it isn't controlled. Re-test the threat assumptions behind SL-T for internet-reachable, remote-access and IT-connected zones. Send your main OT suppliers a short set of AI questions (features, cloud dependency, data use, SBOM, change notification, ability to disable). Add AI models, training data and prompts to your management of change procedure. Confirm in writing that no AI function can write to the control or safety layer without engineering approval. Check that AI activity is logged under its own identity and reaches your monitoring. Brief your team that licensed standards and sensitive engineering data must not be pasted into public AI tools. What is the standard, and what is my judgement From the standards: the SL 1 to SL 4 definitions, the SL-T, SL-C and SL-A distinction, the seven FRs and the SR titles (IEC 62443-3-3:2013, with component SL-C in IEC 62443-4-2:2019); SL-T set through risk assessment of zones and conduits (IEC 62443-3-2:2020); supplier development lifecycle (IEC 62443-4-1:2018). For asset owner security programmes, IEC 62443-2-1:2024 (edition 2.0) has replaced the 2010 edition. From published guidance: the threat trends (NCSC), the architecture, vendor, oversight and logging recommendations (CISA and partners), and the ISA and ISAGCA material cited. My judgement: that AI is compressing the skills and means axes of the SL definitions, the FR table above, treating AI services as untrusted-zone conduits by default, and the "no writes to the control layer without engineering approval" rule. ISA's November 2025 position paper, Industrial AI and Its Impact on Automation, also puts 62443 at the centre of securing AI-enabled systems, and I agree. Zones, conduits, target levels and the foundational requirements all still work. What AI changes is the threat we assume when we set targets, the number of conduits we manage, and the cost of sustaining a high level. Use the framework properly and AI fits within it. Sources UK National Cyber Security Centre, Impact of AI on cyber threat from now to 2027. https://www.ncsc.gov.uk/report/impact-ai-cyber-threat-now-2027 CISA, ASD's ACSC and partner agencies, Principles for the Secure Integration of Artificial Intelligence in Operational Technology (3 December 2025). https://www.cisa.gov/resources-tools/resources/principles-secure-integration-artificial-intelligence-operational-technology UK National Cyber Security Centre and CISA, Guidelines for secure AI system development. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign (13 November 2025). https://www.anthropic.com/news/disrupting-AI-espionage ISA Global Cybersecurity Alliance, ISA/IEC 62443 Quick Start Guide. https://isagca.org/hubfs/2023%20ISA%20Website%20Redesigns/ISAGCA/PDFs/ISAGCA%20Quick%20Start%20Guide%20FINAL.pdf ISA, ISA Explores Industrial AI's Impact on Automation in a New Position Paper (November 2025). https://www.isa.org/news-press-releases/2025/november/isa-explores-industrial-ai-s-impact-on-automation Kalaichelvi Easwaran, Securing New Threats: Industrial AI-Powered Applications and Autonomous Agents, ISA (October 2026). https://www-prod.isa.org/web/acom/article/securing-new-threats-industrial-ai-powered-applications-autonomous-agents Mohannad AlRasan, ISA/IEC 62443 and Risk Assessment: New Horizons in the AI Revolution, ISA (May 2024). https://www-prod.isa.org/web/acom/article/isa-iec-62443-risk-assessment-ai-revolution ISA, ISA/IEC 62443 Series of Standards. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards IEC Webstore: IEC 62443-2-1:2024, IEC 62443-3-2:2020, IEC 62443-3-3:2013, IEC 62443-4-1:2018, IEC 62443-4-2:2019. https://webstore.iec.ch/en/publication/62883