Cyber Resilience Act published
EU Cyber Resilience Act published
The EU Cyber Resilience Act (CRA) was published today. This establishes its validity and timetable, as the publication date determines the corresponding implementation dates: The start of actual validity – i.e. the date from which every software manufacturer or representative of such a manufacturer who places software on the market in the EU must be compliant – is December 11, 2027.
More precisely: The regulations, in particular Art. 13 and Annexes I and II, apply to all products with digital elements that are placed on the EU market from this date. For products that are placed or have been placed on the market beforethis date, the requirements apply as soon as they undergo significant changes after this date, see Art. 69 II CRA. However, the reporting requirements under Art. 14 must be met for all products from September 11, 2026, regardless of the date of market entry (Art. 69 III CRA).
From now on, there is a transitional period until which software providers must deal with the new requirements and implement them. Implementation is not trivial in some cases and requires some organizational change, e.g. the inclusion of any risk analyses and assessments that may not yet exist in the release process, the declaration of support periods or the establishment of suitable vulnerability management processes.
– Unless otherwise stated, all references in the following refer to the text of the CRA –
You want to know more about the challenges your organisation is facing now?
Talk to one of our experts!
For whom is the Cyber Resilience Act relevant?
In principle, the CRA applies to anyone who provides a product with digital elements, i.e. software support. However, it also restricts its application to groups that are already regulated elsewhere. For example, products that are only used in the automotive, marine or aviation sectors or are subject to the Medical Device Regulation are excluded. However, it can be assumed that a dual-use option, i.e. usability in other, non-regulated areas, will also restore validity.
Roles of the actors
The role of the actor is also relevant for the assessment of validity. Conceptually, regulation attempts to make the beneficiary of the economic transaction responsible for the transaction within the EU. What does this mean?
In a simple case, a European provider manufactures a product with digital elements that falls within the regulated area (see above). This means that the supplier is directly obliged to fulfill the CRA requirements for its product, for example a manufacturer of stereo systems or jukeboxes that support music streaming or a machine tool that can be maintained remotely.
If the manufacturer of the product is based outside the EU, these obligations are transferred to its representative, the “distributor”. This can be a dealer, a partner or an implementation partner, i.e. the next economic beneficiary. It is interesting to note that the distributor must also vouch for compliance with the obligations during production. This brings with it a completely new liability regime for license sellers of American software, for example!
Open Source
As soon as open source comes into play, the chain becomes somewhat less clear. But the CRA knows and takes into account the open source concept. The actual creator of an open source solution is not subject to the requirements. However, if an actor takes an open source solution and uses it commercially, be it through support contracts, he is subject to the regulations analogous to those of a provider. For example, a SUSE is responsible under the CRA for the distribution it provides.
There are only exceptions for so-called stewards. These have to fulfill less stringent requirements. This role was created for the so-called Foundations (Eclipse, Cloud native, etc.), as they represent a form of distributor, but do not derive any economic benefits from the provision and distribution comparable to those of a conventional software provider. Recognition is required to be considered a steward.
What are the major changes?
The guiding idea behind the CRA is to improve the security situation for software consumers. Since almost everything today is controlled by and equipped with software, cyber attacks became possible almost everywhere. Every component that is connected to the Internet, Wi-Fi or even near-field communication such as ZigBee or Bluetooth is a potential attack surface and must therefore be used or provided with caution.
The provider of software on the European market must therefore fulfill the following requirements in future:
- Provision of a software bill of materials (SBOM), see Annex I
- Regularly carry out a risk assessment of the safety risks and include this in the documentation, see Art. 13, III and IV
- Drawing up a declaration of conformity, see Art. 13 XII and Art. 28 I and Annex IV
- Provision of a CE marking, see Art. 12 XII and Art. 30 I
- Definition of an expected lifetime of the product and the provision of free safety updates within this period, see Art. 13 VIII et seq.
- Demanding extensive reporting obligations (in accordance with Art. 14)
- Notification of actively exploited vulnerabilities within 24 hours to the European Network and Information Security Agency (ENISA) via a reporting platform yet to be created (presumably analogous to the solution already in place in the telecom environment)
- In addition, clarification of the assessment and measures within 72 hours
- Information of the users of the product and the measures to be taken by them, see Art. 14 VIII.
How could TrustSource support?
- Unified platform for software analysis, compliance & release management
- Integrated risk management
- Automated vulnerability management
- Consistent, CRA-compliant documentation
- CSAF-compliant reports
- Standardized vulnerability reporting process
- Implementation support
What are the consequences of non-compliance?
Every law is initially just a declaration of a behavioral requirement. But what are the consequences if you do not comply? What risks do providers face?
With publication, the member states are instructed to appoint a body that is responsible for supervision in the respective country. In Germany, this will most likely be the BSI. In turn, the BSI can then carry out or commission corresponding inspections in the event of suspicion. If deficiencies are identified, this usually leads to a request for rectification, but can also be sanctioned accordingly. The CRA provides for the following possible sanctions:
- Up to EUR 15 million or, in the case of companies, up to 2.5% of global annual turnover in the previous financial year in the event of a breach of essential safety requirements (Annex I). (see Art. 64 II)
- For breach of obligations imposed by the CRA, up to EUR 10 million or – for companies – up to 2% of the ww turnover (previous year) (see Art. 64 III)
- For incorrect, incomplete or misleading reports to the authorities, up to EUR 5 million or 1% of annual turnover for companies (see Art. 64 IV)
In addition, there is the possibility of restricting the distribution of the product or withdrawing it from the market in the event of sustained non-compliance, see e.g. Art. 58 II.
You want to better understand what this means for your organisation?
Talk to one of our experts!
Why does a license matter?
“If someone is publishing his stuff on Github he must accept that it will be used by others!””
Unfortunately we still hear this critical misunderstanding often while finding open source components buried somewhere in source code; without any furtehr declaration of course. Let’s send a few words to discuss this in more detail.
In our western world protection of intellectual property is a high value. The believe that an inventor shall profit from his achievements has been accepted as the driving force of behind our wealth and developed status. That is why it has been protected by intellectual property laws. This insight counts some years already and meanwhile has been established and harmonized internationally through the Berner Convention.
Governing thought has been, that an inventor or creator of a work always will own all rights of usage, modification and all kinds of distribution. This is always valid for a certain period of time after the work has been created. Theperiod depends on the work.
An inventor or creator may transfer his rights to others. The typical form of this transfer is a license.
Without a license, all rights remain with the creator for his protection!
If no license exists, for the protection of the creator, all rights will be assumed as not transferred. Therefor each user of a component without license starts walking on ice. In general nothing might happen immediately. But who knows what will be in the future? Success might make jealous, motivations might change over time. Happy times for all of those, who own a license they may rely on!
But not only that there might be some contributors of open source software getting nasty. There is another relevant aspect of licenses. They also clarify the terms when the right to use is transferred. this will protect you from a usage without right.
In our hemisphere the usage of protected works without right is assumed a criminal act. This might not only cause immense financial damages due to call backs or branding impacts. But also a criminal investigation might be caused. In some countries this does not even require a plaintiff. This role will be taken by the prosecutor automatically triggered by a suitable evidence, irrelevant of the source (competition, former employee, original inventor).
To prevent all kinds of damage, it is highly recommended to ensure the availability of and conformity with a license!
To prevent damage, it is highly recommended to avoid using components without a license. But to achieve this, it is essential to know what has been used to build the software and what are the resulting obligations.
TrustSource has been developed to automate this task. Applying the automated scanning you may detect early which components are used and which licenses – or even no licenses – are related.
Our architects may help you to manage critical cases or identify alternative solutions. Do not wait, start right now in creating transparency!
June 19th, Compliance Breakfast @ Frankfurt a.M.
To achieve a fast Go-to-market for innovative products and services, the application of software, especially open source software is essential.
But, open source software is no free lunch!
What obligations are related to the use of open source software, what triggers the different obligations and what is resulting therefrom? What are athe risks and how to manage them? All this will be part of this informational event. You will receive an overview of the current legal situation as well as practical experiences of the introduction of Open Source Governnace.
0830-0900 Welcome coffee & tea
0900-0915 Introduction of speakers
0915-0945 Current legal situation and challenges (Heinzke)
0945-1000 Questions and discussion
1000-1045 Lessons learned from introducing Open Source Governance in a conglomerate (Thielscher)
1045-1100 Questions and discussion
Tickets can be booked here. To ensure a sound experience, the event is limited to 25 participants. Please note, the event will be in German.