Hi Steffen,
Dumb question for my clarity – are we saying then that we should presume that all packaged software, made available on the market, is
a PDE?
|
--
|
|
Steve
Millidge
Founder & CEO
|
From: Steffen Zimmermann <steffen.zimmermann@xxxxxxxx>
Sent: Thursday, July 4, 2024 11:04 AM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: AW: [open-regulatory-compliance] Does being categorized as Important or Critical product impact FOSS dependencies (Was: European Commission informal CRA consultations on the definition of Critical and Important products)
Hi,
once again
😉
remote data processing is an option! Software products without remote data processing are clearly in scope. If a software product leverages
remote data processing to perfom essential functions, this processing is also in scope.
The question therefore is, if there is remote data processing, which part of the remote data processing is in scope and which not and to what
extend does this include the infrastructure of the service/solution?
Remote data processing in scope, when “the
absence of which would prevent […] a product with digital elements from performing one of its
functions.”
Example is given in the recital (11):
That approach ensures that such products are adequately secured in their entirety by their manufacturers, irrespective of whether data is
processed or stored locally on the user’s device or remotely by the manufacturer. At the same time,
processing or storage at a distance falls within the scope of this Regulation only in so far as it is necessary for a product with digital elements to perform its functions. Such processing or storage at a distance includes the situation where a mobile
application requires access to an application programming interface or to a database provided by means of a service developed by the manufacturer. In such a case, the service falls within the scope of this Regulation as a remote data
processing solution.
Mit den besten Grüßen,
Steffen Zimmermann
Industrial Security @ VDMA
Von: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx>
Im Auftrag von Steve Millidge (Payara) via open-regulatory-compliance
Gesendet: Donnerstag, 4. Juli 2024 11:47
An: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Betreff: Re: [open-regulatory-compliance] Does being categorized as Important or Critical product impact FOSS dependencies (Was: European Commission informal CRA consultations on the definition of Critical and Important products)
I also agree this is a reasonable question to ask as there is contradictory advice coming from some lawyers.
“The
purpose of this Regulation is to ensure a high level of cybersecurity of products with digital elements
and their integrated remote data processing solutions.” – emphasis in original text
For example advice we received is that a product can be software but it
must also have “its remote data processing solutions” and the remote data processing is only in scope if “it
is necessary for a product with digital elements to perform its functions”.
So my simple understanding is that drupal or a drupal module is under the scope of the CRA if it passes the statements below;
1)
It is installed by an end user i.e. a product placed on the market (not pure SAAS)
2)
It must talk to some remote data processing to function – “for which is designed and developed by the manufacturer, or under the responsibility of the manufacturer”
3)
That remote data processing is necessary to perform its functions.
If it is sold as pure SAAS then NIS(2) would apply depending on the size of the org selling it as SAAS.
So in my mind a pure OAuth integration module would fail (2) as although it is designed to integrate with an OAuth provider the module writer is not providing the remote data processing. However
a module that say talked to some service ran by the module manufacturer – say a drupal module/code library shipped by a service provider like Auth0 that had to use their SAAS service would be covered.
Note I am not an expert on this just reiterating the gist of legal advice we received.
From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx>
On Behalf Of Felix Reda via open-regulatory-compliance
Sent: Thursday, July 4, 2024 10:05 AM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Felix Reda <felixreda@xxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] Does being categorized as Important or Critical product impact FOSS dependencies (Was: European Commission informal CRA consultations on the definition of Critical and Important products)
Am 03.07.2024 um 23:20 schrieb Idelberger, Florian (IIWR) via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>:
2) Yes, there can be products that are purely digital, why shouldn’t there be?
While this answer is correct, it is not an unreasonable question to ask. Traditionally, a lot of EU legislation, including the 1983 Product Liability Directive (PLD) up until recently, defined products as "all movables, ... even though incorporated into another
movable or into an immovable“ - this definition was often interpreted as requiring products to be tangible. Only the recent revision of the PLD changed the definition of products to explicitly include software. EU consumer law still distinguishes between „goods“,
which have to be tangible, and „digital content“ (data which are produced and supplied in digital form), which are intangible.
For the purposes of the CRA, however, the definition in Art. 3 (1) provides the answer:
'product with digital elements' means a software or hardware product and its remote data processing solutions,
including software or hardware components being placed on the market separately; (emphasis mine)
By explicitly including software placed on the market separately from any hardware, the CRA clarifies that for the purposes of this law, a product can be purely digital (same as for the revised PLD). For other laws, the situation may be different.
Best,
Felix
Am 03.07.2024 um 22:29 schrieb Joe Murray via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>:
Thanks for the discussion Dirk-Willem, Steffen, Marta, Florian and Christian.
I am bringing forward this actual use case to try to sharpen our discussion and understanding because it seems like an edge case but not uncommon.
Drupal is a loose open source ecosystem with probably a few billion in annual turnover used by about 1 percent of internet websites .
I'm trying to tease out the difference between the primary function of an open source project (e.g. Drupal as a CMS, which is not covered by
https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Annex_3.html), the primary function of an extension to the product (e.g. a Drupal module supporting OAuth for identity access management, which is covered by Annex 3 but is normally not
the primary function of a Drupal install), and the primary function of the product in a particular sale (of Drupal with OAuth module as an identity access management system). I suspect that the firm selling the open source solution would have legal liabilities
to ensure that it is securely developed, but I am unclear after that.
As I look more closely, I see the CRA only covers products. Are there products that are purely digital? Digital services are sometimes covered by NIS 2 if they are purchased by important or essential entities (https://ec.europa.eu/commission/presscorner/detail/en/QANDA_22_5375),
and it entails equivalent obligations.
So I'm still trying to figure out which entities would meet which legal definitions in the sale of an individual Drupal CMS with a primary purpose of serving as an identity management system for access control to a political party or government department based
on generic modules. I'm assuming that a consulting company making the sale and making the site from open source components would be the manufacturer: they are taking money, so they are putting the software on the market.
I'm unclear on whether individuals contributing to the relevant software modules will be protected or liable in some way.
In the Drupal ecosystem, there is a Drupal Association that as I understand it may be a candidate for Open Source Steward. I do not understand whether the maintainers of the 50,000+ contributed modules who tend to be a collection of a small number of individuals
sometimes getting sponsorships will qualify as collections of Stewards, e.g.
https://www.drupal.org/project/simple_oauth or https://www.drupal.org/project/auth0 . I doubt it. They rarely get money for sites that include their module, so I'm not sure if they are manufacturers in
our example of a sale by the consulting company.
I hope this is helpful.
Joe Murray, PhD (he/him)
President, JMA Consulting
416.466.1281
We respectfully acknowledge the autonomy of Indigenous peoples, and that JMA Consulting is located on the traditional territory of many nations including the Mississaugas of the Credit, the Anishnabeg, the Chippewa, the Haudenosaunee and the Wendat peoples
which is now home to many diverse First Nations, Inuit and Métis peoples. We also acknowledge that Toronto is covered by Treaty 13 with the Mississaugas of the Credit.
On Mon, Jul 1, 2024 at 10:20 AM Dirk-Willem van Gulik via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>
wrote:
On 1 Jul 2024, at 15:47, Steffen Zimmermann <steffen.zimmermann@xxxxxxxx> wrote:
sorry for my very special view on machinery, which is b2b. That grinding machines I have in mind look like these. These are more or less “systems of systems”, having linux, windows, sensors,
actuators, ethernet, opc ua, mqtt, REST-API, you name it.
...
Build by developers maybe as a tailor-made product but based on a lot of (OSS) components from hundreds of suppliers.
Sure - and in some cases - when they buy, on the EU market, some component. Such as a ready made firewall - then that product was placed on the market by its supplier with all the trimmings.
But that is fairly immaterial to these (end) developer from a ‘does my grinder need Annex II/III’ treatment CRA perspective.
Dw
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
