The Cyber Resilience Act and Supplier Contracts

What are manufacturers required to report under the Cyber Resilience Act?

What reporting requirements have applied to manufacturers since September 2026?
‍‍

As of September 11, 2026, manufacturers of products with digital components must report actively exploited vulnerabilities and serious security incidents through ENISA’s central reporting platform. An initial alert must be submitted within 24 hours, a more detailed report within 72 hours, followed by a final report. This requirement also applies to products that were placed on the market before December 2027.

A control module, a third-party communication library, firmware from a supplier: Almost every connected machine contains software that you didn’t develop yourself. That’s exactly where many vulnerabilities arise. And that’s exactly where the problem with the Cyber Resilience Act begins. The clock starts ticking for your report the moment you learn of an exploited vulnerability. If you don’t find out until days later—because your supplier is contractually required only to notify you “without delay”—you’ll be in a tight spot.

This article briefly explains the new requirements and outlines the points that procurement and IT security teams should now review in supplier contracts.
‍

What is the Cyber Resilience Act?

The Cyber Resilience Act (CRA) is EU Regulation (EU) 2024/2847 on cybersecurity requirements for products with digital elements. It applies directly in all member states and does not need to be transposed into German law. Its goal: to ensure that hardware and software remain secure throughout their entire lifecycle. This includes, for example, connected devices, control systems, firewalls, apps, and accounting software.
‍

Who is affected: Manufacturers, importers, dealers

The focus is on manufacturers. These are the entities that develop or have manufactured a product with digital elements and place it on the EU market under their own name. Manufacturers outside the EU are also covered. For small and medium-sized industrial companies, this means that anyone who sells machines with control software, networked electrical systems, or components with firmware is generally considered a manufacturer under the CRA. A component manufacturer may therefore have obligations of its own while also serving as a supplier to another manufacturer.

Importers and distributors must ensure that the products they make available in the EU comply with the requirements. Exceptions include, among others, medical devices, vehicles, civil aviation, and marine equipment—which are subject to their own regulations—as well as free, open-source software developed on a non-profit basis.
‍

Key Deadlines Through December 2027

• December 10, 2024: The CRA takes effect.
• June 11, 2026: The rules for conformity assessment bodies take effect.
• September 11, 2026: The mandatory reporting requirement for actively exploited vulnerabilities and serious incidents takes effect.
• December 11, 2027: All requirements apply, including safety from the design phase onward, vulnerability management, technical documentation, and CE marking.

Important for your planning: According to Art. 69(3) of the CRA, the reporting requirement also applies to products placed on the market before December 11, 2027. This means that your existing products in the field are already affected.
‍

Reporting Requirements: 24 Hours, 72 Hours, Final Report

The reporting requirement under Article 14 of the CRA applies in two cases: when a vulnerability in your product is actively exploited, and when a serious security incident compromises the security of the product. Reporting is conducted in three stages.

Level 1: Early warning within 24 hours
The early warning must be received no later than 24 hours after you become aware of the case. Details are not necessary at this stage. The goal is to ensure that the authorities are notified early on.

Step 2: Report within 72 hours
The actual report must be submitted within 72 hours. It should include additional details, if you already have them, such as the nature of the incident and the measures you have already taken.

Step 3: Final Report
Finally, submit a final report describing the case, the cause, and the corrective action. For a vulnerability, the report is due no later than 14 days after a fix is available. For a security incident, you have one month from the date of reporting.
‍

CRA and NIS2: What's the Difference?

Both sets of regulations focus on cybersecurity, and both have a 24-hour deadline. Nevertheless, they address different issues. The Cyber Resilience Act applies to products with digital elements and imposes obligations on manufacturers, importers, and distributors. NIS2 focuses on organizations and their IT systems and applies to critical and highly critical infrastructure.

This is also evident in the reporting requirements. Under the CRA, you must report exploited vulnerabilities and incidents in your product via ENISA’s reporting platform. Under NIS2, you must report significant security incidents within your own organization to the BSI in Germany.

NIS2, then, asks how secure your company is. The CRA asks how secure the products you sell are. Many industrial companies fall under both sets of regulations. To learn how to incorporate NIS2 requirements into your contracts, read our article on NIS2 and visit the NIS2 Contract Management page.

The problem lies in the supply chain

As a manufacturer, you are subject to the reporting requirement even if the vulnerability is found in a purchased component. The CRA expressly requires that, for third-party components—including open-source software—you exercise due diligence to ensure that they do not compromise the security of your product (Art. 13, para. 5). If you discover a vulnerability in a component yourself, you must notify the manufacturer or maintainer of that component (Art. 13, para. 6).

In practice, the flow of information often looks like this: The subcontractor notices an exploited vulnerability. He informs your supplier. The supplier conducts an internal review, coordinates with relevant teams, and then contacts your purchasing department, which forwards the message to IT security. Each step takes hours. If your contract specifies no reporting deadline at all, a deadline of several business days, or only a general “immediately,” the 24-hour deadline is virtually impossible to meet.

In addition, there are three common gaps in older supplier contracts:

• The supplier's support period is shorter than the one you are required to promise your customers.
• There is no requirement to provide a software bill of materials (SBOM). So you have no idea which libraries are included in a component.
• Liability and recourse do not cover product recalls, in-the-field safety updates, or the risk of fines.

These clauses should be included in your supplier contracts

The following checkpoints are not sample texts. They help the procurement, IT security, and legal departments review existing contracts in a structured manner and prepare for renegotiations.

Supplier Information and Reporting Deadlines

