Blog:
How Manufacturers Are Tackling the EU CRA: Q&A with Derek Yu at Zühlke

The EU Cyber Resilience Act (CRA) is reshaping how manufacturers approach cybersecurity across the product lifecycle. In this Q&A, Derek Yu from Zühlke, a Toradex Partner, shares his perspective on where manufacturers are focusing their efforts, the challenges they are facing, and what meaningful CRA readiness looks like in practice.

From your conversations with manufacturers, what are the biggest areas of uncertainty around the EU Cyber Resilience Act (CRA) today?

As of right now: whether the Single Reporting Platform (SRP) will be ready and effectively used by manufacturers in a few weeks.

Many colleagues in this space think of scope, classification, or the missing harmonized standards. These are real, for sure. I am mainly thinking about the SRP since reporting actively exploited vulnerabilities and severe incidents is the first thing the CRA requires manufacturers to do (Article 14). SRP is a key element in this, and it sets the tone for everything that follows. Authorities would be sending the right signal by getting the platform ready ASAP. A platform that slips tells everyone the deadline is soft.

You mentioned that many companies are "working backwards" from documentation requirements. Why is that happening, and what risks does it create?

It happens because the documentation is what's visible and auditable, so teams naturally optimize for producing it. The risk is that manufacturers polish their risk assessments so that they justify their pre-CRA security design choices, some of which may be insufficient.

I should explain a bit more though. I brought this up at the Torizon CRA Summit 2025 as a neutral observation (not only a critique) that manufacturers are focusing on three things: Technical Documentation (Annex VII), Information and Instructions to the User (Annex II), and the EU DoC (Article 28).

In other words, it's good that companies are result-oriented and can do this efficiently, and it's also risky because it can encourage justifications that are convenient but don't hold up against the actual threat model. Personally, I believe it is perfectly fine that manufacturers treat the CRA as another checklist (companies are familiar with this) as long as they take the things on the list seriously.

Research suggests the CRA could increase development costs significantly. Where are manufacturers seeing those costs appear most clearly?

I see two areas:

1. Implementing a security development lifecycle (particularly security requirements engineering, implementation, and verification)
2. Fulfilling obligations during the support period.

For the first one, building a proper security development lifecycle means doing security requirements engineering against the risk assessment, designing for and implementing those requirements, and then verifying them through testing. For teams that didn't work this way before, that's new effort on every product.

The second area is the long-tail effort of supporting vulnerability handling and updates throughout the lifetime of a product (Article 13(8)). Manufacturers are generally efficient at dealing with hardware defects and can do occasional software updates if needed. They will have to be much more responsive with software updates in the future, instead of just moving on after selling the product.

What are the differences between companies that are approaching CRA strategically versus those treating it as a checkbox exercise?

My first instinct was that strategic approaches improve quality and security since they are more comprehensive, while checkbox approaches leave security gaps because they can be a formality. But I think that oversimplifies it.

If I may, the two can overlap and it can be a good thing. For example, I've worked with companies that treat it strategically at the management level for planning resources. At the same time, these companies have clear checklists for different tech stacks that exactly match what the CRA is looking for and are actionable and repeatable at the engineering level.

The obvious strategy here is reusing things other product teams have done in the same company. I'll give two examples:

1. Many companies apply platform engineering with automated security gates (SAST, SCA, some DAST) consistently deployed in CI/CD pipelines across different DevOps teams. Often, they also centralize SCA scanning in a dedicated PSIRT or equivalent team.
2. Teams developing different products in the same product family share the same threat model and attack surface analysis to avoid duplicate work.

How is the CRA changing expectations around long-term maintenance, software updates, and vulnerability management for connected devices?

I can confirm a real shift for both manufacturers and their customers: they now expect the same level of security guarantees and assurances to hold throughout a product's lifetime, not just at launch (Article 13(8)). I'll elaborate a little more.

For product manufacturers, cybersecurity is now a clearly regulated aspect of product quality. I see this with industrial companies revisiting their products with a security risk assessment (Article 13(2)). Many start by citing physical protection during intended use to justify an acceptable risk level, which is sensible. From there they transition to patching or modernizing efficiently, in software or hardware, so products don't have to rely on physical protection as much. Manufacturers have to stay decisive and efficient to avoid high development costs.

