Product innovation
8
minutes reading time

Cyber Resilience Act: How you can reinvent your product portfolio

If you use the Cyber Resilience Act wisely, you can make clean decisions about legacy portfolio issues, modernize product lines and bring cybersecurity to the market as a differentiating feature.

contributors
Niels Trapp
Niels Trapp
Management Consultant, Business Trainer

A law that is more than just bureaucracy

When the EU passes new laws relevant to industry, there are usually two reflexes. The first reflex is called “effort.” The second reflex is “This is an IT topic.” With the Cyber Resilience Act, a third reflex is worthwhile. The CRA is an opportunity to consistently look at your product portfolio through the lens of “connected, updatable, responsible”, and has actually been doing so since 2023. Nevertheless, many companies did not react to the CRA requirements until late, and so CRA was a very frequently discussed topic at the SPS 2025 exhibition.

The CRA addresses products with digital elements, i.e. networked products and software that are placed on the market. For many machine manufacturers, plant manufacturers and component providers, this means that cybersecurity is moving from the edge to the center. It will no longer just be an issue for the customer's service laptop or network plan, but part of what you as a manufacturer must deliver, document and secure over the life cycle.

That sounds like regulation, and it is. At the same time, it is a strategic trigger. If you use CRA wisely, you can make clean decisions about legacy portfolio issues, modernize product lines and bring cybersecurity to the market as a differentiating feature.

What the CRA requires from companies

The basic logic is simple, but the consequences are not. The CRA requires manufacturers to ensure the cybersecurity of their products over the entire life cycle. This includes identifying and fixing weak points and addressing them in the long term through updates.

Two things are particularly relevant for practice in mechanical engineering.

  1. First: Life cycle becomes a manufacturer's task. It is not enough to “develop safely.” They must also “operate securely” in terms of updatability, vulnerability treatment and clear responsibilities within the company.
  2. Second: Report a process, not an individual case. There are reporting requirements with short deadlines for actively exploited vulnerabilities and serious security incidents. This is not an issue for the drawer, but must function as a repeatable process, including the ability to communicate internally and externally.

Why “concerns us all” is true but falls short

Yes, in principle, the CRA concerns every product that includes connectivity. In practice, however, this purely technical question rarely determines the right product strategy. The combination of technical, economic and market factors is really decisive.

I always see five factors as decisive:

  • Updatability in the real installation: Can you actually roll out updates in the field, even for typical brownfield customers?
  • Age of architecture and components: How much technical debt is there in firmware, libraries, operating systems and third-party components?
  • Installed base and remaining life: How large is the base and how long must it be maintained economically and safely?
  • Margin logic and serviceability: Can you map security costs in price, maintenance contract or service packages?
  • Strategic role of the product line: Cash cow, platform, entry-level product, door opener or already discontinued model?

It is only when you bring these factors together that it becomes clear whether the CRA triggers a product upgrade for a product family, requires a redesign, or makes a phase-out appear rational.

The opportunities for your product portfolio

CRA's requirements can serve as a catalyst for strategic change. Four opportunities are particularly relevant.

1) Technological modernization, but targeted

The CRA creates the opportunity not only to “maintain” outdated technology, but to make conscious decisions. Not every product line deserves a redesign. Some deserve a controlled end. Others need a consistent architecture upgrade so that updates, secure configuration and maintainability are even possible.

2) Added value through security, as a buyable argument

Cybersecurity is increasingly being part of tenders, IT approvals and risk checks for customers. Products that meet comprehensibly high safety requirements reduce friction in sales and create trust. “Safe” is not a label, but a value proposition, which must be covered by an update concept, support period and documentation.

3) New business models because updates and support must be planned

When updates and vulnerability treatment are established as mandatory capabilities, this results in clear product performance. This service can be translated into service and subscription models. Examples include security updates as a service, staggered response times, or managed services for customers who do not want to build up appropriate resources themselves.

4) Sustainability and longevity, as digital product quality

