This post is the third part of a series of blog posts, where we discuss the impacts of the new EU Cyber Resilience Act and compare it briefly to the industrial cybersecurity standard IEC 62443.
In this Part 3, we will discuss the practical implications that the act does not directly spell out but that are likely to be relevant for product manufacturers. As we’ll see, the practical implementation of the act may present a major challenge to product manufactures and cybersecurity practitioners. To get the most out of this post, you should first familiarise yourself with the basic requirements of the act by reading Part 1 of this blog post series.
Overview
The following diagram summarises one way of arranging the implications of the Cyber Resilience Act in the case of a product manufacturer, who have a large and complex product portfolio. Notice that the arrangements of the diagram are not necessarily the only way or even the best way to ensure compliance in your case, as the practical implications of the act may differ significantly depending on the nature of the product and the size of the operation. Not all consequences that we discuss here may be relevant to your product development. The diagram is inspired by a diagram that Antti Lehvonen posted on LinkedIn.
The boxes in the diagram represent functions, the person symbols represent the leaders or the representatives of the functions, and the arrows are actions that point from the subject to the object.

Secure Development Lifecycle and DevSecOps adoption
We already noted in Part 1 that product development teams will have to apply a design, development, manufacturing, and maintenance process that ensures an appropriate level of cybersecurity. Software Bill of Materials (SBOM) need to be managed. There is a requirement to apply effective and regular tests and reviews. In practice, you need to ramp up a Secure Development Lifecycle (SDL) process. In our diagram above, we assume that the organisation has defined a common Secure Development Lifecycle process, with common tools, trainings, process descriptions and so on. The tools include a range of DevSecOps tools for documentation, source code management, continuous integration, archiving, and automated testing.
However, adopting an SDL process and DevSecOps practices is not an easy task. If the organisation is just starting, the adoption requires a new attitude, training, and potentially significant changes to the current ways of working. To be sustainable, this change must be implemented gradually, and it often requires a lot of facilitation and support from cybersecurity experts.
Security testing is an essential part of an SDL process. The Cyber Resilience Act requires effective tests and reviews, and since you need special skills and tools to perform security testing, it is often practical to have an independent testing team, as illustrated in the overview diagram above.
Given the current lack of SDL experts on the job market, a sudden mass adoption of SDL across the European Union will certainly present challenges. As cybersecurity practitioners, we need more scalable methods of adopting secure development practices, using various self-service models that could be run by security champions, developers, and test engineers.
Platform thinking
Most products that have digital elements rely on an operating system. An industrial product may rely on some network devices such as routers, firewalls, and switches. You may have dependencies to a hypervisor, or to a certain monitoring or access control products or library components. Let’s call all this stuff as the underlying infrastructure platform, just for convenience.
It’s not uncommon for a product development team to focus on their value-adding business logic and application functionality, and largely ignore the above-mentioned infrastructure platform as far as possible. In large product companies, it is also not uncommon for different product units or development teams to use completely different solutions as their infrastructure platform.
Some of the essential requirements in the Cyber Resilience Act affect the application-level implementation as well. Again, it’s not uncommon for the different teams of a large product company to use completely different application platforms and application frameworks.
To implement the requirements of the act in a company that has a large product portfolio without wasting too much time and money on fragmented and redundant implementations seems to call for more platform thinking. When we consider the need to maintain the product portfolio, and the possible cybersecurity-related lifecycle services that the product manufacturer may want to offer to its customers, platform thinking will suddenly seem a great idea.
Our overview diagram above illustrates this with the Common platforms function, headed up by the Chief Technology Officer (CTO). The common platforms could include, for example, technology selections for operating systems, hardware, application frameworks, network devices, as well as, cybersecurity technologies such as software update mechanisms, digital signing, access control, and log management.
Maintenance and long term supported versions
In many industries, it is already obvious that software needs to be maintained, and software updates must be offered. However, there still are product teams who focus their efforts exclusively on the next software version, which will be bundled with the next new products and not offered as an update to existing customers.
If a product development team has not had a maintenance plan and a mechanism to update software so far, then they are in for a rather extensive development effort and a change of priorities in their development.
Especially when we’re dealing with products that have long lifetimes, such as many typical industrial products, the installed base of a product development company may consist of even tens of different product versions. It’s easy to see that developers won’t be able to support all these versions separately. The typical solution is to define certain long term supported (LTS) versions and try to migrate the users into a small number of supported LTS versions.
Version compatibility
Another implicit consequence of maintaining software and providing software updates is the need to worry about version compatibility. When you update the software of a product that is already in use, then the users typically expect their data and configuration to work after the update. This is possibly only if the two software versions are compatible. You may implement this with data migration features, explicit support for versioning in various data structures and compatibility testing.
Spare hardware capacity
If the product has a long lifetime, then the product manufacturer may have to provide support for a lot longer than the five years that the act requires. In operational technology (OT), for example, product lifecycles can be even decades long.
Let’s make a thought experiment. Assume you’ll have to maintain a customer delivery for 14 years, and that you make an annual software release, which will include not just security updates but the latest functional development. This could be done to focus development and testing efforts on a single code base. Assume that each software update requires 5 % more hardware capacity, such as storage space, RAM or CPU capacity. The miracle of compound interest yields that the 14th software version will end up requiring 1.05 14 times the original capacity, which equals twice as much capacity than the first version. If you think that a 5% annual increase and a 14-year maintenance period are extreme examples, then you can repeat the experiment with your own assumptions.
The consequence is that you should include some spare hardware capacity in the product deliveries, and that you should measure the performance requirements of new software versions and consider excessive increase in resource usage as a compatibility break.
Product roadmap
Making software updates, maintaining the technology selections and building the required cybersecurity functions is hard if you have a legacy tech stack. One of the consequences of the Cyber Resilience Act may be a renewed product roadmap. You could analyse the current product portfolio and the product roadmap, and divide the products into a few categories:
- Products that have modern enough technologies to be maintained and brought to the era of CRA compliance
- Products that are so important that they need to be updated to be CRA compliant, but require a technology renewal. The renewal could be done as part of a common platform adoption roadmap.
- Products that are built on legacy technologies and where the gaps to make them maintainable and CRA compliant are too big in comparison with the business importance to justify the effort. These products are considered legacy products that will be phased out.
Archiving
One of the requirements we noted in Part 1 of this blog post series was archiving the software, Software Bill of Materials (SBOM), technical documentation, including specifications and evidence of security testing, and user manuals for at least 10 years.
This requirement calls for a quality process that can store all this in its original form for a long period of time. If a development team is only working on the tip of the current code and documentation, some new practices and tools will have to be established. Exporting stuff from your enterprise wiki manually as PDFs for archival purposes is hardly going to be the most purposeful task for the developers.
7 Days a Week Product Security Incident Response Team (PSIRT)
The Cyber Resilience Act requires product manufactures to communicate about vulnerabilities in a timely manner, set up communications and notification channels and coordinate the disclosure of vulnerabilities. In many organisations, the team that coordinates all this is called the Product Security Incident Response Team or PSIRT. Setting up a PSIRT function requires collaboration between the security team, product development teams, marketing/communication teams and even the legal team. To meet the notification requirements, the PSIRT function must be able to manage incident and vulnerabilities 7 days a week.
Due to its cross-functional nature, things tend to take some time, so it is a good idea to start these preparations as soon as possible.
Aftermarket functions
The overview diagram at the top of this blog post includes three boxes for different aftermarket functions to support the customer: software updates, documentation delivery, and customer services & support. In most cases, such functions already exist, but they may need some improvements to take cybersecurity aspects better into account.
The act requires making software updates available, including notifications of updates and an automatic mechanism, where applicable. There is also an essential requirement to protect the integrity of data, and the integrity of install packages and software updates is usually very important. The standard way to let the users verify that a software update is authentic and has not been modified since its publication is to digitally sign the software update. Don’t be fooled to think that digital signing is a simple invocation of some openssl commands on the command line, because you need to take good care of the signing keys. This requires adequate technical and procedural security controls.
A common way to make product documentation readily available to users is to set up a documentation portal. You also need to arrange the communication channels to and from the external stakeholders.
The act does not require manufacturers to provide commercial services, but it may still be a good idea. There is a requirement to document in product manuals, which kind of technical security support is available from the vendor. Especially if cybersecurity topics are new in the customer community, it is good to prepare for an increased need for support.
What about small and medium size enterprises?
All these practical consequences of the Cyber Resilience Act may seem feasible in a large corporation that has a modern technology stack that is already built on platform thinking. However, what about small or medium size enterprises? Will SME’s have the resources and expertise to set up all these processes, functions, and practices?
We’re hopeful that cybersecurity communities will come up with more scalable methods and supporting resources to help companies of any size with this change. Open-source tools and resources may be especially important for small and medium size enterprises. To breach the competence gap, new and innovative solutions are going to be needed. At Cyberismo, we’re committed to doing our part.
Conclusions
This post concludes our series about the EU Cyber Resilience Act. We introduced the contents of the act, compared it to the industrial cybersecurity standard IEC 62443 and considered the practical implications of the act.
Cyberismo is a cybersecurity solution company dedicated to fortifying the digital landscape. We simplify and optimise cybersecurity management while aiding teams in integrating cybersecurity into their daily operations. We base our approach on open collaboration and the courage to focus on delivering impactful results.
To answer the challenges that we presented in these blog posts, we are developing new ways of managing cybersecurity in digital product and service development. These new ways include open resources that we expect to be helpful for product development teams, regardless of the size of the company. Follow us on LinkedIn to get notifications of our updates, and get in touch to find out how we could help you make a difference in cybersecurity!