CRA readiness goes far beyond the legal text. In practice, it is reflected in how cybersecurity risks are addressed in product development, whether the components used in the product are known, how vulnerabilities are monitored and handled, and whether responsibilities have been defined before the first serious incident occurs.
compliancereliabilitysoftware development
CRASecurity
CRA readiness means that a company is able to put cybersecurity requirements into practice as part of the product, product development, and lifecycle maintenance. In practice, this includes understanding product-related risks and software components, having effective processes for vulnerability handling and reporting, and defining clear responsibilities across the organization. There is no single ready-made model for CRA readiness; the necessary actions must be determined based on the company’s own product and existing ways of working.
The Cyber Resilience Act (CRA) is an EU regulation that sets cybersecurity requirements for products with digital elements, such as software and connected devices. The requirements apply to the design, development, manufacturing, and maintenance of a product throughout its lifecycle. The CRA reporting obligations took effect on 11 September 2026, and the regulation will apply broadly from 11 December 2027 onwards.
CRA readiness goes far beyond the legal text. In practice, it is reflected in how cybersecurity risks are addressed in product development, whether the components used in the product are known, how vulnerabilities are monitored and handled, and whether responsibilities have been defined before the first serious incident occurs.
A company’s practical readiness is built around the product, product development, and the organization’s ways of working. This is why CRA requirements need to be considered in the context of the company’s own product and current practices.
A company’s CRA readiness cannot be assessed on the basis of a single certification, standard, or checklist. The impact of the requirements depends on the product, its features, operating environment, and lifecycle. According to Mika Maunumaa, Wirokit’s Mission-Critical Software Engineer, one of the key starting points for CRA readiness is understanding what the requirements mean for the company’s own product.
The extent of the CRA’s impact can vary significantly from one product to another. A simple product with limited connectivity may require fewer measures, while a product that includes network connections, services, and multiple software dependencies may involve a broader set of requirements. Companies therefore need to assess the impact of the CRA on a product-by-product basis rather than trying to build readiness around a single generic model.
CRA readiness becomes very concrete when a vulnerability is discovered in a product. At that point, the organization should already know who takes ownership of the finding, how its severity and risks are assessed, whether the CRA reporting criteria are met, and how the necessary follow-up actions are initiated.
Vulnerability handling may involve several activities taking place in parallel: internal assessment, regulatory reporting, initiating corrective actions, and communicating with users or customers. The key is to define responsibilities and procedures in advance and to have a process in place for receiving and handling vulnerability reports from external parties.
“If a serious vulnerability is discovered, the organization should already know who responds, who assesses the situation, and how the issue is taken forward. You cannot start building the process once the situation is already unfolding”, Maunumaa explains.
Readiness also requires the company to know which software components and versions are used in its product. Without this information, it is difficult to assess whether a newly discovered vulnerability affects the product. An SBOM, for example, serves as a practical tool for managing software components and vulnerabilities.
The CRA does not necessarily mean that a company needs to adopt entirely new technologies at every stage of product development. The bigger change may lie in how existing work is managed and which aspects are addressed systematically throughout the development process. Cybersecurity requirements need to be identified during requirements definition, the suitability of the architecture needs to be assessed against the relevant threat environment, and implementation and testing need to ensure that cybersecurity is integrated into normal development work.
According to Maunumaa, the CRA brings practical changes and refinements to several stages of the product development process. The challenge is therefore not always about building a new technical solution, but about changing established ways of working.
“The CRA brings changes to different stages of product development in practice. The biggest challenge may be changing established ways of working in areas where cybersecurity has not previously been addressed systematically enough,” Maunumaa says.
For many companies, building CRA readiness therefore means refining existing product development processes and embedding the new requirements into normal day-to-day work. These measures improve cybersecurity while also contributing to overall quality.
CRA readiness cannot be built as the responsibility of the cybersecurity team or a single specialist alone. In practice, the required changes affect product development, cybersecurity, quality assurance, and often also compliance and product-related responsibilities. This means the work needs a shared direction and clear decision-making.
Maunumaa particularly emphasizes the role of management. Without genuine management support, it is difficult to put the necessary changes to working practices and product development processes into practice. Simply assigning formal responsibility is not enough; management must also enable the changes through adequate resources and decision-making.
“This type of change starts with the company’s management. Without support, resources, and decision-making authority, it is difficult to put the necessary changes to working practices into effect,” Maunumaa says.
Clear responsibilities are just as important as management support. The organization needs to know who owns CRA readiness, who is responsible for vulnerability handling, who makes the necessary decisions, and how information flows between different roles. When responsibilities are agreed in advance, the CRA does not remain a separate project but becomes part of the organization’s normal operations.
Building CRA readiness should begin with forming a realistic view of the company’s current situation. The first step is to understand what the CRA means for the company’s own product, which requirements are already being met in product development, and where gaps still remain. Only then can the company determine which working practices, responsibilities, or technical solutions need to change.
The key is to align the necessary actions with the actual needs of the product and its operating environment. Not everything needs to be rebuilt from scratch, but the essential gaps must be identified and addressed systematically. At the same time, the company should assess whether the required expertise is available internally or whether training or external expert support is needed.
Once the current state is understood, the necessary changes can be prioritized and introduced step by step into product development, vulnerability management, testing, and maintenance.
Wirokit helps companies identify what the CRA requirements mean in practice for their own product and implement the necessary changes as part of the product and its development process.
CRA readiness does not come from a single standard, technical solution, or reporting process. It is built by understanding the requirements that apply to the company’s own product, identifying the key risks and gaps, and integrating the necessary changes into product development and the product’s entire lifecycle. When responsibilities are clear, effective vulnerability handling practices are in place, and management is prepared to support the necessary changes, CRA requirements become part of the organization’s normal operations and structured product development.
R&D Partner & Expert in Mission-Critical Software & QA
Harder code
