Key Takeaways
The CRA has important consequences for products with digital elements (PDEs).
PDEs can no longer simply be placed on the market “as is”. Under the CRA, PDEs must now meet essential minimum cybersecurity requirements. Manufacturers, importers, and distributors will be required to ensure the security, maintenance, and support of the PDE both before and after it is placed on the market. Every actor must assess the impact the CRA has on them and their contracts.
Upstream contracts (with suppliers) and downstream contracts (with customers) must be reviewed.
Contracts with suppliers and customers should include specific provisions such as audit rights, reporting obligations, cooperation duties, information obligations, liability clauses, and patch and update guarantees.
Supplier selection processes must also be reviewed.
If you take CRA compliance into account during the supplier selection process, you avoid lengthy negotiations with a supplier who was never CRA-compliant. Or worse: you avoid discovering that the supplier is not CRA-compliant after the contract has been signed.
Back-to-back contracts are needed for a proper allocation of risks.
It is important that clauses in supplier contracts and customer contracts are aligned throughout the entire chain. This prevents a situation where, for example, a distributor bears certain responsibilities that should rest with its supplier or customer instead.
Do not wait to implement the CRA!
The CRA obligations come into force in phases between December 2024 and December 2027. To be compliant and avoid operational and legal risks, it is essential to start analysing the impact of the CRA on your organisation and to draft or review your contracts now.
What is the CRA and what is its impact on your contracts?
Where the NIS2 Directive focuses on cybersecurity at organisational level, the Cyber Resilience Act (CRA) focuses on cybersecurity at product level.
To raise the cybersecurity level of products with digital elements (PDEs), the CRA prohibits placing PDEs on the market “as is”, that is, without meeting the essential cybersecurity requirements.
Is the CRA completely new to you? Or are you unsure what a PDE is? Read our earlier blog first: The Cyber Resilience Act (CRA) in 10 questions and answers.
This blog focuses on the impact of the CRA on your contracts as a manufacturer, importer, or distributor. In practice, CRA compliance is a multidisciplinary issue. Alongside the technical aspect, the legal aspect must be kept into account.
The CRA obligations have significant consequences for contracts throughout the entire chain. Organisations will need to review both their supplier contracts (upstream) and their customer contracts (downstream) to assess whether they comply with the CRA. This is not only relevant for contracts, but also for other legal documents such as purchasing conditions, sales conditions, and service level agreements (SLAs).
Below, we distinguish between the consequences for:
- Upstream contracts (with suppliers)
- Downstream contracts (with customers)
What are the CRA obligations for manufacturers, importers, and distributors of PDEs in brief?
To understand the impact of the CRA on contracts, we first need a clear picture of the CRA obligations.
The CRA sets out various obligations to ensure that PDEs are designed, developed, and produced in accordance with the essential cybersecurity requirements of the CRA.
The CRA therefore requires manufacturers, when integrating third-party components (such as central processing units, graphics cards, or software libraries) into their PDE, to carry out due diligence. If the manufacturer discovers a vulnerability, they are required to notify the third party that manufactures or maintains the component, to address and remediate the vulnerability, and, where applicable, to provide that third party with the security patch applied.
The CRA does not only impose obligations on manufacturers, but also on importers and distributors of PDEs. They must, among other things, verify that the PDEs they place on the market:
- meet the essential cybersecurity requirements of the CRA
- are accompanied by the required technical documentation
- bear the CE marking and declarations of conformity
- are accompanied by security updates and vulnerability handling procedures
If the importer or distributor knows (or should know) that a PDE is not CRA-compliant, they must not place the product on the market or continue to distribute it.
Consequences for upstream contracts (with suppliers).
The CRA creates a clear need for manufacturers, importers, and distributors alike to obtain contractual guarantees from their suppliers, as the cooperation of those suppliers is necessary to fulfil their own CRA obligations.
Below, we list some examples of clauses that these actors should include in their contracts with suppliers:
Audit rights and information obligations:
For manufacturers, it is important that they carry out appropriate due diligence and obtain the necessary (technical) information (and any updates) in a timely manner when purchasing components from third parties. This is needed to fulfil their own CRA obligations, such as:
- drafting the Software Bill of Materials (SBOM),
- providing information and instructions to users,
- responding to questions from supervisory authorities,
- obtaining the conformity assessment.
For importers and distributors, it is equally important that they receive the necessary (technical) information (and any changes to that information) from their suppliers (or are able to verify it). This is needed to fulfil their own CRA obligations, such as:
- providing information at the request of supervisory authorities,
- providing information to their customers (e.g. in connection with updates to the PDE),
- verifying that PDEs meet the essential cybersecurity requirements,
- verifying that all required markings are present on the PDE, or
- obtaining the required documentation to place PDEs on the market.
Cooperation obligations
It is advisable to contractually establish that the supplier must provide the necessary corrective measures, such as issuing patches, withdrawing non-compliant PDEs from the market, or recalling or ceasing to distribute PDEs.
Reporting obligations for vulnerabilities and incidents
Manufacturers are required to report any vulnerabilities they discover in third-party components to their supplier and to address and remediate them without delay.
For importers and distributors, it can be useful to require the manufacturer to investigate known vulnerabilities and incidents and to develop patches or updates, which must then be made available immediately and free of charge (potentially linked to the relevant service levels).
Notification of cessation of activities or support
It is important to include a clause requiring the supplier to timely inform the manufacturer of any intended cessation of activities or discontinuation of support, production, or availability of (a component essential to the operation or security of) the PDE, so that the manufacturer can meet its obligations regarding product support, security updates, and notifications to users and authorities, and so that importers and distributors can inform the relevant authorities and users in a timely manner.
In the event of a cessation of activities or the end of support, production, or availability, it may also be advisable to make arrangements regarding access to source code, firmware, and technical documentation, possibly under an escrow agreement. You can also agree that the supplier must propose viable alternatives or replacement components or must assist with the migration or redesign of the PDE. This can be linked to service levels and sanctions.
Patch and update guarantees
For manufacturers, importers, and distributors alike, it is important to include provisions that require their supplier, during the support period of the PDE, to report vulnerabilities without delay, to investigate them, and to develop patches or updates that are then made available immediately and free of charge. This can be linked to service levels and sanctions.
Software Bill of Materials (SBOM)
The manufacturer must contractually agree that suppliers will provide a detailed list of all components (including open-source components). If a supplier refuses to do so, the manufacturer will be unable to fulfil its own CRA obligations.
Liability and indemnification
The manufacturer must be able to hold the supplier liable or seek indemnification from the supplier in the event of fines or damages where the component does not meet the agreed CRA requirements, or where the supplier fails to deliver updates.
Importers and distributors must likewise be able to hold their supplier liable or seek indemnification where the supplier fails to comply with the CRA. Existing liability arrangements or limitations may need to be reviewed in this context.
Termination
The ability to terminate existing contracts may also need to be reviewed, clarified, or extended in the context of the CRA, for example where a party fails to provide a patch (in time) or where a patch proves insufficient to address the vulnerability. Including exit or migration arrangements can also be useful for ensuring continuity of the PDE during its support period.
Service levels and Service Level Agreement (SLA)
In general, it can be useful to agree on service levels or a separate SLA.
Consequences for downstream contracts (with customers or resellers).
In addition to the upstream risks, the actors mentioned must also consider their downstream obligations towards customers. These may include end users, importers, or distributors.
Below, we list some examples of clauses to bear in mind in general (sales) conditions, licence agreements, terms of use, or other legal documents with customers.
Support period
The manufacturer must state the expected lifetime or a fixed period during which security updates will be provided.
Limitation of liability
The manufacturer can no longer simply exclude all liability for cybersecurity. Because the CRA sets mandatory essential cybersecurity requirements, a court may be more likely to reclassify “as is” clauses or scrutinize them more closely. Existing liability arrangements or limitations may need to be reviewed.
Update obligations
The supplier can require customers to install updates within a set period. If customers refuse or fail to install updates in time, the supplier can limit its liability for incidents that could have been prevented by that update. The contract can also specify how updates will be delivered.
Information and instructions for the user
The CRA requires PDEs to be accompanied by clear information and instructions for the user, including on the safe use of the PDE, its security functionalities, and how to install security updates. This obligation rests primarily with the manufacturer. Importers and distributors must ensure this information is present when they place the PDE on the market or distribute it. In contracts with customers, it may therefore be advisable to refer to this user information and instructions, so that the customer confirms having read and understood them, or at least that it is clear where the customer can find and consult them.
Reporting obligations for vulnerabilities and incidents
It is important that vulnerabilities and incidents are reported to the manufacturer, as the manufacturer has its own reporting obligations and must take corrective measures. This reporting obligation should also be captured contractually.
Cooperation obligations
In certain cases, an incident may require cooperation between supplier and customer. Contracts can therefore include arrangements and procedures for cooperation in investigating an incident and sharing relevant information about it.
Should you look at the full set of contracts (back-to-back contracts)?
Yes, every contract must be viewed in the context of the full chain of contracts, as one contract has consequences for another. These must be aligned into a coherent set of obligations, so that there are no contractual gaps.
For example, a distributor that purchases products with digital elements from a manufacturer in order to place them on the market and sell them will need to pay particular attention to aligning the clauses in the contract with the manufacturer with those in the contract with the customer, to avoid contractual gaps that expose the distributor to unnecessary risks as a seller.
Should you distinguish between template contracts and existing contracts?
Yes, it is best to distinguish between your template contracts and existing (signed) contracts:
Template contracts: it is best to review these as soon as possible, so that future contracts you enter into are in line with the CRA.
Existing contracts: these can be reviewed now via an addendum, or as the contract approaches its end date or renewal date, depending on the type of agreement. This requires a good overview of your existing contracts . If you do not have this overview, it is best to map it out first.
When should you review your contracts?
As a manufacturer, it is best to update your contracts before 11 September 2026, in line with the phased entry into force of the CRA. The phased entry into force of the CRA is discussed further below.
In any case, do not wait until the last moment to update your contracts. You may need to negotiate with your supplier or customer, and that takes time. By starting the conversation early, you avoid having to negotiate under pressure.
Should you also review other processes?
Yes, the CRA does not only affect your contracts (upstream and downstream), but can also affect other processes, such as the supplier selection process.
Negotiations with a mature, CRA-compliant supplier will always go more smoothly than negotiations with a supplier who has never heard of the CRA. Existing supplier questionnaires may also need to be updated.
What about products that are already on the market?
For products with digital elements that are currently on the market, or that will be placed on the market before 11 December 2027, the provisions of the CRA will only apply once those PDEs undergo a significant modification.
However, this does not mean there is no contractual impact for these existing PDEs, as there is an exception to this rule: the manufacturer’s reporting obligation for certain vulnerabilities and incidents applies to all PDEs, including those placed on the market before 11 December 2027.
Where does the CRA apply and what is the contractual impact?
The CRA is a European regulation and therefore applies directly in all EU member states, without needing to be transposed into national law (unlike the NIS2 Directive).
This does not mean the CRA has no consequences for contracts with non-European parties, for example where your supplier is based outside Europe. Negotiating with, for instance, a US supplier to make the contract CRA-compliant becomes a matter of negotiating position. It is best to approach this strategically.
When does the CRA apply?
The CRA obligations apply in phases. Here are some key dates in the transitional period:
- On 11 December 2024, the CRA entered into force.
- On 11 June 2026, conformity assessment bodies (CABs) will be authorised to assess the conformity of products with the requirements of the CRA.
- On 11 September 2026, manufacturers of connected products will become subject to mandatory reporting obligations for vulnerabilities and incidents. Manufacturers should ideally have their contractual arrangements with suppliers and customers in place by this date.
- On 11 December 2027, all remaining provisions of the CRA will finally apply, including the essential cybersecurity requirements before placing a PDE on the market, vulnerability management throughout the full lifecycle of the PDE, and transparency towards users.
How can CRANIUM help me?
Implementing the CRA requires a multidisciplinary approach, both legal and technical. Within the CRANIUM Group, we have all the necessary expertise in-house to fully support you:
CRANIUM’s Digital Law team handles the legal aspects for you (e.g. assessing the applicability of the CRA to your organisation, drafting and reviewing your contracts, legal assistance in fulfilling the reporting obligations, and support in the context of enforcement).
Cingulum handles the cybersecurity aspects for you.