For institutional customers, I see more due diligence to ensure their products operate securely in their infrastructure. They have also become much more responsive to cybersecurity, often driven by key regulations such as NIS2. For regular consumers, I think we will collectively not change our behavior as much. If there's anything explicit to be said, consumers rely on two things: secure-by-default settings (Annex I, Part I(2)(b)) and keeping up with security updates (Annex I, Part I(2)(c)).

What role do platforms like Torizon play in helping embedded product teams manage CRA-related requirements more efficiently?

If you're referring to the Torizon Platform, I'd say it covers a lot of the basics so product teams don't have to reengineer them: SBOM generation, secure boot, secure updates, and vulnerability monitoring (Annex I, Part II). I think the vulnerability monitoring is the most helpful, because it helps teams focus on just the exploitable vulnerabilities rather than every CVE. I know a lot of manufacturers use established commercial or open-source solutions, but first-party information gives good confidence.

You spoke about companies using AI and sometimes ending up with "compliance theater." What does meaningful CRA readiness look like in practice?

Indeed, at last year's conference I talked about "compliance theater," referring to situations where AI generates polished, convincing security concepts that then fail the actual security tests. I actually started on a positive note, which I still believe today: AI is an option we don't have to shy away from.

I think meaningful CRA readiness should have traceability as the main criterion, and if we're using AI, that's something we should explicitly prompt for, even with today's frontier models. More explicitly, it means being able to trace the elements in the technical documentation (Annex VII) back to explicit processes, design decisions, implementation, test cases, and test results. For example, a ready manufacturer can tie its risk assessment to real architecture decision records, feed its SBOM into a live vulnerability workflow, and point to disaster recovery plans that are actually rehearsed.

Many organizations are still waiting for harmonized standards. Why are some manufacturers already moving ahead with frameworks like IEC 62443?

Because most products fall in the default class, where harmonized standards aren't mandatory at all. Conformity can be self-assessed (Module A, Article 32), and harmonized standards aren't an obligation. To show due diligence, these manufacturers pick IEC 62443 (or sometimes EN 303 645) as a guideline to follow. It's also worth knowing that even if a product follows IEC 62443, it doesn't have to meet every single requirement (e.g., every Component Requirement in IEC 62443-4-2). Since the CRA is risk-based, manufacturers of default products can forgo certain requirements where the associated risks are acceptable. I personally often use ENISA's requirements-to-standards mapping (November 2024) to pin down the requirements that are strictly in the scope of the CRA.

How are CRA requirements changing relationships between manufacturers, software suppliers, and silicon vendors?

Cybersecurity becomes a procurement criterion. The relationship gets stress-tested as everyone is compelled to build security into a wider range of products and push obligations upstream, and the suppliers who make that easiest for their customers will win the business.

Silicon vendors already include many platform-specific security features the CRA requires; the change may simply be that more manufacturers now ask for advanced features such as secure key provisioning. For manufacturers and software suppliers, the relationship increasingly turns on SBOMs, with pressure on suppliers to be transparent and responsive. It also extends to service providers, where scrutiny is higher. For example, I increasingly see client projects where we are far more deliberate about security design choices and long-term vulnerability handling.

How can companies like Zühlke help manufacturers with CRA?

Different engineering consultancies like ours tend to have niche strengths, and on CRA we can usually fill various gaps a client may have. Just a few concrete examples:

• Gap assessment to help clients get their priorities right. This is the part I enjoy most, since I get into so many domains, meet so many clients, and see different technical solutions. I think it's also the most valuable for clients: they often have the engineering power, and they just want a quick check through us to see what their industry peers do.
• External audit support so clients pass with adequate solutions and a concise narrative. I've personally talked to external auditors in DACH to help explain security decisions, prepare audit evidence, and guide witness testing.
• Security engineering to design and verify adequate security measures. This can include defining development processes, deriving specs from standards or CRA requirements, and implementing and validating security features.
• CRA training, a smaller part of what we do. Most clients are better served starting with a gap assessment and building capability from there.

If you were advising an embedded manufacturer starting its CRA journey today, what would be the first three priorities?

Classifying the product portfolio, establishing supply-chain vulnerability handling, and building a security development lifecycle.

Without classification, we either don't even know the unknowns or overreact and waste effort. Without vulnerability handling, we will not be ready for the reporting obligations effective from 11 September this year. Without a security development lifecycle, product teams cannot be consistent in ensuring adequate product security.