4 key challenges with the CRA – and how to tackle them

The Cyber Resilience Act isn't a regulation you can hand off to your compliance team and forget about. It sets specific requirements for how your products are built, who in your organisation owns responsibility, and what you can document when things go wrong.

The CRA must be embedded in your products from the outset – it cannot be treated as an afterthought.

The regulation comes fully into force in December 2027, but some CRA requirements are already in effect – including vulnerability reporting obligations.

You can read more in our article "Everything you need to know about the CRA".

The regulation also requires security to be built into every stage of product development, and for many organisations, that's a fundamental shift that takes time.

It may sound abstract, but the consequences are very real: products that don't comply with the regulation cannot legally be sold in the EU. And the CRA doesn't only apply to large companies. It affects most businesses that develop, import, or distribute products containing software components.

We spoke with Raja Hamza Ali, Nordic GRC Advisor at NorthGRC, about the four challenges he sees organisations run into time and again when they start taking the CRA seriously.

Here they are – and what you can do about them.

1. Scope: What's actually in play for you?

The first question is also the most fundamental: which of your products are actually covered by the CRA?

The regulation applies to products with digital elements – meaning products containing software or firmware that connect to networks or other devices. That covers everything from industrial control systems and IoT devices to B2B software and applications.

But scope doesn't stop at the product list. It's just as much about understanding your organisation's regulatory role.

The CRA defines three central roles. The manufacturer is the company that develops and produces products and places them on the market under its own name or trademark. The importer brings products from non-EU producers onto the EU market. The distributor markets products without having produced or imported them.

A single company can hold multiple roles across different products – and that's precisely what makes scope mapping so important.

"Before you can even begin talking about CRA compliance, you need to identify which products are in scope and map your organisation's regulatory roles – because that determines which CRA obligations apply," says Raja Hamza Ali.

Your role determines your obligations. A manufacturer faces the heaviest requirements – including full documentation, vulnerability management, and CE marking. An importer is obliged to verify that the products they bring to the EU market already meet the requirements. A distributor has limited but still genuine responsibility for ensuring products are compliant before they go on sale.

What’s your next step? Conduct a structured mapping of your product portfolio. For each product: does it contain digital elements? What role does your company play? The answers to those two questions are the foundation for everything that follows.

2. Security by design: The later you start, the more it costs

Under the CRA, cybersecurity is an integrated part of the entire product lifecycle. The regulation requires security to be built in from the very first line – in requirements, in design, in code, in testing, at launch, and throughout maintenance.

That's what security by design means.

For many organisations, this is a paradigm shift. And it has one very direct consequence: you won't be able to sell your product in the EU unless security has been woven in from start to finish.

“If you pick up the CRA requirements late in your product development cycle, you'll actually have to go back to the drawing board and integrate them from the beginning. That means real costs for your organisation – in time, money, and resources – and it can affect how customers perceive and trust your company," says Raja Hamza Ali.

In business terms, the stakes are clear: any company hoping to launch products on the EU market after December 2027 without having done the groundwork first will have a serious problem on its hands.

In practice, security by design means feeding security requirements into the requirements phase, running threat modelling during design, holding developers to secure coding standards, making security testing a core part of QA, and managing vulnerabilities and updates through every release.

What’s your next step? Review your current product development process and identify where CRA requirements are missing. Integrate security gates into your existing workflow. The earlier you start, the lower the cost.

3. Roles and responsibilities: Who owns what?

One of the most underestimated aspects of CRA preparation is internal accountability. Many organisations instinctively put compliance responsibility with a single function – the compliance team, IT security, or perhaps whoever was most engaged with GDPR.

That's not enough.

CRA obligations span the entire organisation. Engineering must build securely. Security must define requirements and run testing. Legal must handle contractual and regulatory obligations. Governance must ensure oversight and traceability. None of these functions can stand alone.

"The point isn't that the organisation needs every possible job title covered – but it must be clear who is responsible for what, and where the necessary expertise lives. Responsibility cannot sit with compliance alone. It has to be distributed across the organisation," says Raja Hamza Ali.

The goal is to make accountability explicit and actionable. Who approves security requirements? Who owns vulnerability management? Who escalates to leadership when a product can't meet the bar?

What’s your next step? Build a clear RACI (Responsible, Accountable, Consulted, Informed) for CRA obligations across engineering, security, legal, and governance. Also map where your internal expertise falls short – and whether you need to bring it in from outside.

4. Documentation: Prove that your product is secure

The fourth element is what holds everything else together: documentation. The CRA doesn't just require your product to be secure. It requires you to prove it.

This isn't a bureaucratic formality. It's the foundation of the trust that EU legislation is trying to build – and your customers rightly expect.

"The technical documentation a product must carry includes cybersecurity assessments, documented security requirements, vulnerability management records and logs, security testing results, software dependency disclosures, and the technical documentation that accompanies the product to market. It needs to be documented – and documented in a way that, if a vulnerability does emerge, you can pinpoint exactly where it is and who is responsible. That's what puts you in a position to actually do something about it," says Raja Hamza Ali.

That framing is worth holding onto. Good CRA documentation is ultimately what lets your organisation respond quickly and precisely when something goes wrong. And something will go wrong at some point – the question isn't if, but when.

What’s your next step? Build your documentation structure as an ongoing part of your product process – not as a task to complete in the days before an audit. Keep it live and updated with every release and every product change.

CRA is a product question, not a compliance question

The four challenges are closely connected. Scope determines what roles your organisation holds. Your roles determine what needs to be designed and built. What you design and build determines what must be documented. And documentation is the only thing that proves you got it right.

That's why the CRA can't be solved by one department alone. It requires a cross-organisational effort – and it requires you to build it in from the start, not add it in the weeks before the deadline.

Are you mapping your CRA position? NorthGRC helps organisations navigate the regulation from scope mapping through to clear documentation. Get in touch for a no-obligation conversation about where you stand and what your next step looks like.