The Cyber Resilience Act for Software Manufacturers: A Guide

· Yunus Yildiz

This guide follows the questions a software company asks about the Cyber Resilience Act, in the order it usually asks them. Every section links to a longer post and to the verbatim article text in the CRA library. Dates are in the timeline.

1. Are You a Manufacturer?

You are if you develop a "product with digital elements", or have it developed, and market it under your own name or trademark, "whether for payment, monetisation or free of charge" (Article 3). Software counts, installed or embedded, and so do components placed on the market separately, such as libraries. There is no size threshold.

  • SaaS: standalone SaaS is not a product under the CRA, but the backend of an app, client or agent you ship can be part of that product as a remote data processing solution. See does the CRA apply to SaaS.
  • Open source: stewards of open-source software have a lighter regime (Article 24); integrating open source into your own product makes it your responsibility (section 5).

2. What Applies Already: Reporting

Since 11 September 2026, Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents affecting the security of their products: an early warning within 24 hours, a notification within 72 hours, and a final report. It covers products placed on the market before 11 December 2027 too, and it continues after a product's support period ends.

3. What Applies From 11 December 2027: the Essential Requirements

Annex I has two parts.

Part I, the product. Based on a cybersecurity risk assessment (Article 13(2)-(4)), products must be made available without known exploitable vulnerabilities and with a secure default configuration, and must address among other things security updates, protection against unauthorised access, confidentiality and integrity of data and programs, data minimisation, availability, limited attack surfaces and logging of relevant internal activity.

Part II, vulnerability handling. Identify and document components, including by drawing up an SBOM; remediate without delay; test regularly; disclose fixed vulnerabilities; run a coordinated vulnerability disclosure policy; share information; distribute security updates securely and, where applicable, automatically, free of charge.

4. The SBOM

Annex I, Part II, point (1) requires an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies". It applies from 11 December 2027, it goes into the technical documentation, and manufacturers are not obliged to publish it (recital 77). Customers under NIS2 will ask for more. See what the CRA actually requires of an SBOM, clause by clause.

5. Third-Party and Open-Source Components

Article 13(5) requires due diligence when integrating components from third parties, "including when integrating components of free and open-source software". Article 13(6) adds that a vulnerability you find in a component must be reported to whoever maintains it and remediated in your product. See the due diligence obligation most teams overlook and, for images, container supply chains and EU sovereignty.

6. The Support Period

You decide how long each product gets its vulnerabilities handled, based on how long it is expected to be in use, with at least five years unless it is expected to be used for less (Article 13(8)). You publish the end date, month and year, at the time of purchase, and keep security updates available for at least ten years. Versioned software can limit fixes to the latest version if upgrading is free. See five years is a floor, not a default.

7. Showing Conformity

Before placing a product on the market you draw up the technical documentation (Annex VII), carry out a conformity assessment, sign an EU declaration of conformity (Annex V) and affix the CE marking. The route depends on the product's category (Article 32):

Category Conformity assessment
Default Internal control (module A) is allowed
Important, class I (Annex III) Module A only if harmonised standards, common specifications or a certification scheme at level "substantial" are fully applied; otherwise module B+C or H
Important, class II Module B+C, H, or a certification scheme at level "substantial" or higher
Critical (Annex IV) A European certification scheme where required under Article 8(1); otherwise as class II

Free and open-source products in Annex III categories may use any route if their technical documentation is public (Article 32(5)). Keep the documentation and the declaration for at least ten years or the support period, whichever is longer (Article 13(13)). See when self-declaration is not an option.

8. What Non-Compliance Costs

Fines of up to EUR 15 million or 2.5% of worldwide turnover for the essential requirements and Articles 13 and 14, with lower tiers for other obligations and specific derogations for micro and small enterprises and open-source stewards (Article 64). See three tiers, real carve-outs.

9. Your Customers and NIS2

The CRA regulates your product; NIS2 regulates many of your customers, and reaches you through their duty to assess "the overall quality of products and cybersecurity practices of their suppliers". Expect questionnaires, and prepare the answers once per release.

10. What the Commission Has Said

The Commission's FAQ and its application guidance of 27 July 2026 do not change the law, but they narrow how it is read on scope, substantial modification, remote data processing, support periods and reporting. See what actually changed in July 2026.

A Short Checklist

  1. List every product you place on the market, including clients, agents, libraries and self-hosted editions, and decide which are in scope.
  2. Put the Article 14 reporting process in place now: coordinating CSIRT, submitting role, product and version data, user notification.
  3. Classify each product (default, important class I or II, critical) using Annex III, Annex IV and Implementing Regulation (EU) 2025/2392.
  4. Start the risk assessment and the technical documentation per product.
  5. Make the build produce per-release evidence: SBOM, vulnerability status, signatures, provenance.
  6. Set and publish support periods; decide your policy on older versions.
  7. Choose the conformity assessment route and, where needed, a notified body early.

Sources

This guide summarises our reading of the Regulation as of the date above and is updated when the linked posts change. It is not legal advice.