Software publishers & CRA: product security becomes mandatory

What does the CRA cover?

The CRA targets 'products with digital elements': software and hardware connected directly or indirectly to a network. It defines essential cybersecurity requirements and vulnerability management obligations, with 'important' and 'critical' categories subject to stricter assessments.

Specific regimes exist, notably for non-commercial open-source software and products already covered by an equivalent sectoral regulation.

Is the 'Software Publishers' sector concerned?

Any software publisher placing software on the European market is, in principle, a manufacturer of a product with digital elements. The level of requirements depends on the criticality of the product: most software falls under the baseline regime, while certain products (security tools, sensitive components) fall under the enhanced categories.

A lighter regime applies to non-commercial open source; however, an open-source component integrated into a commercial product remains the responsibility of the publisher who commercialises it.

Detailed obligations

Sanctions & risks

Failures to meet essential cybersecurity requirements can be sanctioned by fines of up to €15M or 2.5% of global turnover; other infringements fall under lower thresholds. Non-compliance may also result in the withdrawal or recall of the product from the market.

For a software publisher, the challenge is twofold: the penalty and market access, with cybersecurity CE marking becoming a condition for commercialisation.

Application timeline

• 1Entry into force. End of 2024.
• 2Notification obligations. Applicable approximately 21 months after entry into force (during 2026).
• 3Full requirements. Applicable approximately 36 months after entry into force (horizon 2027).

Common mistakes in the sector

• 1"CRA = hardware only". Believing the CRA only targets hardware, when software qualifies as a product with digital elements.
• 2No SBOM. Ignoring the software bill of materials, making vulnerability management impossible.
• 3Absence of a patch management policy. Failing to guarantee updates over the support lifecycle.
• 4Unreported vulnerabilities. Omitting notification of actively exploited vulnerabilities.

Practical case

A publisher of widely deployed software discovers that an integrated open-source dependency has an actively exploited vulnerability. Using its SBOM, it identifies affected versions within hours, publishes a patch under its support policy, and notifies ENISA — a chain of response required by the CRA and impossible without a software bill of materials or a PSIRT in place.

Compliance roadmap

1. 1

   Establish an SBOM. Map all software components and their dependencies.

2. 2

   Set up a PSIRT. Structure vulnerability management and coordinated vulnerability disclosure.

3. 3

   Defining the support period. Setting and communicating the patch supply duration.

4. 4

   Preparing compliance. Build the technical documentation and conformity assessment in preparation for CE marking.

5. 5

   Equip the notification process. Implementing the process for notifying exploited vulnerabilities to ENISA.

Frequently asked questions