Rune Hillebo Wiinberg & Johan Callmyr

The Cyber Resilience Act: where should product companies start?

The Cyber Resilience Act (CRA) is changing the cybersecurity landscape for companies developing products with digital elements for the European market. For many manufacturers, the challenge is not realizing that cybersecurity matters. That message has already landed. The harder question is much more practical: Where do we start?

CRA readiness starts with understanding your current position

Especially if you already have products on the market, established development processes and technologies that were never designed around today's cybersecurity expectations.

The timeline makes preparation important. The CRA's reporting obligations have applied since 11 September 2026, while the main product cybersecurity requirements will apply from 11 December 2027. This gives product companies a clear reason to start assessing their current position now – before the main requirements take effect.

The answer is not necessarily to start implementing new security features. First, understand where you are.

Start with the gap

A GAP analysis provides a structured way to compare your current products and ways of working with the requirements you need to address. That means looking at the device itself, but also beyond it.

How is the product developed? Which software and hardware components does it contain? How are vulnerabilities managed? Can the product be securely updated? Who is responsible for cybersecurity after release? What documentation is available?

Answering those questions creates a baseline. Some organizations will discover that they already have many of the necessary processes and technologies in place. Others may find significant gaps. Both are useful outcomes. You cannot create a meaningful roadmap until you know your starting point.

Secure development from the beginning

One important area is the development process itself. Security needs to become part of how products are designed and developed rather than something checked shortly before release. Secure coding, threat modelling and cybersecurity risk assessments can help teams identify potential problems earlier.

The principle is straightforward: it is generally easier to make good security decisions when designing the architecture than to compensate for weaknesses once the architecture is fixed.

This is the foundation of security by design.

Know what is inside your product

Modern connected products often contain an ecosystem of components. Some are developed internally. Others come from suppliers, open-source projects or established software frameworks. That makes component security another important part of the picture.

Teams need to understand what their products depend on and how those dependencies are maintained. If a vulnerability is discovered in a component, you need to know whether your product is affected and what you can do about it.

This becomes particularly important for products with long lifecycles. The software that was considered secure when the product was launched will not necessarily remain so forever.

Prepare for vulnerabilities

New vulnerabilities are inevitable. The question is how prepared you are when one affects your product.

A structured vulnerability management process can help teams identify, assess and mitigate security issues throughout the product lifecycle. CVE monitoring (Common Vulnerabilities and Exposures) is one part of this. It provides information about known vulnerabilities that may be relevant to the software used in the product.

But monitoring is only useful when connected to action.

Who evaluates the alert? How is its relevance assessed? What happens if an update is required? How quickly can the organization respond?

Cybersecurity becomes much more manageable when these questions have answers before an incident occurs.

Updates need a strategy too

Once you identify a vulnerability that requires action, you may need to update products already operating in the field. That introduces another set of questions.

Can the product be updated remotely? How do you verify the authenticity of the update? What happens if an update fails? How is the new software tested before deployment? Can you control and prohibit downgrades of software to ensure that security patches actually are deployed?

Secure software updates, firmware signing and appropriate key management can all play a role.

Testing is equally important. A dedicated test environment makes it possible to qualify security updates and perform integration and performance testing before software reaches operational products.

The ability to update securely is therefore something worth designing into the product from the beginning.

Documentation matters

Cybersecurity is not only about doing the right things. Organizations also need to be able to demonstrate what they have done. That places greater emphasis on documentation and traceability.

Security requirements, risk assessments, development activities and decisions may need to become part of a structured process. For some organizations, this represents a considerable cultural change.

Informal development practices that worked well in the past may need to become documented processes with clearer ownership and responsibilities. And this highlights an important point about CRA readiness.

This is not just an engineering project

Technology may be at the centre of cybersecurity, but the changes can reach far beyond the engineering department. R&D, product management, quality, production and management may all be affected.

We have customer project where GAP analyses were conducted for different products operating across different markets and industries. The work showed that improving cybersecurity involved not only the products themselves, but also development processes, maintenance and ways of working.

Prevas therefore worked as both technical advisor and project manager, helping connect cybersecurity requirements with the wider business context.

That combination matters. A technically correct solution is only useful if the organization can implement, maintain and work with it.

Cyber Resilience Act - Turn the requirements into a roadmap

The Cyber Resilience Act (CRA) can initially feel like a large and complex challenge. Breaking it down makes it more manageable.

Map your products. Understand your risks. Review your development and maintenance processes. Identify the gaps. Prioritize what matters most. Then build a roadmap that connects cybersecurity requirements with engineering and business priorities.

The goal should not simply be compliance. Done well, the same work can create more robust products, clearer development processes and better control over the complete product lifecycle.

And that is a good place to start.

explore

Cybersecurity Insights

See all our cases and insights

About the Authors

Rune Hillebo Wiinberg is Head of Cybersecurity at Prevas and has worked professionally with embedded and secure, connected products since 2007. With experience across energy, medical technology and defense, he advises customers at all levels of the organization, helping bridge business priorities, regulatory requirements and technical product development.

Johan Callmyr is a Software Architect with more than 20 years of experience in C++ and embedded device software. He combines technical expertise with his experience in software architecture, technical leadership, cybersecurity, and development in regulated environments like medtech. As a Software Architect and Software Lead, he helps customers build robust, secure, and safe software solutions for complex products.