As the deadlines for the EU Cyber Resilience Act (CRA) are fast approaching, reaching CRA compliance is turning cybersecurity an essential theme for many. Already strictly regulated industries, such as medical or automotive, have shown how regulation can foster creating secure solutions. Now with the CRA, a similar level of security is about to be required from a broader number of product manufacturers.
But here’s the positive news: CRA compliance can be a game-changer for product manufacturers. First, managing the security of products better will protect from potentially massive losses caused by security breaches. Second, being among the first ones to set up standout processes and practices for vulnerability management and reporting, 3rd party management, and overall product security by design is likely to get recognized, creating a competitive advantage.
A short interview summarizing the key aspects on preparing for the CRA.
You can also watch the video in YouTube.
In this blog, I wanted to share some insights on to how Qt Group has started the journey towards CRA compliance, and how manufacturers can ensure their products meet regulatory expectations on time.
Where Do You Stand on Your CRA Compliance?
Looking at the CRA compliance of Qt customers, there’s still a lot of variances on where manufacturers currently stand. Some are at the very early stages, trying to identify which products are affected. Others already have a cybersecurity unit going through the regulatory items in detail, for example, evaluating the CRA compliance of the product development and maintenance processes.
What makes it complicated is that even the regulatory authorities are not fully prepared, as there are still some unclarities around the Cyber Resilience Act. At the same time, the approaching CRA deadlines are creating pressure to comply with the CRA in time. At Qt Group, for instance, seeing that there’s no certification unit in place yet, we decided to ask external auditors to assess where we currently stand with our CRA compliance, even if also the auditors are currently acting on their best assumptions.
That is to say, building CRA compliance starts from assessing where you are now. Only from there, can you start to see which regulatory items to address first.
Considerations for Your Product Development
The earlier you start working towards CRA compliance, the better you are prepared when the deadlines kick in. Even with the remaining unclarities, there are already many items from the CRA requirements you can work on. Let’s take a closer look at some of them.
Vulnerability Management as a Differentiator in the Market
Vulnerability management is a CRA compliance item with great potential to be turned into a competitive advantage.
The CRA doesn’t provide strict guidelines for how to handle security updates. It rather sets a common standard for publicly disclosing found security incidences, leaving manufacturers with the liberty to set up their best processes and practices for it. Showing how fast you’re able to manage situations with security breaches can thus be your differentiator; doing it well builds trust among your users and has a major positive impact on your brand image.
Manufacturers will want to clarify their processes on vulnerability reporting, automate reporting and user communication as much as possible using mailing lists or other early warning notification channels, and build up ability to provide security patches to customers, for example, via a customer portal. All of these we’re also already doing at Qt Group.
One essential aspect to the vulnerability management is also the ability to identify what components and which versions of them are included in the product. This will help both manufacturers and the end users to identify, in case of a security incident, whether that actually applies to the product at hand, and which versions of the product will be needing a given security update.
The SBOM and Sandboxing for Improved 3rd Party Management
The Software Bill of Materials (SBOM) is a machine-processable document that describes the details and supply chain relationships of the components used in a product. When using Qt in creating a device, for example, the SBOM allows to identify which security-relevant parts the device contains, both from the product itself as well as from the used 3rd parties.
As the SBOM is also a direct technical product requirement for CRA, automated SBOM generation will help with the CRA compliance a lot. The SBOM is also one of the easier CRA requirements to meet, as it’s clearly defined in the regulation, unlike some other more vague items.
There’s more to 3rd party management, however. As software architectures are getting more and more complex, and the platform approach is becoming more and more common, especially industrial setups end up consisting of multiple applications from different vendors. That leads to questions such as, how to shield the product in case of a security breach in one of the included applications? That’s where sandboxing comes in with tools such as Qt Application Manager, enabling to isolate applications and prevent them from interacting with the rest of the system setup. It provides manufacturers full control of the application lifecycle in the product stack.
Security by Design as a Foundation for Your CRA Compliance
Vulnerability management is often focused on how to handle situations after an incident is found. But protecting products from security incidents beforehand is, in fact, even more important. Therefore, the CRA demands manufacturers to also look into lifecycle management of their products, requiring support and security updates to be provided for the entire product lifecycle, or by default, for a minimum of 5 years.
There’s more to consider about the 5 years, though.
Let’s take an example of an industrial machine. Creating the product can take 5 years of development time alone. It would be impossible to decide in the beginning of that to use, say, Qt version 6.8, release the product 5 years later, and continue with providing 20 years of support. Therefore, as also the OPC foundation claims, product developers must get educated on planning out an upgrade path and an update philosophy to always use the latest and most secure technology, already in the prototyping phase, long before releasing the product to the market. That’s one of the biggest learnings for reaching CRA compliance, because if you're not prepared for upgrades from the start, you will need to learn the hard way once your device is out.
So how to create stable, secure and mature solutions from the get-go? Before deploying an update, you must make sure there are no regressions in functionality, security, or experience.
For these aspects, quality assurance tools come to help, from multiple angles. One angle is static analysis with tools such as Coco or Axivion, to parse your source code and check for potential security issues even before you have your code in production. Another angle, from a higher-level perspective as software architectures are so complex nowadays, is to verify that the implementation of your system matches with its software architecture. That is to ensure that your R&D, for instance, didn’t accidentally create interfaces which open up potential security holes, further helping the overall creation of secure products and enabling CRA compliance, as well.
Qt Group’s Notion on CRA Compliance
Qt Group naturally has a two-way approach to CRA compliance. First, we ensure that our own products are compliant. Second, we look into helping our customers to more efficiently meet the CRA requirements without slowing down their go-to-market activities.
Here are the CRA compliance steps taken at Qt Group so far:
- Holistic Risk Assessment: Conducted a thorough review of the entire Qt Framework, tagged each component with clear risk-severity indicators, and built up a roadmap out of the CRA compliance items to work on.
- Enhanced Vulnerability Management: Assessed and updated internal processes to ensure their CRA compliance, established the Early Warning List for commercial customers, provided help for customers to identify whether a given incident applies to them and how to get security patches updated into their products.
- CVE Numbering Authority (CNA) Status: Received the official CNA authority for all Qt Group’s products, and updated vulnerability reporting processes and practices to include CVE issuance and meet the CRA requirements on the reporting times.
- CRA-Aligned Support Lifecycle: Extended the Long-Term Support (LTS) releases to 5 years to match the CRA’s support requirements, and provided additional services such as Extended Security Maintenance for those who need longer support periods.
- SBOM generation in Qt Framework: Released the functionality for auto-generating the SBOM with Qt 6.8.0 and later, as a part of the build process.
- Provided essential CRA info: Published a dedicated CRA web space to gather in one place essential information about the CRA requirements, where Qt Group stands with the CRA compliance, and what aspects to consider as manufacturers.
Some of the CRA compliance items we are still working on at Qt Group, and you can find more information about where we stand with those, also in the dedicated CRA web space. We regularly also exchange with our customers on their needs and expectations around the CRA, to together tackle the complexities of CRA compliance in the most profitable way for all.
Find Your Security-First Mindset
Qt as a technology has existed for 30 years now. Thanks to that, we have had robust security practices and processes established since a long time already, and now we're simply adapting them for CRA compliance. From there, Qt Group actually embraces the CRA, because it formalizes what we’ve already been doing to help our customers improve their product security. Now, we encourage all manufacturers to simply start establishing their CRA compliance.
How to identify vulnerabilities? How to provide patches? How to build a secure product from the get-go? And what are the most important aspects of your CRA compliance; are you able to break down your compliance items into “low-complexity” and “high-effort” tasks, and tackle simpler items first? Finding the answers that best suit each manufacturer will not only help reach regulatory compliance but also foster trust and differentiation in a competitive market.
Hopefully, the thoughts shared here have provided a helpful starting point for CRA readiness. If still you have questions in mind, contact us to book a CRA workshop to go through where you currently stand and what steps you need to get compliant.
See also