Digital longevity means that a product remains safe to operate for years because it is maintained, updated and supported with clear responsibilities. This reduces unplanned replacement cycles and promotes a more rational use of product generations. Especially in mechanical and plant engineering, this is more than just an image point. It is part of your customers' ability to deliver.

Upgrade, redesign or phase-out: The CRA as a portfolio sorting machine

The CRA doesn't force you into a single solution. It forces you to make decisions. And that is exactly the opportunity.

A Product upgrade often makes sense when the architecture is fundamentally updatable or can be updated with manageable effort, when the installed base is large and the product line remains strategically relevant, and when security gaps can primarily be managed through processes, hardening and update mechanics.

A Redesign is usually useful when an updatable architecture is virtually impossible to retrofit, when central third-party components or operating systems are no longer viable, or when the product line is intended to serve as a platform for new digital functions.

A phase-out On the other hand, is a clean option when the product line has lost strategic importance, when the installed base and market perspective are low, or when the security costs no longer fit economically into a plausible offer.

It is crucial not to evaluate these options morally. A phase-out is not a defeat. It is often the most professional form of product care. However, this also requires cutting off many of your beloved old braids.

How you can use CRA strategically

To use the CRA not just as a duty but as an opportunity, you should take a structured approach.

  • Portfolio analysis: Review your portfolio for updateability, component risks, support period, and installed base. Work with simple scoring that combines technology, market and profitability.
  • Investing in Innovation: Don't just invest in tools, invest in skills. A functioning process for treating vulnerabilities is at least as valuable as a new security feature.
  • Customer centricity: Customers don't want “more security.” They want less risk, less downtime and clear statements. Translate CRA capabilities into understandable product promises.
  • Communication: Make your safety standards part of your product story. Transparency is not an image issue here, but a building of trust that has an effect on approvals and purchasing decisions.

CRA as a portfolio upgrade

A medium-sized company from the automation industry used CRA requirements to revise its IoT-enabled products. In addition to improving cybersecurity, new functions such as extended predictive maintenance have been integrated. The result was a significant increase in customer satisfaction and sales growth of 15 percent in the first year after the introduction of the revised product line despite a recession.

The interesting thing about this is not so much the number as the pattern. The CRA was not run as a separate compliance stream, but as an opportunity to technically modernize the product line and visibly increase customer benefits.

Conclusion: The CRA as a driver of innovation

The Cyber Resilience Act is no barrier. It is an opportunity to make products safer, more modern and easier to control over the life cycle. The lever comes when you treat CRA work not as a documentation requirement, but as a portfolio decision-making framework.

The question isn't whether you adapt. The question is whether you're using the pressure to adapt to sharpen your portfolio, modernize product lines, and establish security as part of your value proposition. Be bold, think strategically, and make CRA your competitive advantage.

If you want to use the CRA as an opportunity to make a structured decision about your portfolio, then let's talk about it. I support you in properly evaluating the upgrade, redesign and phase-out per product family and turning this into a roadmap that brings technology, market and profitability together. Get in touch with me

Five questions to ask yourself after this post

  1. Which product families are economically strong enough to seriously support a defined support period, including the ability to update, and for which would that be a promise of good weather?
  2. Where is our biggest “update gap” in the field, i.e. where updates work in theory but fail in practice due to architecture, customer environment or process?
  3. Which third-party components are our biggest risk because dependencies, patches, and transparency are out of our control, and how do we change the procurement and approval model?
  4. How quickly are we able to turn a weak point into reliable customer communication plus a fix plan, and who carries out this responsibility from end to end?
  5. What portfolio decision would you make if you treated security expenses like a real product cost block, and not as “something from quality assurance”?

Sources

Internet sources

  • European Commission, Directorate-General for Communications Networks, Content and Technology (2025): Cyber Resilience Act, [online] URL [accessed 04.01.2026]
  • European Commission, Directorate-General for Communications Networks, Content and Technology (2025): Cyber Resilience Act — Reporting Obligations, [online] URL [accessed 04.01.2026]
  • Federal Office for Information Security (2025): Cyber Resilience Act, [online] URL [accessed 04.01.2026]