Cyber Resilience Act: what software manufacturers must have done by the end of 2027

Quality and security

Since 11 September 2026, manufacturers have had to report actively exploited vulnerabilities in their products – including products that have been on sale for a long time. From 11 December 2027, the Cyber Resilience Act applies in full. If you sell software or devices containing software in the EU, you have just over a year left to adapt your products and processes.

Who the CRA applies to

The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to products with digital elements placed on the EU market. These include devices with their own control software as well as pure software, such as desktop programs or CAD add-ins. A manufacturer is anyone who markets such a product under their own name or trademark, whether for payment or free of charge. Some product groups with their own rules, such as medical devices, are excluded.

The deadlines

Your tasks by the end of 2027

1. Set up the reporting channel – now. For an actively exploited vulnerability, an early warning is due within 24 hours, a notification within 72 hours and a final report no later than 14 days after a fix is available. The same deadlines for early warning and notification apply to severe incidents. Reports are submitted via ENISA’s single reporting platform. Decide who receives, assesses and reports such information – including during holidays.
2. Classify your products. Which products and versions are affected? Is a product a default product, an important product or a critical product? This determines whether you can assess conformity yourself or need a notified body.
3. Create a software bill of materials (SBOM). The CRA requires an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies. Ideally it is generated automatically with every build, for example in CycloneDX or SPDX format.
4. Handle vulnerabilities. Regularly compare your components with public vulnerability databases. You need a contact address for external reports, a policy for coordinated vulnerability disclosure and regular security testing. Publish fixed vulnerabilities with a description for users.
5. Define your update process. Security updates must reach customers without delay and, as a rule, free of charge – where technically feasible, separately from feature updates. The support period is generally at least five years. Each security update then remains available for at least ten years or until the end of the support period, whichever is longer.
6. Secure the product. Requirements include: no known exploitable vulnerabilities on delivery, a secure default configuration with the option to reset it, protection against unauthorised access, encryption, the smallest possible attack surface and logging of security-relevant events.
7. Document. The technical documentation covers the product description, architecture, cybersecurity risk assessment, vulnerability handling procedures and user information. It forms the basis of the EU declaration of conformity. You must keep both for at least ten years or for the support period, if that is longer.

Where to start

Start with what already applies today and pays off everywhere later: the reporting channel and the SBOM. Without an SBOM, you won’t know in an emergency whether a newly disclosed vulnerability affects your product – and the 24-hour deadline is running all the same. Automated tests are another building block. The CRA requires you to test the security of the product regularly and effectively. Tests that run with every build provide traceable evidence for this.

Infringements of the essential requirements or of the obligations under Articles 13 and 14 can lead to fines of up to EUR 15 million or up to 2.5 percent of worldwide annual turnover, whichever is higher.

Note: This article gives a technical overview and is not legal advice. Please clarify the binding classification of your product with your legal department or lawyers.

Typical mistakes

• Waiting for 2027. The reporting obligations have applied since 11 September 2026, for new and existing products alike.
• “Our product is old, this doesn’t affect us.” Reporting is still required. And if you substantially modify an existing product after 11 December 2027, it must then meet all requirements.
• Creating the SBOM once by hand. It is out of date with the next build. It belongs in the build process.
• Overlooking purchased and open-source components. Vulnerabilities often hide in libraries, not in your own code.
• Shipping security updates only together with new features. Customers should be able to close a gap without rolling out a new version.
• No dedicated contact address. Vulnerability reports end up in the general inbox and stay there.

Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act), in particular Art. 13, 14, 64, 69 and 71 and Annex I, EUR-Lex; Cadida: Cyber Resilience Act. As of October 2026.