LFEL1001: conformity assessment section is inaccurate

nmav

The section linked below about "conformity and oversight" mentions that critical and closed important products cannot use internal control. This is not accurate as Article 32.2 of CRA explicitly requires for Important Class I products to use Module B or H only when they don't fully comply with the requirements of Annex I. Quoting: "Where, in assessing the compliance of an important product with digital elements that falls under class I as set out in Annex III and the processes put in place by its manufacturer with the essential cybersecurity requirements set out in Annex I, the manufacturer has not applied or has applied only in part harmonised standards ..."

That is, products under Important Class I can use internal control when they fully comply with the requirements set out in Annex I. At the same time, I cannot find any requirement for open source or closed source in the conformity assessment requirements of CRA. The reference to closed source seems innaccurate.

A way to express it:
- Critical and Important Class II: cannot use internal control

https://trainingportal.linuxfoundation.org/learn/course/understanding-the-eu-cyber-resilience-act-cra-lfel1001/requirements-and-conformity-assessments/conformity-and-oversight?page=1

dwheeler

First, THANK YOU for your feedback! We had many reviewers, but you can never have too many. The rules for CRA compliance are quite complicated. We were trying to simplify it without being misleading. So let's take a look...

I agree that CRA 32(2) is the key text. It says:

"2. Where, in assessing the compliance of an important product with digital elements that falls under class I as set out in Annex III and the processes put in place by its manufacturer with the essential cybersecurity requirements set out in Annex I, the manufacturer has not applied or has applied only in part harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least ‘substantial’ as referred to in Article 27, or where such harmonised standards, common specifications or European cybersecurity certification schemes do not exist, the product with digital elements concerned and the processes put in place by the manufacturer shall be submitted with regard to those essential cybersecurity requirements to either of the following procedures:
(a) the EU-type examination procedure (based on module set out in Annex VIII followed by conformity to EU-type based on internal production control (based on module C) set out in Annex VIII; or
(b) a conformity assessment based on full quality assurance (based on module H) set out in Annex VIII."

Today we don't have such "harmonised standards" or similar, so you can't use internal control (self-assessment) today. But obviously that is the hope & intent over time.

We said:

• Critical & closed important: cannot use internal control

You suggested:

• Critical and Important Class II: cannot use internal control

That might be an improvement, but doesn't deal with the exception for OSS.

You also said, " At the same time, I cannot find any requirement for open source or closed source in the conformity assessment requirements of CRA. The reference to closed source seems innaccurate."

This was our attempt to explain CRA article 32(5). This text says:
"5. Manufacturers of products with digital elements qualifying as free and open-source software, which fall under the categories set out in Annex III, shall be able to demonstrate conformity with the essential cybersecurity requirements set out in Annex I by using one of the procedures referred to in paragraph 1 of this Article, provided that the technical documentation referred to in Article 31 is made available to the public at the time of the placing on the market of those products."

If it's OSS and important and the technical documentation is public, then "one of the procedures" must be used. One of those procedures is internal control (self-assessment), so to me it appears important OSS can use internal control, with the caveat that it must publicly release the technical documentation. You could reasonably argue that 32(5) and 32(2) conflict, but I don't think so. 32(2) says you DON'T meet certain specs then you can't self-assess, but if you do I don't see the conflict.

So I guess I'd tweak that one line further to:

• Critical and Closed Important Class II: cannot use internal control

Do you agree?

dwheeler

This is not accurate as Article 32.2 of CRA explicitly requires for Important Class I products to use Module B or H only when they don't fully comply with the requirements of Annex I.

All software is required to fully comply with the requirements of Annex I, as applicable (due to risk analysis), even if it's "default". What's at issue in CRA article 32(2) is whether or not there are clarifying documents like harmonised standards.

dwheeler

Here's the corresponding script that I hope fixes the concern, with changes in bold:

Since most software is “default”, you can use internal control for most software. However, for PDEs that are critical, or are important class II and closed source software, you cannot use internal control. PDEs that are OSS and important may use internal control if the technical documentation is made public per article 32(5). For important or critical software, see article 32 for the specific list of procedures allowed.

Does that address your concern?

dwheeler

Actually, let's ad a little more. How about this (bold for change)?

Since most software is “default”, you can use internal control for most software. However, for PDEs that are critical, or are important class II and closed source software, you cannot use internal control. PDEs that are OSS and important may be able to use internal control if the technical documentation is made public per article 32(5). For important or critical software, see article 32 for the specific list of procedures allowed, as the rules are somewhat complex.

Critical & closed important class II: cannot use internal control

...

Since most software is “default”, you can use internal control for most software. However, for PDEs that are critical, or are important class II and closed source software, you cannot use internal control. PDEs that are OSS and important may be able to use internal control if the technical documentation is made public per article 32(5)*. For important or critical software, see article 32 for the specific list of procedures allowed **, as the rules are somewhat complex.

dwheeler

Actually, let's add a little more. How about this (bold for change)?

Critical & closed important class II: cannot use internal control

...

Since most software is “default”, you can use internal control for most software. However, for PDEs that are critical, or are important class II and closed source software, you cannot use internal control. PDEs that are OSS and important may be able to use internal control if the technical documentation is made public per article 32(5). For important or critical software, see article 32 for the specific list of procedures allowed ,as the rules are somewhat complex.

dwheeler

Any last comments before we tweak the material?

nmav

@dwheeler said:
First, THANK YOU for your feedback! We had many reviewers, but you can never have too many. The rules for CRA compliance are quite complicated. We were trying to simplify it without being misleading. So let's take a look...

I agree that CRA 32(2) is the key text. It says:

"2. Where, in assessing the compliance of an important product with digital elements that falls under class I as set out in Annex III and the processes put in place by its manufacturer with the essential cybersecurity requirements set out in Annex I, the manufacturer has not applied or has applied only in part harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least ‘substantial’ as referred to in Article 27, or where such harmonised standards, common specifications or European cybersecurity certification schemes do not exist, the product with digital elements concerned and the processes put in place by the manufacturer shall be submitted with regard to those essential cybersecurity requirements to either of the following procedures:
(a) the EU-type examination procedure (based on module set out in Annex VIII followed by conformity to EU-type based on internal production control (based on module C) set out in Annex VIII; or
(b) a conformity assessment based on full quality assurance (based on module H) set out in Annex VIII."

Today we don't have such "harmonised standards" or similar, so you can't use internal control (self-assessment) today. But obviously that is the hope & intent over time.

We said:

• Critical & closed important: cannot use internal control

You suggested:

• Critical and Important Class II: cannot use internal control

That might be an improvement, but doesn't deal with the exception for OSS.

You also said, " At the same time, I cannot find any requirement for open source or closed source in the conformity assessment requirements of CRA. The reference to closed source seems innaccurate."

This was our attempt to explain CRA article 32(5). This text says:
"5. Manufacturers of products with digital elements qualifying as free and open-source software, which fall under the categories set out in Annex III, shall be able to demonstrate conformity with the essential cybersecurity requirements set out in Annex I by using one of the procedures referred to in paragraph 1 of this Article, provided that the technical documentation referred to in Article 31 is made available to the public at the time of the placing on the market of those products."

If it's OSS and important and the technical documentation is public, then "one of the procedures" must be used. One of those procedures is internal control (self-assessment), so to me it appears important OSS can use internal control, with the caveat that it must publicly release the technical documentation. You could reasonably argue that 32(5) and 32(2) conflict, but I don't think so. 32(2) says you DON'T meet certain specs then you can't self-assess, but if you do I don't see the conflict.

So I guess I'd tweak that one line further to:

• Critical and Closed Important Class II: cannot use internal control

Do you agree?

Yes, you have very good point on the open source. I have missed the implications of paragraph 5. The tweak you propose seems great. As "closed product" may have multiple interpretations, a further minor suggestion is to call out "closed source" as opposed to "closed".

nmav

I didn't get a notification of the response so I probably missed the window. However the changes look great! There is a smaller suggestion regarding closed, but that's more minor if the changes are already in place.

Just wanted to say, the content is really impressive. Even top consultants in the field would be envious!

dharmon

Thank you again for the thoughtful feedback and kind words! The updates have now been posted.