For decades, cybersecurity has been something of an arms race. Attackers search for weaknesses in computer systems, while defenders try to identify and eliminate them before attackers can exploit them. Both sides have traditionally been constrained by the availability of skilled people, the complexity of the technology, and the time required to discover and exploit vulnerabilities. Artificial intelligence (AI) is beginning to change that equation.
In April 2026, Anthropic announced Project Glasswing, an initiative bringing together major technology organizations to use an advanced AI model, Claude Mythos Preview, to identify and address software vulnerabilities. The results have been remarkable. By October 2026, Project Glasswing participants had reportedly identified at least 129,000 verified software vulnerabilities, including tens of thousands classified as high or critical severity. These findings show that AI can dramatically accelerate the discovery of weaknesses in software organizations have relied on for years, sometimes decades.
For operational technology (OT), the implications are particularly significant. Industrial control systems operate manufacturing facilities, power generation and distribution networks, water and wastewater treatment plants, oil and gas infrastructure, transportation systems, and other essential services. Many of these systems run software developed years ago, use older operating systems, and cannot be updated as easily as conventional information technology (IT).
An attacker who compromises an IT system might steal information or disrupt business operations. An attacker who compromises an OT system could interrupt production, damage equipment, contaminate products, disrupt essential services, or potentially create conditions that threaten human safety.
The emergence of AI tools that can discover and exploit software vulnerabilities at unprecedented speed should therefore be a considerable concern for industrial asset owners and technology suppliers. However, it does not mean that the industry needs to invent an entirely new approach to cybersecurity. The ISA/IEC 62443 series of standards already provides a comprehensive, internationally recognized framework for managing industrial automation and control system cybersecurity throughout the system and product lifecycles.
The challenge is ensuring organizations implement its requirements at a pace appropriate to the changing threat environment.
What are Claude Mythos and Project Glasswing?
Although closely related, Claude Mythos and Project Glasswing are different. Claude Mythos is an AI model. Project Glasswing is an initiative that uses the model to improve cybersecurity.
Claude Mythos is a family of advanced AI models developed by Anthropic. Unlike traditional vulnerability scanners, which typically identify known vulnerabilities or predefined patterns of insecure software, Mythos-class models can analyze complex software, reason about how its components interact, identify previously unknown weaknesses, and develop ways to demonstrate their exploitability.
Traditional vulnerability management has relied heavily on databases of known vulnerabilities, such as Common Vulnerabilities and Exposures (CVE), along with software patches and security advisories. However, these approaches cannot identify every vulnerability that has not yet been discovered or publicly disclosed.
AI systems that can analyze software and identify previously unknown vulnerabilities could significantly change this situation. In announcing Project Glasswing, Anthropic reported that Mythos Preview had identified thousands of previously unknown vulnerabilities, including weaknesses in major operating systems and web browsers. Some had existed for decades without being discovered. The significance is not simply that AI can find more vulnerabilities. It is that AI may dramatically reduce the time, cost, and specialized expertise needed to discover them. This capability offers substantial benefits to defenders, but it also creates risks if malicious actors gain access to similar technology.
Project Glasswing was launched in April 2026 to apply Mythos’s capabilities to defensive cybersecurity. Its founding participants included major technology companies responsible for widely used software, hardware, cloud infrastructure, and cybersecurity products. The initiative initially provided selected organizations with controlled access to Mythos Preview so they could identify and remediate vulnerabilities in their own products and infrastructure. In June 2026, Anthropic expanded the program to approximately 150 additional organizations, including participants involved in power, water, healthcare, communications, and hardware infrastructure.
In October, Anthropic announced an expanded Cyber Verification Program, offering qualifying security professionals access to advanced models, including Claude Mythos 5.1. According to reporting published in October, Project Glasswing participants had identified at least 129,000 verified vulnerabilities between April and July 2026. More than 33,000 vulnerabilities identified through the broader reported efforts had been classified as high or critical severity.
These figures represent findings across a wide range of software and infrastructure, not specifically industrial control systems. They should not be interpreted as evidence that thousands of industrial systems have already been compromised. Nevertheless, the underlying capability has clear implications for OT.
The central concern is that capabilities currently being used to identify vulnerabilities defensively could eventually become available to attackers.
Why this matters more for OT than conventional IT
Industrial automation and control systems have several characteristics that make AI-enabled vulnerability discovery particularly concerning.
Industrial systems have long operational lifetimes. Many industrial facilities operate equipment for 15, 20, or even 30 years. A programmable logic controller (PLC) installed today might remain operational long after its original operating system, software libraries, or communications protocols have become obsolete. Industrial asset owners frequently operate a mixture of modern and legacy technologies, some of which may no longer receive security updates. These systems may contain vulnerabilities that have remained undiscovered for many years. The emergence of Mythos-class capabilities raises the possibility that previously unknown vulnerabilities in these systems could be discovered much more quickly. A vulnerability that has existed harmlessly for 20 years is not necessarily harmless once someone discovers how to exploit it.
This reinforces the importance of ISA/IEC 62443-2-1, which establishes requirements for an asset owner’s industrial automation and control system security program, including asset management, risk management, vulnerability management, and ongoing security activities. It also highlights the importance of ISA/IEC 62443-3-2, which addresses cybersecurity risk assessment and system design. Asset owners need to understand not only which systems they operate, but also the potential consequences if those systems are compromised.
Patching is often difficult or impossible. In conventional IT environments, installing security patches may be relatively straightforward. Industrial environments are different. A software update might require a production shutdown, introduce compatibility problems, invalidate a tested configuration, or interfere with equipment that performs a critical safety or operational function. Some industrial systems can only be updated during scheduled maintenance outages, which may occur months apart. Others may depend on products that are no longer supported by their manufacturers. If AI substantially accelerates vulnerability discovery, asset owners may face an increasing number of vulnerabilities that require attention without the ability to patch them immediately.
This makes compensating controls especially important. ISA/IEC 62443-3-3 provides system security requirements, including restricted data flow, access control, system integrity, and availability. These requirements can help organizations reduce exposure even when they cannot update individual components.
For example, a vulnerable controller that cannot be patched might still be protected through appropriately designed network segmentation, restricted remote access, monitoring, and other compensating measures. However, these controls must be evaluated against the actual risk. A firewall does not automatically make an insecure controller safe, particularly if an attacker can gain access through an authorized communications path.
Industrial consequences extend beyond data loss. Perhaps the most important difference between IT and OT cybersecurity is the nature of the consequences. Consider a vulnerability in a web application used for online retail. Exploitation might result in stolen customer information or interrupted transactions. Now consider a vulnerability in a controller responsible for maintaining pressure in a chemical processing facility. If exploited, the consequences could include damaged equipment, an uncontrolled release, or a serious safety incident.
The risk assessment process described in ISA/IEC 62443-3-2 considers threats, vulnerabilities, likelihood, and consequences to determine appropriate cybersecurity protection requirements. AI-enabled attacks may change the likelihood side of this equation. It does not necessarily change the physical consequences of a successful attack. A pump can still fail the same way, whether the attacker used conventional techniques or AI. However, if AI makes certain attacks easier to develop and execute, the probability of those consequences occurring may increase.
Organizations should therefore revisit existing cybersecurity risk assessments to determine whether assumptions about attacker capability and exploitability remain valid. Importantly, this does not mean that every system automatically requires a higher security level.
ISA/IEC 62443-3-2 establishes a risk-based approach for determining target security levels. Any changes should follow an evaluation of credible threats, system vulnerabilities, existing protections, and potential consequences.
What could Mythos-class capabilities mean in practice?
The following examples illustrate plausible OT scenarios. They are not claims that Claude Mythos has been used to execute these attacks.
Example 1: Discovering Vulnerabilities in PLC Firmware
A PLC manufacturer has produced a family of controllers for many years. The controllers are widely deployed in manufacturing plants, water utilities, and energy facilities. Their firmware includes communications services, protocol implementations, and software libraries developed over several generations. Historically, identifying a vulnerability in this firmware might require considerable specialist knowledge, reverse engineering, and manual analysis.
An AI system with Mythos-class capabilities could accelerate firmware analysis and identify weaknesses that previous testing missed. An attacker who discovered such a vulnerability might be able to interfere with controller communications, cause a denial of service, or, depending on the weakness and available privileges, manipulate controller operation.
For the manufacturer, this scenario highlights the importance of ISA/IEC 62443-4-1, which establishes secure product development lifecycle requirements. Manufacturers need effective processes for security requirements, secure design, implementation, verification and validation, defect management, and security update management.
ISA/IEC 62443-4-2 complements these processes by establishing technical security requirements for industrial automation and control system components. Manufacturers should assume that attackers will become increasingly capable of examining their products for vulnerabilities, including weaknesses that have escaped conventional testing.
Example 2: Exploiting an Engineering Workstation
An engineering workstation is used to configure controllers, modify control logic, and maintain industrial automation systems. It may contain specialized engineering software, communications drivers, and libraries that interact with industrial equipment. An attacker gains access to the workstation through a compromised remote connection or malicious software. AI-assisted analysis identifies a vulnerability in the engineering application or one of its supporting components.
Exploitation could allow the attacker to obtain additional privileges or interfere with the software used to configure industrial equipment. Depending on the system architecture and existing protections, the attacker might then attempt unauthorized changes to controller configurations or control logic.
This scenario illustrates why cybersecurity cannot be addressed solely at the individual component level. ISA/IEC 62443-3-2 requires consideration of system architecture, including the division of systems into zones and conduits. ISA/IEC 62443-3-3 provides requirements that can support protection against unauthorized access, unauthorized modifications, and inappropriate communications between systems. Engineering workstations should not automatically have unrestricted access to every controller in a facility simply because that arrangement is convenient.
Example 3: Compromising a Remote Access Gateway
Remote access is increasingly important for industrial operations. Equipment suppliers, system integrators, and maintenance contractors frequently require remote connectivity to diagnose faults, update software, or support operational personnel.
Consider an industrial remote access gateway deployed across hundreds of facilities. An AI system identifies a previously unknown vulnerability in the gateway’s software. If the vulnerability permits unauthorized access, an attacker could potentially exploit multiple installations using the same product.
The consequences would depend on how the gateway was deployed and what systems it could reach. A gateway connected to a tightly controlled maintenance zone presents a different risk from one providing broad access to an entire control network. This is where several parts of ISA/IEC 62443 become particularly relevant:
- ISA/IEC 62443-2-4 addresses security requirements for industrial automation and control system service providers.
- ISA/IEC 62443-3-3 addresses system-level security capabilities.
- ISA/IEC 62443-4-2 addresses component-level technical requirements.
Together, these standards support a more comprehensive approach to remote access security involving the product supplier, service provider, and asset owner.
Example 4: A Vulnerability in a Water Treatment System
A municipal water utility operates a supervisory control and data acquisition (SCADA) system that monitors reservoir levels, pumping stations, chemical dosing, and distribution pressures. Some equipment is more than 15 years old. An AI-assisted attacker discovers a vulnerability in software used by the utility’s SCADA infrastructure.
Depending on the vulnerability and system design, the attacker might attempt to disrupt monitoring, interfere with communications, or manipulate control functions. The operational consequences could range from temporary loss of visibility to interruptions in water service or unsafe process conditions. However, the outcome would also depend on the utility’s engineering safeguards.
Independent protective devices, mechanical pressure relief, appropriate chemical dosing safeguards, and the ability to operate equipment locally could substantially reduce the consequences of a cyber incident.
This illustrates an important principle: Cybersecurity is not simply about preventing an attacker from gaining access. It is also about ensuring that a successful cyberattack does not automatically become a major operational or safety incident.
ISA/IEC 62443-3-2 supports this approach through consequence-based risk assessment. ISA/IEC 62443-3-3 includes requirements addressing system integrity, availability, and resource management.
Where safety instrumented systems are involved, cybersecurity considerations must also be coordinated with functional safety requirements, including those addressed by IEC 61511.
The 4 implications for OT product manufacturers
For industrial technology manufacturers, Project Glasswing should be treated as an important signal that the assumptions underlying traditional software security testing are changing. A product that has operated for years without a reported vulnerability is not necessarily secure. It may simply not have been examined with sufficiently capable tools.
AI-assisted vulnerability discovery increases the importance of adopting a systematic secure development lifecycle.
1. Secure development must become a continuous activity
ISA/IEC 62443-4-1 provides a foundation for addressing cybersecurity throughout the product lifecycle. Manufacturers should ensure that their development processes include threat modeling, secure design, secure coding, security testing, vulnerability management, and security update procedures.
AI-assisted analysis can potentially strengthen these activities. For example, manufacturers could use appropriate AI-based tools to identify weaknesses in source code, review software dependencies, analyze firmware, and support security testing. However, AI-generated findings require validation. False positives, incorrect assumptions, and proposed changes that introduce new operational problems remain important concerns.
For industrial products, a security fix must not compromise reliability, deterministic behavior, functional safety, or essential operational capabilities. Consequently, AI-assisted testing should supplement established engineering and verification processes, not replace them.
2. Vulnerability management must be faster and more effective
ISA/IEC 62443-4-1 includes requirements for managing security-related issues throughout the product lifecycle. Manufacturers need processes to receive vulnerability reports, assess their significance, develop corrections, communicate with customers, and provide updates. As AI accelerates vulnerability discovery, manufacturers may face increasing volumes of vulnerability reports. The challenge will not simply be finding vulnerabilities. It will be determining which vulnerabilities are genuine, which products are affected, what operational consequences could result, and how customers should respond.
A conventional severity score alone may be insufficient for industrial applications. A vulnerability rated critical in a product isolated from external networks may present a different operational risk than a moderate-severity vulnerability in an internet-accessible industrial gateway.
Manufacturers should provide enough information for asset owners to perform meaningful risk assessments consistent with ISA/IEC 62443-3-2. This includes affected versions, exploit prerequisites, potential consequences, available mitigations, and update instructions.
3. Software supply chain security becomes more important
Modern industrial products frequently incorporate third-party software libraries, operating systems, and open-source components. A vulnerability in one widely used library could affect products from numerous manufacturers. AI-assisted vulnerability discovery could expose previously unknown weaknesses in these shared dependencies.
Manufacturers therefore need accurate visibility into the software components incorporated into their products. Software bills of materials (SBOMs) can support this objective, although producing an SBOM is not, by itself, proof of security. ISA/IEC 62443-4-1 provides the secure development and maintenance framework within which software component management and vulnerability response should operate.
Manufacturers should also assess how their products satisfy the applicable technical requirements of ISA/IEC 62443-4-2.
For products placed on the European Union market, these activities also support preparation for the Cyber Resilience Act (CRA), which introduces mandatory cybersecurity requirements for products with digital elements.
Although ISA/IEC 62443 compliance does not automatically establish CRA conformity, alignment with the relevant parts of the standard can provide a valuable foundation for demonstrating secure development, vulnerability handling, and appropriate product security capabilities.
4. Independent verification provides additional assurance
Manufacturers should also consider independent assessment and certification against relevant ISA/IEC 62443 requirements. The ISASecure certification schemes provide mechanisms for independent evaluation of industrial automation and control system products and development processes.
For example, the ISASecure Secure Development Lifecycle Assurance (SDLA) scheme addresses development processes based on ISA/IEC 62443-4-1, while component security certification addresses applicable requirements derived from ISA/IEC 62443-4-2.
Certification cannot guarantee that a product contains no vulnerabilities. However, it can provide independent evidence that appropriate security processes and technical requirements have been evaluated.
In an environment where AI may discover previously unknown vulnerabilities at increasing speed, confidence in the manufacturer’s ability to manage vulnerabilities throughout the product lifecycle becomes particularly important.
The 6 implications for OT asset owners
Asset owners face a different challenge. They generally do not control the software development practices of the products they purchase. They may also have limited influence over when manufacturers release security updates. Their responsibility is to understand and manage the risks associated with deploying and operating those products. ISA/IEC 62443 provides a structured approach to meeting that responsibility.
1. Reassess cybersecurity risk.
The priority should be to review existing cybersecurity risk assessments. Organizations should consider whether their assumptions about attacker capabilities remain reasonable.
For example, an assessment completed several years ago might have concluded that exploitation of a particular vulnerability was unlikely because it required specialist knowledge and considerable effort. AI-assisted vulnerability discovery may change that assumption.
Asset owners should revisit the risk assessment process established in ISA/IEC 62443-3-2, paying particular attention to systems where successful compromise could result in serious safety, environmental, operational, or financial consequences.
The objective is not to increase every risk rating automatically. It is to ensure that decisions reflect current threats, credible attack scenarios, existing protections, and realistic consequences.
2. Understand the installed asset base.
Organizations cannot effectively manage vulnerabilities in equipment they do not know they possess. A reliable asset inventory should identify key hardware and software components, their versions, locations, operational functions, and support status. It should also identify dependencies between systems.
This is particularly important where multiple industrial products incorporate the same vulnerable software component. ISA/IEC 62443-2-1 provides the basis for establishing and maintaining appropriate asset management processes.
Asset inventories should support vulnerability management and risk assessment, not exist merely as administrative records.
3. Strengthen zones and conduits.
One of the most important architectural concepts in ISA/IEC 62443-3-2 is dividing industrial systems into zones and conduits. Zones group assets with common security requirements, while conduits define and control communications between zones. This approach becomes increasingly important as attackers gain access to more sophisticated vulnerability discovery tools.
If a vulnerability is discovered in one component, the system architecture should limit the attacker’s ability to use that weakness to compromise other systems.For example, compromising an operator workstation should not automatically provide unrestricted access to safety-related systems, engineering workstations, or every controller in the facility. Appropriate segmentation, access controls, and communications restrictions can significantly reduce the potential consequences of individual vulnerabilities.
These measures should be designed using the risk assessment and target security levels established through ISA/IEC 62443-3-2 and implemented using applicable requirements from ISA/IEC 62443-3-3.
4. Improve vulnerability and patch management.
Asset owners should establish processes to receive security advisories, determine whether vulnerabilities affect installed equipment, evaluate operational risk, and implement appropriate mitigations. Where patches are available, their deployment should be planned and tested to avoid unintended operational consequences. Where patches cannot be applied promptly, compensating measures may be necessary. These could include restricting communications, disabling unnecessary services, limiting remote access, increasing monitoring, or introducing additional independent protections. The appropriate response depends on the system and the consequences of compromise
ISA/IEC 62443-2-1 provides the organizational framework for managing these activities, while ISA/IEC 62443-3-3 supports implementing technical protections.
5. Strengthen incident response and operational recovery.
One of the most important implications of AI-enabled attacks is the potential reduction in the time available to detect, contain, and respond to an incident. Asset owners should not assume that prevention will always succeed.
They must also be prepared to maintain safe operations and recover when cybersecurity controls fail. ISA/IEC 62443-2-1 addresses incident management and response as part of the asset owner’s security program. ISA/IEC 62443-3-3 includes requirements related to availability, backup, and recovery. Industrial incident response plans should answer practical questions. What happens if the SCADA system becomes unavailable? Can operators continue to control the process locally? Are current backups available for engineering workstations, controller configurations, and application software? Can those backups be restored successfully? Are independent safety protections available if normal control functions are compromised? Who has authority to shut down equipment? Who contacts the equipment manufacturer? Who decides whether operations can safely resume?
Most importantly, when were these procedures last tested? An incident response plan that has never been exercised provides limited assurance that the organization can respond effectively.
Organizations should conduct regular exercises involving operations personnel, maintenance teams, engineering staff, cybersecurity specialists, management, and relevant suppliers. These exercises should include scenarios where digital systems are unavailable or cannot be trusted. The ability to restore equipment from verified backups, run essential processes manually, and rely on independent mechanical or electrical safeguards can be as important as detecting malicious software.
6. Require better security assurance from suppliers.
Asset owners should also reconsider their procurement requirements. Purchasing decisions should evaluate more than functionality, price, and delivery schedules. Suppliers should be asked to demonstrate how their development processes align with ISA/IEC 62443-4-1 and how their products satisfy applicable ISA/IEC 62443-4-2 requirements. They should also explain how vulnerabilities are reported, investigated, corrected, and communicated.
Important questions include the duration of product security support, the availability of security updates, the management of third-party software dependencies, and the procedures for responding to newly discovered vulnerabilities.
Independent certification through an appropriate ISASecure scheme can provide additional assurance. These requirements should apply not only to new products but also, where practical, to existing suppliers supporting critical systems.
What should organizations do now?
The emergence of Project Glasswing does not justify abandoning established cybersecurity practices. Instead, it reinforces the need to implement them properly. For OT asset owners, immediate priorities should include reviewing consequence-based risk assessments, identifying critical and unsupported assets, strengthening system segmentation, improving vulnerability management, and testing incident response and recovery capabilities.
For OT product manufacturers, priorities should include strengthening secure development practices, expanding security testing, improving software supply chain visibility, accelerating vulnerability handling, and providing customers with actionable security information.
For system integrators and service providers, the priority should be to ensure that systems are designed, deployed, maintained, and supported in accordance with appropriate cybersecurity requirements. These responsibilities correspond closely to the structure of ISA/IEC 62443:
- ISA/IEC 62443-2-1: Asset owner cybersecurity management programs.
- ISA/IEC 62443-2-4: Security requirements for service providers.
- ISA/IEC 62443-3-2: System security risk assessment and design.
- ISA/IEC 62443-3-3: System security requirements and security levels.
- ISA/IEC 62443-4-1: Secure product development lifecycle requirements.
- ISA/IEC 62443-4-2: Technical security requirements for industrial automation and control system components.
These standards address complementary responsibilities across the industrial cybersecurity lifecycle. None is sufficient in isolation.
A securely developed product can still be deployed insecurely. A well-designed industrial network can still be compromised through poor maintenance practices. An effective security management program cannot compensate indefinitely for products that contain serious unaddressed vulnerabilities.
The strongest protection comes from applying the relevant parts of ISA/IEC 62443 together.
The bigger picture: AI changes the economics of cyberattacks
Perhaps the most important implication of Claude Mythos is that AI could fundamentally change the economics of discovering and exploiting software vulnerabilities. Historically, sophisticated attacks against industrial systems have often required substantial resources, specialized expertise, and considerable preparation. This has provided some degree of practical protection for organizations whose systems were difficult to understand or attack. However, complexity is not a security control.
If AI reduces the cost and effort of discovering vulnerabilities, some attacks that were previously impractical may become economically attractive. This does not mean that every attacker will suddenly be capable of compromising a power station or chemical plant. Industrial attacks still require access, an understanding of the target environment, and the ability to influence physical processes. Safety systems, operational constraints, and engineering safeguards can substantially complicate an attack. Nevertheless, the balance between attacker capability and defensive effort may be shifting.
This makes the distinction between cybersecurity and cyber resilience increasingly important. Cybersecurity seeks to prevent, detect, and respond to unauthorized activity. Cyber resilience considers an organization's ability to continue essential operations, limit the consequences of compromise, and recover safely. For industrial organizations, both are essential.
The ISA/IEC 62443 series provides a foundation for addressing these challenges through risk-based security management, secure system architecture, product security, and lifecycle processes. However, effective implementation requires coordination with broader engineering disciplines, including process safety, functional safety, reliability, maintenance, and business continuity.
Conclusion: the standards exist; the urgency has changed
Project Glasswing and Claude Mythos represent an important development in cybersecurity. They demonstrate that AI can identify software vulnerabilities at a scale and speed that would have been difficult to imagine only a few years ago. For industrial asset owners and technology manufacturers, this creates both an opportunity and a warning.
The opportunity is to use increasingly capable technologies to discover and eliminate vulnerabilities before attackers can exploit them. The warning is that attackers may eventually gain access to similar capabilities.
Industrial organizations cannot assume their systems are too obscure, too complex, or too difficult to attack. Nor can they assume that software that has operated without incident for decades is free from serious vulnerabilities. Fortunately, the industrial cybersecurity community does not need to start from scratch.
ISA/IEC 62443 already establishes a comprehensive framework for managing cybersecurity across industrial systems, products, and organizations. The priority is to apply that framework consistently, verify that the required protections are effective, and adapt risk assessments as threats evolve.
For asset owners, this means understanding operational consequences, reducing exposure, and preparing to respond and recover. For product manufacturers, it means developing secure products, maintaining them throughout their supported lifetimes, and responding effectively when vulnerabilities are discovered.
Project Glasswing may mark the beginning of a new era in vulnerability discovery. The fundamental principles of industrial cybersecurity have not changed. What has changed is how quickly organizations may need to apply them.
References
1. Anthropic. Project Glasswing: Securing Critical Software for the AI Era. April 7, 2026; updated October 6, 2026. Project Glasswing announcement
2. Anthropic. Expanding Project Glasswing. June 2, 2026. Project Glasswing expansion
3. Reuters. Anthropic Opens Its Most Powerful AI Models to More Security Teams. October 6, 2026. Reuters report
4. International Society of Automation / International Electrotechnical Commission. ISA/IEC 62443-2-1: Security for Industrial Automation and Control Systems—Security Program Requirements for IACS Asset Owners.
5. International Society of Automation / International Electrotechnical Commission. ISA/IEC 62443-2-4: Security for Industrial Automation and Control Systems—Security Program Requirements for IACS Service Providers.
6. International Society of Automation / International Electrotechnical Commission. ISA/IEC 62443-3-2: Security for Industrial Automation and Control Systems—Security Risk Assessment for System Design.
7. International Society of Automation / International Electrotechnical Commission. ISA/IEC 62443-3-3: Security for Industrial Automation and Control Systems—System Security Requirements and Security Levels.
8. International Society of Automation / International Electrotechnical Commission. ISA/IEC 62443-4-1: Security for Industrial Automation and Control Systems—Secure Product Development Lifecycle Requirements.
9. International Society of Automation / International Electrotechnical Commission. ISA/IEC 62443-4-2: Security for Industrial Automation and Control Systems—Technical Security Requirements for IACS Components.
10. International Society of Automation. ISASecure Certification Programs. ISASecure
