CRA Software Readiness

A fixed-price project from €4,900 in which I compare your software development against the technical requirements of the EU Cyber Resilience Act (Regulation (EU) 2024/2847): release processes, dependencies, Software Bill of Materials, vulnerability management, update and patch processes, and evidence. The result is a gap analysis, a prioritised roadmap and an effort estimate for your team. For a first impression of where your development stands, take the CRA self-check with eight questions, no sign-up required.

The CRA applies to products with digital elements placed on the EU market, which covers most commercial software and connected hardware. Products with their own EU regulation are excluded, for example medical devices under the MDR, vehicles and aviation. The technical classification of your product is part of the analysis; the legal assessment remains with your lawyers.

The CRA distinguishes default products, important products of classes I and II (Annex III) and critical products (Annex IV), classified by core functionality. Most software products and machines are default products and are assessed by the manufacturer; PLCs, HMIs and SCADA are not in the annexes. Important products such as operating systems, routers, firewalls or microcontrollers with security functions need harmonised standards or a notified body, depending on the class. The legal classification remains with your lawyers; the analysis records the technical core functionality and its consequences for procedure and effort. An overview of the classes is in the article Implementing the CRA technically.

Since 11 September 2026, reporting obligations apply for actively exploited vulnerabilities and severe security incidents. From 11 December 2027, all other requirements of Regulation (EU) 2024/2847 apply, including CE marking, for products placed on the market from then on.

Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents: an early warning within 24 hours, a notification within 72 hours and a final report, for vulnerabilities no later than 14 days after a corrective measure is available. Reports go via the single reporting platform to the competent CSIRT and ENISA. This requires a process that detects and assesses vulnerabilities and makes a report possible within a day, including at weekends. The gap analysis shows how far you are from that.

Yes, under the CRA it is. Manufacturers must know their product's components and keep an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. Without that overview you cannot quickly tell whether your product is affected by a newly disclosed vulnerability. An SBOM generated automatically in the pipeline is usually one of the first items on the roadmap.

For the entire support period, which reflects the expected time of use of the product and is generally at least five years. Each security update must then remain available for at least ten years. That is only affordable with a release process that ships updates quickly and reliably, which is why build, testing and delivery are part of the analysis.

A declaration of conformity is only possible once all requirements are met. What you can show is a documented status and a plan: the gap analysis, the prioritised roadmap and, once implemented, an SBOM and a described process for vulnerabilities and updates. That answers most questions from purchasing and tenders factually.

The manufacturer is responsible, meaning the company as a whole. In practice the CRA affects development, quality assurance, product management and legal at the same time, which is exactly why nobody feels responsible. The roadmap assigns each measure to a role, so it is clear who implements what by when.

Better not. The essential requirements are set out in Annex I of the regulation and will not change; the standards only describe how to meet them demonstrably. Changes to development and release processes take time, and the reporting obligations already apply. Laying the technical foundations now means you only have to align with the standards later.

No. The analysis is technical: it shows what needs to be done in development, build, supply chain and operation. Legal classification, conformity assessment and certification remain with your lawyers and, where required, a notified body. The results are structured so they can serve as a basis there.

Yes, in two steps, each at a fixed price. First the gap analysis with roadmap and effort estimate from €4,900, then, on that basis, an offer for the technical implementation in your pipeline. A flat price before the analysis would not be credible, because the scope depends on the current state of your development. Legal assessment and conformity assessment remain with your lawyers or a notified body.

Yes, if you wish. Typical follow-up work includes SBOM generation in the pipeline, automated vulnerability scanning, signed updates and a documented patch process, for example in GitLab CI/CD or GitHub Actions. This comes as a separate fixed-price offer based on the roadmap.