This post is the second part of a series of three blog posts, where we discuss the impacts of the new EU Cyber Resilience Act (CRA) and compare it briefly to the industrial cybersecurity standard IEC 62443.
If you haven’t read Part 1 of the series yet, then you can check it out here. It introduces the requirements of the act. Finally in Part 3, we will discuss what the act means in practice, including such impacts that the act does not directly spell out but that are likely to be relevant for product manufacturers and cybersecurity practitioners.
In this Part 2, we will compare the Cyber Resilience Act to the IEC 62443 series of standards on a high level. Now, why would we do this comparison? Isn’t this a comparison of apples and oranges? These two texts have a different status, scope, and purpose. The EU may also define its own standards that could be used instead of IEC 62443 to work out the details of how to comply with the Cyber Resilience Act. However, from the point of view of an industrial product manufacturer, this is still a relevant comparison, especially if they have already invested in compliance with IEC 62443.
What is IEC 62443
IEC 62443 is a series of industrial cybersecurity standards originally written for industrial automation and control systems but nowadays applied quite widely in the industrial context. IEC 62443 is not usually applied outside the industrial context, so it might not be relevant for you. In that case, you can skip the rest of this post and wait for the final part 3 of the series.
The most commonly used parts of the IEC 62443 standard are listed below. While the standard includes some other less commonly referenced parts, it is these three parts that are the most relevant to product manufacturers and the most closely related to the Cyber Resilience Act.
- IEC 62443 Part 4-1 defines Secure Development Lifecycle Assurance requirements for product development teams. The requirements cover all phases of the product development life cycle, and they also include vulnerability handling and documentation requirements. The standard also includes a maturity model, so you can start building up the maturity of the organisation gradually.
- IEC 62443 Part 4-2 defines a set of functional security capability requirements for individual products or components. The requirements have been divided into four security levels, to enable gradual implementation and certification.
- IEC 62443 Part 3-3 defines a similar set of functional security capability requirements for industrial solutions that are comprised of several components. It also divides the requirements into four security levels.
The following diagram illustrates these three key parts of the IEC 62443 standard.
Different approaches
The requirements in these IEC 62443 standards share a lot of similarities with the CRA, but there are also notable differences. In this blog post, we don’t have space for a detailed breakdown, so let’s highlight the most noteworthy similarities and differences.
First the obvious difference: the CRA will be mandatory legislation in the EU market for most products that have digital elements, whereas IEC 62443 is an international standard that is mainly relevant in the industrial context. The legal status and the purpose of these two cybersecurity frameworks are therefore completely different.
When we look at the contents of the two texts, the first observation is that the IEC 62443 standards are a lot more detailed and specific than the Cyber Resilience Act. For example, the CRA seems to require a Secure Development Lifecycle (SDL) process that covers the design, development, manufacturing and maintenance phases and provides an appropriate level of cybersecurity, but the act does not define any details. However, IEC 62443 Part 4-1 most definitely lays down a lot of details about how exactly an SDL process should be established. If you break down the standard into individually auditable detail, as the ISA Security Compliance Institute has done in their ISASecure Secure Development Lifecycle Assessment (see the document SDLA-312 in ISASeure IEC 62443 SDLA Certification), you will find 102 specific things that the SDL process should include, plus some 30 more things, if you include the appendices.
Similarly, the functional capability requirements of Parts 4-2 and 3-3 are a lot more detailed and specific, with each part containing over hundred requirements, than the roughly dozen high-level essential requirements given in Annex I of the CRA.
A second observation is that the Cyber Resilience Act is very much risk based. Things start from the risk assessment and requirements should be interpreted and implemented based on the risk assessment and proportionally to the risks. On the other hand, IEC 62443 feels a lot more like a control framework which does give too much room to interpret its detailed requirements in the light of the risks. For product manufacturers, there is a requirement in Part 4-1 to create a threat model and in general to track the known risks to closure, but overall, the spirit of the standard is compliance to its specific requirements.
You could summarise these two observations so that the Cyber Resilience Act is a condensed set of minimal requirements that start from the identification of the risk-based justification why you should do certain things, whereas IEC 62443 provides detailed instructions on how to do these things in the industrial context.
Similarities and differences in the essential functional requirements
Let’s first see, how well IEC 62443 addresses the essential functional requirements of the Annex I of the Cyber Resilience Act. Since the final text of the act is not available at the time of writing this blog post, this analysis is using the compromise text from December 2023. We’re including the risk assessment requirement here, because the essential requirements have been written in the light of the risk assessment.
| Requirement in Cyber Resilience Act | Corresponding product manufacturer requirements in IEC 62443 |
| Product manufacturer shall undertake an assessment of cybersecurity risks | IEC 62443 Part 4-1 requires the manufacturer to create a threat model. However, the required details imply that the threat model should focus on the technical design as typical in threat modelling. The focus is on the interfaces, data storages and trust boundaries, rather than a more holistic risk assessment. |
| Products shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks. | The entire IEC 62443 Part 4-1 standard is about secure development lifecycle. However, the standard includes no specific requirements about the product manufacturing phase. |
| Not having exploitable vulnerabilities when the product is put on the market | IEC 62443 Part 4-1 includes six requirements about Defect Management (DM), and requirement DM-4 requires the manufacturer to address security related issues. DM-4 requires a definition of an acceptable residual risk level, which shall be used to determine how each issue should be addressed. Typically, one would expect the risk level of exploitable vulnerabilities to be higher than the acceptable residual risk level, so DM-4 should essentially cover this CRA requirement. |
| Secure default configuration | Not required in IEC 62443 Part 4-1, Part 4-2 or Part 3-3. This could be one of the secure design best practices discussed in Part 4-1. IEC 62443 does require the product documentation to list the default settings and the recommended settings for all network and security related settings. Apparently, the authors of IEC 62443 have prioritised availability and the ease of replacing broken devices over secure default settings. |
| Vulnerabilities can be addressed with software updates, which should be automatic, when applicable. | IEC 62443 Part4-2 requires support for updates, but there is no requirement for automatic updates or notifying the user about available updates. There are also no requirements for software updates to be free of charge. |
| Access control | IEC 62443 Parts 4-2 and 3-3 include a lot of requirements about identity management, authentication, session management and authorisation. |
| Protecting confidentiality | There are confidentiality requirements in IEC 62443 Parts 4-2 and 3-3. |
| Protecting integrity | There are integrity requirements in IEC 62443 Parts 4-2 and 3-3. |
| Minimisation of data | Not required in IEC 62443 Part 4-1, Part 4-2 or Part 3-3. This could be one of the secure design best practices discussed in Part 4-1. |
| Protecting the availability of essential functions after incidents, which includes protections against denial-of-service attacks, | Covered by various testing requirements of IEC 62443 Part 4-1 and requirements in Parts 4-2 and 3-3. |
| Minimising negative impact to the availability of other products or services | Not required in IEC 62443 Part 4-1, Part 4-2 or Part 3-3. This could be one of the secure design best practices discussed in Part 4-1. |
| Limiting attack surfaces (hardening) | Included in IEC 62443 Part 4-1: attack surface analysis, and including hardening instructions in product manuals, as well as in the “Least functionality” requirement of Parts 4-2 and 3-3. |
| Reducing the impacts of incidents with appropriate exploitation mitigation mechanisms | This could refer to for example protection against malicious code and backup mechanisms, which are required in IEC 62443 Parts 4-2 and 3-3. |
| Cybersecurity monitoring | Required in IEC 62443 Parts 4-2 and 3-3. |
| Possibility to remove data, for example when the product is being disposed | IEC 62443 Part 4-1 requires this to be covered in product manuals. |
To sum up, even though IEC 62443 is a lot more extensive and detailed than the act, there are a few essential functional requirements in the Cyber Resilience Act that are not included in IEC 62443.
Similarities and differences in vulnerability handling, notification responsibilities and documentation requirements
IEC 62443 standards include requirements about vulnerability handling, disclosing security related issues, and documentation, which map quite well to the corresponding requirements in the Cyber Resilience Act. However, there are some requirements in these areas in the CRA that are not required in IEC 62443. For example:
- CRA defines responsibilities to notify authorities in a timely manner and collaboration with market surveillance authorities.
- CRA requires manufactures to support their products at least five years, or at least the expected use time, if the use time is less than five years, but IEC 62443 does not include any maintenance time requirements.
- CRA requires the manufacturer to draw up and archive a Software Bill of Materials (SBOM).
- The CRA requirement to archive technical documentation and the EU declaration of conformity for at least 10 years is not included in IEC 62443
- Obviously, requirements about EU conformance assessment procedures are not included in IEC 62443.
- Product manual requirements in these two texts are largely similar, but there are some details of product manuals that are not required in IEC 62443 but are required in CRA. For example,a clear identification of the product, a description of the essential functions of the product, and a description of the security support that the product manufacturer will provide.
- While IEC 62443 does not have a general concept that would correspond to the technical documentation of CRA, there are many requirements in IEC 62443 Part 4-1 that require technical documentation at least indirectly. For example, documenting the threat model, interfaces specifications (called “secure design principles” in the standard for some reason), security test plans and test reports is similar. If you have designed your development process based on IEC 62443 Part 1, you may still have to make some additional effort to ensure compliance with the technical documentation requirements of the CRA.
Notice that this is not an exhaustive list, but it mentions the most notable highlights.
Conclusion
In this second part of our three-part blog post series, we compared the EU Cyber Resilience Act to the IEC 62443 series of cybersecurity standards on a high level. The Cyber Resilience Act and IEC 62443 have a lot of similarities, but they have a different point of view and a different purpose.
In general, compliance with IEC 62443 Parts 4-1 and either Part 4-2 or Part 3-3 will give a product manufacturer an excellent basis and a justified mechanism for complying with most, but not all, of the requirements in the EU Cyber Resilience Act, while compliance with the act doesn’t necessary mean that the manufacturer or the product would be very close to compliance with IEC 62443.
In Part 3 of this blog post series, we’ll discuss the practical implications of the EU Cyber Resilience Act. Stay tuned and take good care!