Case Study: CRA Software Applicability and EU Declaration of Conformity Boundaries Across a Mixed Product Portfolio

Why the EU Declaration of Conformity Is Not a Simple Form

A manufacturer may ship computers, firmware, apps, SDKs and online services under one brand. The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) asks it to prepare an EU Declaration of Conformity (DoC) for products with digital elements. The hard part is the CRA product boundary: what counts as one product, and what counts as a separate one? A case study tests this question on a mixed product portfolio. It shows that the answer comes from supply facts and function, not from labels.

First, Decide If the Software Is in Scope

Software Compliance Starts With Data Connections

The CRA applies to products made available on the EU market in the course of commercial activity. Their intended use must involve a direct or indirect data connection to a device or network. Offline software on a normal PC can still qualify, because it connects indirectly through the operating system. Free of charge does not remove a product from scope.

Required Backends Belong to the Product

A website that only offers promotions or product registration is usually not a separate CRA product. A backend that a delivered product needs is different. For example, a remote access tool may need account login to work. That backend is assessed and declared with the product, usually without its own DoC.

Draw the CRA Product Boundary

Software Shipped With Hardware

Firmware, BIOS and drivers delivered with a computer are normally covered by the assessment and DoC for the whole machine. Technical documents should name the software and its versions. A downloadable update does not automatically become a separate product.

Software Supplied on Its Own

A system management app, a router app or offline image software needs its own assessment and DoC when it is supplied alone. Adding an app name to a hardware DoC does not replace a real assessment.

SDKs and Internal Tools

Treat an SDK given to outside developers as in scope unless you can prove an exclusion, such as true free and open source, non-commercial supply. A tool made and used only inside one legal entity may be excluded. If its flow is unknown, mark it “to be confirmed,” not “excluded.”

What an EU Declaration of Conformity Must Cover

A DoC must identify the product it covers. The technical documents behind it must show the software versions that affect compliance and the system architecture. Article 28 says the declaration should be updated as appropriate. This does not mean a new DoC for every installer or minor update. It does mean you should not keep using an old declaration after the product boundary or a compliance-relevant version has changed.

If one product falls under several EU laws that require a DoC, a single declaration can combine them. This is about one product across several laws. It does not mean every standalone software product can be folded into a hardware DoC.

Plan for the Dates

Main product obligations apply from December 11, 2027. Products placed on the market earlier need a check for substantial modification after that date. Reporting duties under Article 14 have applied since September 11, 2026, and they also reach products already on the market. Keep the declaration timeline separate from the reporting timeline.

Build an Evidence File for Each Item

For each software item, record the product name, version, EU supply region, manufacturer, license, supply route, data connections, required backends, SBOM, risk assessment and test evidence. Then mark it “in scope,” “excluded under stated conditions” or “to be confirmed.” Shared records help engineering, legal and compliance teams agree on one answer.

Key Takeaways

• Decide the declaration unit for every item. Mark each software item as part of the whole machine or as standalone software before you write any DoC.
• Name the product and version on the DoC. Make sure the declaration, technical documents and SBOM all point to the same product and software versions.
• Do not rely on a hardware DoC to cover standalone apps. Give each standalone app its own assessment, and reuse shared evidence only where the scope clearly matches.
• Include required backends in the product’s assessment. If a delivered product cannot use a function without a backend, assess the two together.
• Treat unknown flows as “to be confirmed.” Until license, recipient and use are clear, do not mark SDKs or internal tools as excluded.
• Set a review trigger for old declarations. Re-check the DoC whenever the product boundary, supply route or a compliance-relevant version changes.
• Plan for December 11, 2027, and start Article 14 reporting now. Keep the two timelines separate in your project plan.

Source of article
Case study: “CRA Software Applicability and EU Declaration of Conformity Boundaries Across a Mixed Product Portfolio” (version 1.0, legal check date October 21, 2026).
Regulation (EU) 2024/2847 (Cyber Resilience Act): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847