By: Steve Mustard, President & CEI of National Automation, Inc. & (CS)²AI Fellow, Khalid Ansari, Senior Engineer - Industrial Control Cybersecurity at FM Approvals and Jason Stiteler, Business Development Manager - IIoT & Cybersecurity at FM Approvals
Following the (CS)²AI roundtable on March 5th, 2025, we had several audience questions that we didn’t have time to answer. We’ve grouped the questions into the following categories and provided some responses:
· Questions about standards
· Questions about people and knowledge
· Questions about how certification works
· Questions about new technology
Questions about standards:
What criteria do you base your standards on? Yes, especially for the IACS.
ISA/IEC 62443 is a risk-based standard that has requirements defined in a consensus process by a group of more than 500 IACS subject matter experts from around the world, who work in all sectors and are asset owners, system integrators, product suppliers, consultants, and academics.
Is this a national or international accepted standards like the ones in accounting for example? Or still in the process to acceptance?
ISA/IEC 62443 is an international standard. The original editions of some parts were first published by the ISA99 committee in 2002. In 2010 they were renamed to 62443 and jointly published by ISA and IEC. IEC designated the series of standards as ‘horizontal’, meaning they are proven to be applicable to a wide range of different industries. The certification process evaluates conformity to this series of standards.
Critical assets may need to be governed by National standard, now IACS vendor if they follow only IEC62443 will that be a problem?
National IACS security standards, if they do exist, tend to refer to ISA/IEC 62443, for instance those in Qatar, Malaysia, and Saudi Arabia. In Europe the NIS2 Directive does not reference any specific standards but requires that organizations follow a risk-based approach to managing security. This can be demonstrated by conformity to ISA/IEC 62443.
Considering how important ICS security is, shouldn't all relevant standards be available for free? (ISO and IEC aren't)
Standards provide significant, but often unheralded, value to society and government. Many people are unaware that the global standardization system is a partnership between the public and private sectors – governments are not the owners of the documents, nor are they primary stakeholders in the process.
If standards are made freely available, the cost to support their development must come from participation fees, which most standards development organizations (SDOs) keep intentionally low to encourage the broadest possible participation. In fact, it is free to participate in ISA standards development – this ensures that we have the maximum amount of technical expertise from all over the world. This model stands in contrast to the open-source standards environment where the end product is free, but the few major players who can afford to pay steep membership fees drive the technical work.
By funding operations at least in part through sales and licensing of standards, SDOs can minimize barriers to qualified participation and maximize independence from entities seeking to influence the outcome for commercial or political reasons. Maintaining the current model for standards development keeps the system flexible and driven by the needs of the marketplace.
The question implies that standards like ISA/IEC 62443 are a significant cost barrier. The truth is the cost is negligible to any organization that is involved in managing IACS security risk. Many organizations have access to standards through subscription services.
Members of ISA get access to ISA standards. Annual ISA membership ranges from $15 for students, to $77 for eligible countries, and $154 for all others. There are so many legitimate ways to access these standards that we should stop asking why they aren’t free and instead focus on promoting and mandating them.
Questions about people and knowledge:
Most people in OT security they are not really expert at process and design engineering whatever industry they are working in, they just come up with checklist and they hardly go in-depth.
This is a good point, and why formal conformity programs that are based on international standards are so important. Custom checklists are only as good as the input that goes into them, and there is very little chance of being able to compare results across industries or countries using such a method.
I believe one better be good at understanding DCS, PLCs, networks and industry specific knowledge such as chemical engineering experience or degree if in industry. Provide you inputs please. Thank you
Yes, very good point. People involved in IACS design, development, maintenance or conformity assessment need to have a good understanding of the operating environment, the safety and operational aspects, and a good grounding in instrumentation and control practices and technology. ISASecure® Conformity Assessment Bodies are mandated by the certification scheme to employ people with this broad skill base as well as IACS-specific experience so that they are able to do thorough evaluations.
Are personnel trained? Are there only allowed device connecting?
In the case of both questions, the answer is that the ISA/IEC 62443 series of standards includes requirements for personnel training and for the management of device connections (permanent, temporary, and remote). These aspects are evaluated during a conformity assessment.
Questions about how certification works:
Companies and asset owners often consider standards and compliance as additional cost and work. They sometimes limit compliance to producing the minimum set of documents. How to counter that and ensure that the minimum controls are actually implemented even by smaller asset owners and operators?
The ISA/IEC 62443 series of standards is risk based, which means it is possible for any sized asset owner or operator to choose the controls that allow them to manage their risk to tolerable levels. The standards series defines four levels of security, 1 through 4, that require progressively more controls to manage greater risk. The risk assessment process defined in ISA/IEC 62443-3-2 allows asset owners and operators to clearly quantify their risks and determine the appropriate response that suits their organization, rather than a generic set of controls that may be excessive or inadequate.
The challenge with IEC 62443 standard is that the SL is based on the threat. If an organization threat profile is defending against Nation State, no product or system today exist that can have SL4. The best in the market today is SSA SL2?
The ISA/IEC 62443 series of standards base SL-T (Security Level - Target) on risk, not threat. Obviously, threat is part of the risk equation, but it is not the only part. Consequence is probably the most significant element of risk for an asset owner. That said, the SL-C (Security Level - Capability) is defined in terms of protection against a given level of threat. There are ongoing discussions in the joint ISA/IEC committee to review this approach. It is true that few components or systems have a certified SL-C of SL3 or SL4. However, an asset owner can have an SL-A (achieved) of SL3 or SL4 for their IACS by applying additional controls on top of the capability of the components or system. As noted in the roundtable, asset owners should demand higher levels of SL-C so that the additional controls they need to apply can be reduced.
How do the vulnerabilities affect the products?
Vulnerabilities offer opportunities for the bad actors to exploit them, leading to compromising of the product and potentially the larger system. Product vulnerabilities increase overall asset owner risk. Products are not the only element of an IACS that has vulnerabilities. Processes and people also have vulnerabilities. All of these need to be managed by a comprehensive risk-based security program. ISA/IEC 62443 identifies the controls that are needed to manage all of these risks.
ISASecure is at component level, good, how do we achieve compliance of entire IACS which may involve multiple systems and who will certify that the system is compliant?
ISASecure conformity assessment programs currently exist for product suppliers: Secure Development Lifecycle Assurance – SDLA; Component Security Assurance – CSA; System Security Assurance – SSA. A new program, Automation and Control System Site Assurance – ACSSA – is under development and will be launched in 2025. This will provide conformity assessment against the entire operational IACS environment.
What leverage do I have as an asset owner to incorporate secure by design when purchasing complete control systems from an integrator?
You have a lot of leverage as you are the customer. You can mandate that components and systems are certified to have a particular SL-C. In order to do this, you should perform a risk assessment in accordance with ISA/IEC 62443-3-2 and identify your SL-T for all zones in your IACS. You could make this part of the scope of the overall project. You can also require that service providers demonstrate conformity to ISA/IEC 62443-2-4.
If you check today ISASecure website for Honeywell or Yokogawa SSA Certificate? It’s based on their architecture. which means Controller, application, communication card, network switches, and that’s all. While the actual deployment there are other systems and applications included as part of the system such as Advanced Process Control, PI, and others. These introduce new attack surface which make the certificate not valid or not enough. the SSA certificate need to clearly define the minimum system architecture that should be certified? Another example is the integration between BPC and SIS? this usually not included as part of SSA certificate? basically not in the scope of the certificate. Can the panelist shed some light on this?
SSA certification requires that the product supplier provide reference architectures to be considered as in-scope during the assessment. These architectures, ideally, would reflect the common architecture that gets deployed in the field. SSA certification evaluates the security capabilities of the product (SL-C). It does not necessarily guarantee that all the security controls get configured and utilized when the system is deployed. When deployed in a wider IACS, the ACSSA would provide assurance that the complete IACS is conformant to ISA/IEC 62443.
How does Update Management deal with the Secure Product Development Lifecycle?
The secure product development lifecycle requirements (defined in ISA/IEC 62443-4-1) include update management. Providing timely and tested updates for vulnerabilities discovered in products are an essential part of the product’s lifecycle. Service provider requirements (ISA/IEC 62443-2-4) also include requirements in this area.
What of the product dev lifecycle is typically made public?
Product suppliers who achieve SDLA receive a certificate to confirm they are in conformance with ISA/IEC 62443-4-1. No product supplier specific details are made public.
Can the panelists comment on the differences between (ISO) Common Criteria and the SDLA cert discussed now?
There are some similarities in the approach between ISO/IEC 15408 and ISA/IEC 62443. ISA/IEC 62443 has been specifically designed to address the requirements of industrial automation and control systems whereas ISO/IEC 15408 is very generic, covering the security properties of IT products and systems.
As for the methodology, under the Common Criteria, sets of desired security features are defined in various Protection Profiles. An end-user may select a certain Protection Profile and request evaluation of a product against that profile. So, a Common Criteria certified product would very much depend on the Protection Profile that it was evaluated for, i.e., it would have only been evaluated for those security features that are defined in the Protection Profile. Whereas with ISASecure 62443 certification, all the Foundational Requirements are evaluated at the given Security Level.
How will SDLA fit into DevOps and SAFe?
Agile frameworks and concepts like DevOps and SAFe can be assessed against SDLA. The requirements are defined in ISA/IEC 62443-4-1. If a product supplier using DevOps and/or SAFe can demonstrate that it meets these requirements it can be certified.
I heard from Andrew Kling the maturity level was removed from the latest SDLA certification Scheme? why? it used to be SDLA with maturity Level. Now, the maturity Level has been removed?
ISASecure® does not indicate the maturity level on the SDLA certificate any longer. However, the maturity of the manufacturer’s organization is still assessed, i.e., the documented policies and procedures are consistently practiced, which would equate to ML3. Indicating the maturity level on the certificate had the potential of being misunderstood (and misused). For instance, an end user would see the SDLA certificate and may assume the organization is fully compliant with 62443-4-1 while not paying attention to the “ML” (ML1, for example) on the certificate. A Maturity Level 1 is where product development happens in “an ad hoc and often undocumented (or not fully documented) manner”.
What are the biggest challenges you see as of today with deployment of OT scanning process within ICS? Especially since neither IEC 62443 nor NIST 800-82 explicitly require it; however, do recommend it as a comprehensive set of cyber programs?
ISA/IEC 62443 does not typically mandate any particular product or method. It is a risk-based series of standards that defines controls and methods to manage security risk in IACS environments. Asset owners may choose to use products or techniques to inform them or support them in identifying vulnerabilities for risk assessment or testing controls as part of implementation. Those products and techniques will change over time, but the overall objective – to manage risk – will not change. With the proliferation of such tools in the market, it may be tempting to consider them a silver bullet—which there is none of in cybersecurity.
Questions about new technology:
How is influence of AI so far in OT industry?
Generally speaking, AI is being used in various aspects in OT, from GenAI analyzing documents, through to ML for predictive maintenance. In OT security, AI plays a part in threat detection and is widely used by SOCs.
ISAGCA will soon be publishing a report on a study on AI risks in critical infrastructure.
I'd be interested in hearing how IT/OT employees are using AI in their day to day now whether you're in manufacturing, or utilities, or transportation. And with AI, does that help with Cybersecurity?
See above response. AI can help by reducing the burden on people, freeing them up to do more targeted activities.
Where are you guys relative to the broader market motion around Post Quantum Encryption - has this kept into the discussion yet?
Post quantum encryption will change risk profiles for asset owners. They should be regularly re-assessing their risk, taking into account changes in threats, vulnerabilities, and consequences. As a result, an asset owner who is conformant with ISA/IEC62443 will be adjusting their controls as needed to manage any change in risk.
If you need more information or have any additional questions related to these topics, please contact Jason Stiteler (FM Approvals, Business Development Manager, Industrial Control Cybersecurity) at jason.stiteler@fmapprovals.com.
Comments