First, check whether a specific deadline in hours has been agreed upon at all. It should be well under 24 hours, because your own deadline begins as soon as you receive the information. Equally important is the starting point: Does the deadline begin as soon as the vendor learns of the vulnerability, or only after its internal review? In the latter case, a few hours can quickly turn into several days. Also, make sure that the supplier reports not only confirmed cases but also suspected cases and indications of active exploitation.

To enable you to act on a report, the contract should specify minimum requirements, such as the affected versions, the nature of the vulnerability, and known mitigations. However, the initial notification is not enough. The supplier should be required to provide additional information so that you can prepare your 72-hour report and, later, the final report. Also clarify who is responsible on both sides and whether these contacts are available on weekends. A vulnerability that comes to light on Friday evening won’t wait until Monday. Finally, the supplier should pass these obligations on to its subcontractors. Otherwise, the reporting chain breaks down precisely where many vulnerabilities arise.

Security Updates and Support Period

Your supplier’s support period should last at least as long as the one you specify for your own product. The CRA generally stipulates a minimum of five years for this. If support for a component ends earlier, you’ll be left without a solution if a new vulnerability arises. Therefore, you should also check whether a deadline has been agreed upon for security updates or workarounds. It makes sense to prioritize these based on severity, so that critical vulnerabilities are addressed more quickly than minor ones.

Also, pay attention to the costs. You must offer security updates to your customers free of charge, so your supplier should also provide them at no extra cost. Equally important is how long updates remain available. For your own updates, the CRA requires at least ten years of availability, and this is only possible if the supplier cooperates. Finally, clarify how much advance notice the supplier must give when discontinuing a component or ending support. This will give you time to find a replacement.

SBOM and Component Transparency

Without a Software Bill of Materials (SBOM), you often have no way of knowing which libraries are included in a purchased component. Therefore, check whether your supplier is required to provide an SBOM in a standard, machine-readable format, such as SPDX or CycloneDX. A one-time delivery is not sufficient. The SBOM should be updated with every new version and should fully list open-source components along with their versions. Only then can you quickly determine whether a newly discovered vulnerability affects your product.

Also, specify the purposes for which you are permitted to use the SBOM and the supplier’s technical documentation. You need them for your conformity assessment and must be able to present them in response to requests from market surveillance authorities. Many suppliers wish to treat such information as confidential, which is understandable. However, make sure that the confidentiality agreement does not hinder your ability to meet your documentation requirements.

Liability and Recourse

A vulnerability in a purchased component can be costly. Therefore, check whether the liability limits in your contract cover realistic costs, such as those for in-the-field updates, recalls, or production downtime. Often, the agreed-upon maximum amounts fall far short of these costs. Equally important is a clear provision specifying who bears the costs of remediation if the cause lies with the supplier. Whether—and to what extent—the supplier can also indemnify you against the risk of fines is not legally clear. Your legal department should review this separately.

In addition to liability, it’s worth taking a look at your oversight options. With audit rights, you can get a sense of how securely the supplier develops its software. If the supplier repeatedly fails to meet reporting or update obligations, you should have the right to terminate the contract. Finally, you can require proof of insurance, for example, for cyber risks. This ensures that your supplier can actually cover any damages in the event of an emergency.
‍

How to Bring Your Contract Portfolio Up to CRA Standards

1. Identify products and components. List which of your products contain digital elements and which purchased components they include.
2. Assign contracts. Identify the appropriate supply, license, or maintenance contract for each critical component. Often, the terms and conditions are spread across a master agreement, a quality assurance agreement, and purchasing terms.
3. Prioritize by risk. Start with components that are networked, have access to control systems, or are installed in many products.
4. Check for gaps. Go through the checklist above and document what is missing for each contract.
5. Renegotiate and adjust standards. Amend existing contracts and update your purchasing terms and templates so that new contracts are in line with your requirements from the start.
6. Establish an internal reporting process. Determine who receives supplier reports, who evaluates them, and who submits them to ENISA.

For more information on how to systematically manage supplier contracts in purchasing, see " Contract Management for Purchasing." If you are already reviewing your supply chain in accordance with the Supply Chain Act, you can easily combine both reviews.

How Contract Management Software Can Help

The most time-consuming step is usually not the renegotiation, but the search. Where is the contract with the control software supplier? What is the notification deadline specified in it? Contract management software like ContractHero takes care of this work for you:

• Centralized Storage: All supplier contracts are stored in one place and can be tagged by product or component. This way, if a vulnerability is identified, you can immediately see which contract applies.
• AI Analysis: The AI analysis scans your contracts and identifies where notice periods are missing or too long. Each instance is directly linked to the corresponding passage in the contract.
• Tasks and Deadlines: Plan renegotiations as tasks with assigned responsible parties and deadlines to ensure that no contract is left unaddressed.

For companies in the mechanical engineering, electrical engineering, and component manufacturing sectors, you can find additional use cases under " Production and Industry." Your data is stored in data centers in Frankfurt, and ContractHero is ISO/IEC 27001 certified.

Would you like to see how to check your supplier contracts for CRA gaps?

Conclusion

The Cyber Resilience Act holds manufacturers responsible for the security of their products throughout their entire lifecycle. The first strict requirement is already in effect: Starting September 11, 2026, you must report exploited vulnerabilities within 24 hours, even for products already in the field. Whether you can meet this requirement often depends on your supplier contracts. Therefore, review reporting deadlines, support periods, SBOM requirements, and liability rules now. You have until December 2027 to comply with the remaining requirements, but not with the reporting requirement.

‍