Mastering Risk Assessment under the Cyber Resilience Act

Margaret Ellis

Welcome back to Come Reflect Act, the podcast by Tributech where we dive deep into the world of the Cyber Resilience Act. I’m Margaret Ellis, and with me as always is David Evans. Today, we’re focusing on the CRA risk assessments and how they are the very backbone of compliance for any product with digital elements.

David Evans

Yeah, Margaret, and this is where a lot of manufacturers get their first real wake-up call. I mean, risk assessments have always been a good practice, but now, with Article 13 of the CRA, it’s a legal requirement. Every single product—with digital elements with just a few exceptions—needs a formal, documented cybersecurity risk assessment. And without that? No CE marking, no market access. It's as non-optional as it gets.

Margaret Ellis

Exactly. It’s more than just paperwork. The CRA defines risk assessment as a process to identify, analyse, and evaluate risks tied to both a product’s intended use and foreseeable misuse. So, it’s not just about how a device should be used but how it could be misused—those “creative” scenarios you’d rather not think about! It really pushes manufacturers to think beyond just intended operation.

David Evans

Right—and I think the word “foreseeable” is key there. Because, let’s be honest, users and environments…they’re unpredictable. Manufacturers have to analyse operational context, product lifespan, vulnerabilities—the whole lot. And those aren’t just nice-to-haves. They’re the minimum criteria straight from Article 13. So: what’s the product meant to do, what might go wrong, what’s the environment, and how long could this thing be out in the wild?

Margaret Ellis

And let’s not forget: the outcomes from this risk assessment aren’t siloed. They feed directly into which essential requirements from Annex 1 apply to your product and, importantly, how you address them. Every security control or mitigation step you take should be justified by the risks you identified. If it’s not in the assessment, it shouldn’t be in your technical solution. You can’t just copy-paste security features.

David Evans

Exactly, and—maybe this is getting into the weeds—but everything ties back. So, manufacturers have to show that their products are, as the CRA puts it, “designed, developed and produced in such a way that it ensures an appropriate level of cybersecurity based on the risks.” No vague claims, no boilerplate security promises. Only measures that map directly to the risks you found and documented. I might be rambling here, but you get my point.

Margaret Ellis

No, that’s spot on, David. It’s fundamentally strategic—documenting how you’re thinking about risks at every stage, from the first line of code through to maintenance and updates. Without this, compliance simply isn’t possible under the CRA.

David Evans

So, let’s talk about documentation—because I feel like this is where things get real for manufacturers. The technical documentation isn’t just a folder of reports somewhere. It has to show traceability, right? From the risks in your assessment all the way to the security controls you put in. If an auditor comes in, they need to see a clear line connecting the dots—“Here’s the risk we found, here’s the control we chose, and here’s why.”

Margaret Ellis

Absolutely. And where relevant, you’ve got to reference established standards or frameworks. The CRA doesn’t operate in a vacuum; leveraging standards like ETSI EN 303 645 for consumer IoT, EN IEC 62443 for industrial controls, or ISO/IEC 27001 and 27002 for information security management has been encouraged by many experts. Referencing these in your technical documentation not only supports your choices, but also gives a bit of structure—almost a kind of blueprint for your risk management activities.

David Evans

Right—it’s like standards bring some order to the chaos. And ENISA has provided mappings to show how these frameworks align with the Annex 1 requirements. So, if you use them, it isn’t just some checkbox routine—it becomes a justifiable and repeatable process. I mean, I remember when we talked about this a couple episodes back—how using recognized standards isn’t just about best practice, but about defensibility if anyone challenges your compliance.

Margaret Ellis

Yes, and that’s where it gets interesting. The technical documentation must capture every step: from why you picked certain controls or even why you decided something wasn’t applicable, to how your risk assessment articulated the need for that control. It’s also not static—if a requirement from Annex 1 doesn’t fit your specific product, you actually have to explain the reasoning in the documents. It’s a living, breathing set of records.

David Evans

And one thing I always tell teams—you don’t get extra points for overengineering things. The point is to match your mitigation to actual risks. Use the standards for structure, yes, but make the whole process proportionate. Otherwise, you’ll just drown in unnecessary controls or documentation that no one will read after the audit.

Margaret Ellis

So true. The bottom line is: make your process traceable, reference globally recognized standards where possible, and be prepared to justify every choice you make. That’s what makes your risk assessment meaningful, not just a compliance artefact.

Margaret Ellis

Of course, documenting once isn’t enough, is it? The CRA makes it clear this is an ongoing responsibility. Any “substantial modification”—and that can mean a lot of things, really—demands a fresh risk assessment. We’re talking software updates, new features, maybe the product ends up in a new operational context that wasn’t anticipated at launch. It’s not static by any means.

David Evans

Yeah, and honestly, “substantial modification” is kind of a moving target. CRA defines it as anything that could affect compliance with essential cybersecurity requirements or the product’s security posture. So, if you issue a software update that changes functionality? That’s a trigger. If you add a feature or start using the device in a new environment? Time to reassess. And manufacturers have to track all these changes internally—they basically need a monitoring process in place.

Margaret Ellis

Spot on. Internal monitoring isn’t just a buzzword here—manufacturers are expected to keep tabs on vulnerabilities, not just the ones they discover themselves but also those reported from outside sources. You also need to update the risk assessment if new threats pop up. This sort of continuous vigilance is what CRA is demanding. And it ties back to lifecycle thinking—security isn’t a one-and-done, it evolves as the product does.

David Evans

Exactly. And we’ve actually touched on this before in earlier episodes—keeping your documentation alive so it reflects the current state, not just how things looked at launch. To stay compliant, manufacturers need to make sure those internal triggers are clearly defined so nothing slips through the cracks. If the threat landscape shifts, or someone finds a new vulnerability, that’s your cue to update and reassess. I guess, to wrap it up, the CRA is nudging—or, I should say, shoving—the market into a much more mature security posture.

Margaret Ellis

It absolutely is, David. Cybersecurity under the CRA is proactive, strategic, and persistent—and risk assessment sits at the very heart of it. That’s all for today’s episode—we hope it’s cleared up some of the mystery around CRA risk assessments. Thanks for joining us. David, always a pleasure talking security with you.

David Evans

Same here, Margaret. We’ll be back soon to dig even deeper into CRA compliance, and if you don't want to wait, head to Tributech's CRA Knowledge Hub to read more! Until then, take care!