Does the Cyber Resilience Act cover your software?

1. 1. What product is being supplied?

   Identify the software or hardware product, any separately marketed component, and qualifying remote data processing. A standalone cloud service is not automatically a CRA product; the backend relationship below matters.

2. 2. Is it made available on the Union market in a commercial activity?

   If no, this product-supply route is outside scope. Free of charge is not the same as non-commercial. For open source, examine monetisation and responsibility; a steward can have separate duties.

3. 3. Does intended or reasonably foreseeable use involve a data connection?

   Include direct or indirect, logical or physical connections to a device or network. If no, the Article 2(1) connection condition is not met.

4. 4. Does an exclusion or a sector-specific rule apply?

   Check the actual product against Article 2 and applicable delegated acts. Medical-device, vehicle, aviation, marine, defence and other exclusions have specific conditions; they are not blanket industry exemptions.

5. 5. Which role, category and obligations follow?

   Record manufacturer, importer, distributor or steward responsibilities. If the product is in scope, check important or critical categories and the applicable conformity-assessment route.

These questions follow Articles 2 and 3 of Regulation (EU) 2024/2847. A supplier, a contributor and an open-source steward can participate in the same software project while carrying different responsibilities.

1. Client → a function depends on remote processing

   Would the absence of the remote processing prevent any function of the product? If no, that dependency does not meet this part of the remote-processing definition.

2. Dependent function → who designed and developed the remote software?

   If it is designed and developed by the manufacturer, or under its responsibility, it can be part of the product as a remote data-processing solution.

3. Outside the manufacturer's responsibility → external service

   A cloud service designed and developed outside that responsibility is not included on this basis. The client still needs its own scope assessment.

For example, an installed client may require its manufacturer's backend to authenticate users. Removing that backend disables a function, even if other functions still work. A third-party service is not necessarily outside the boundary merely because someone else hosts it: responsibility for its design and development matters. See Article 3(2) and recitals 11–12.

Article 32 provides an internal-control route for ordinary products as well as other conformity-assessment options. Important class I, important class II and critical products have different conditions. The core functionality, the categories in Annexes III–IV, and their technical descriptions determine the next question.

For important class I, internal control depends on applying the relevant harmonised standards, common specifications or an applicable certification scheme as required by Article 32. Class II normally requires a notified-body route; critical products can be subject to specified certification requirements. Article 32(5) provides an exception for important class I and II free and open-source products whose technical documentation is public. Select the route with the person responsible for the product assessment.

• 11 September 2026: Article 14 manufacturer reporting applies.
• 11 December 2027: the main CRA requirements apply; open-source steward reporting also starts then.
• Earlier products: Article 69 generally subjects products placed before 11 December 2027 to the main requirements only if substantially modified from that date. It separately preserves Article 14 reporting for products already made available.

The Act entered into force on 10 December 2024; its assessment-body notification provisions began applying on 11 June 2026. Use the reporting page for the event-based clocks.

Record these fields for one supplied product. Retain the source version and the person who confirmed applicability so a change to the product or business model can prompt a fresh review.

• Supplied artifact, version and supported releases; commercial model and EU market route.
• Data connections and remote-processing dependencies, including who controls their design.
• Your role, exclusions considered, category and assessment route, with rationale.
• Applicable provision, approved requirement, risk or hazard, planned verification and observed result.
• Open questions, responsible reviewers and next review date.

Illustrative engineering entry: a connected updater must reject an unsigned package. Link that approved requirement to the code change, an executed rejection test and its exact revision. Keep supported-version coverage and distribution of the remedy as separate questions. A passing test supports that behavior under its test conditions; it does not settle CRA applicability.

Proof currently links requirements, hazards, code, Changes and verification records in its graph. Product-wide release tracking, regulatory profiles and automated reporting preparation are development objectives, not a completed CRA service. Bring one scoped security Change and its required evidence to examine what your reviewer can reuse.