[Webinar Recap] Engineering for the Cyber Resilience Act: Navigating Compliance Across the Product Lifecycle
|
Watch the entire presentation here: Engineering for the Cyber Resilience Act: Navigating Compliance Across the Product Lifecycle.
Engineering for the Cyber Resilience Act: Navigating Compliance Across the Product Lifecycle
Preparing for the Cyber Resilience Act: What Engineering Teams Need to Know Now
The EU Cyber Resilience Act (CRA) is setting new expectations for digital product development. It introduces mandatory requirements for vulnerability management, secure-by-design engineering, traceability, and post-market monitoring. For manufacturers of connected or software-enabled products, this represents a critical shift in how you build, document, and maintain your technology.
In this webinar, Patrick Garman, Manager of Solutions & Consulting at Jama Software, breaks down the complexities of the CRA, reviews enforcement timelines, and demonstrates how to integrate cybersecurity directly into your product lifecycle.
What You’ll Learn:
- Deconstruct CRA Requirements: Gain a clear understanding of obligations for manufacturers, importers, and distributors, including secure development practices and vulnerability handling.
- Operationalize Secure-by-Design: Learn practical strategies to embed security into your engineering workflows from day one.
- Master Software Bill of Materials (SBOM) Transparency & Traceability: Discover how to maintain the rigorous documentation and traceability of the new regulation demands.
- Navigate the Enforcement Timeline: Get a clear view of upcoming deadlines to help you prepare your organization strategically.
- Leverage Jama Connect® for Compliance: Explore how a modern requirements management tool helps track threats, link mitigations to requirements, integrate testing, and prove compliance.
Don’t wait until the deadline approaches to address these critical changes. Watch now to ensure your team has the knowledge and tools to navigate the CRA successfully.
The video above is a preview of this webinar – Click HERE to watch it in its entirety!
TRANSCRIPT PREVIEW
Patrick Garman: Hi, everyone, and thank you for joining today. My name’s Patrick Garman, and I am the Solutions Manager for Energy, Industrial, and Consumer Electronics sectors here at Jama Software. Today, I’m going to be talking about the EU’s Cyber Resilience Act, or the CRA. I’ll explain what the CRA actually is, what it means for product developers, and how you can show evidence of secure by design without creating unnecessary overhead. I’m also going to briefly show how Jama Connect supports your CRA compliance. At a high level, the Cyber Resilience Act is an EU regulation that applies to products with digital elements, so hardware with software, firmware, or connectivity, and standalone software products as well. It’s not a technical standard, and it does not tell you how to implement security; it focuses on outcomes. Did you consider cybersecurity risks? Did you define mitigations? Can you show how those were implemented and maintained? It’s also worth saying what it’s not. It’s not saying that products must be perfectly secure, and it’s not trying to turn product teams into security researchers. It’s really about making cybersecurity part of normal product engineering, just integrating it into your process.
And the motivation behind the CRA is pretty straightforward: products today rely heavily on software, but cybersecurity practices across manufacturers vary a lot. Some teams are very disciplined, and others rely more on informal knowledge and experience. From a regulatory point of view, that makes it hard to assess product risk and hard to respond when vulnerabilities show up later, so the CRA is really about creating a consistent baseline, so cybersecurity is treated more like safety, reliability, or quality, something you design for, document, and revisit throughout the product lifecycle. And the penalties can be pretty stiff for non-compliance. You hear, for non-compliance, up to 15 million euros or 2.5% of your global annual turnover. Products can be barred from the EU market for non-compliance. It does include mandatory incident reporting, and it also establishes liability for manufacturers for unsafe or insecure products, so it is something that is very important to prepare for and be ready for. If you strip away the legal language, the CRA requirements really fall into a few practical buckets. First, you’re expected to identify cybersecurity risks that are relevant to your product and how it’s used.
RELATED: Buyer’s Guide: How to Select the Right Requirements Management and Traceability Solution
Garman: Second, those risks should lead to actual security requirements, design constraints, controls, or behaviors that mitigate the risks. Third, there needs to be evidence, not just that you thought about security, but that the requirements were implemented and verified. And finally, the CRA expects manufacturers to manage vulnerabilities after release, things like intake, assessment, updates, and communication. And the challenge is doing it consistently and in a way that you can explain later, especially if this information is spread across different repositories. Before I jump into a demo in Jama Connect, I want to set up how to think about CRA compliance in Jama Connect. The CRA is ultimately asking for something pretty specific, can you prove a clean line from the cybersecurity risk to mitigation to verification, and then keep that story intact as the product changes? And Jama Connect’s a great tool for this because it’s designed for exactly this kind of lifecycle traceability with definable traceability information models that provide guardrails for your process. And the model I’m showing here, threats must link to one or more security requirements, and security requirements must link to verification evidence like test cases or analysis.
And if we want to go deeper, we can link into design and implementation artifacts as well. And the reason that this matters is that once these rules are in place, you’re not relying on memory or tribal knowledge. Jama Connect can guide teams towards consistent linking, and it becomes much easier to answer the questions that come up in audits and reviews, such as which risks are unmitigated, which mitigations aren’t verified, and what changed since the last release? And the other big benefit is the change impact. Sorry. When a new vulnerability pops up or a design decision shifts, Jama makes it practical to see what requirements, tests, and releases are affected without manually stitching it together across documents and spreadsheets. With that framing, what I’ll show next is a simple example. We’ll take a threat and author a requirement against it, and then see the verification evidence, so you’ll see how the relationship rule set keeps the traceability clean and reviewable. For this dem,o I’m going to keep the model intentionally simple. We’re going to start with a cybersecurity threat analysis, trace that to a security requirement, and then to a validation.
RELATED: SPAN Electrifies Its Product Development and Safety with Jama Connect
Garman: And in this scenario, I’m going to use the CVSS, which stands for the Common Vulnerability Scoring System, the 3.1 model, to score severity consistently. CVSS is traditionally used for vulnerabilities, but teams often use that same scoring structure for threat scenarios because it is familiar and repeatable. And I have a pre-created threat analysis item so that we can focus on the traceability aspects. But here you can see I have a place where I can provide a name, a description of the threat or vulnerability, and also select all of the appropriate vectors within the CVSS scoring model. And I’m also using Jama Connect Interchange™‘s Excel functions to calculate the base score and assign a severity rating, along with the temporal score and environmental score. Again, these are all calculated automatically on the backend as you define your threat vectors. And the reason I like capturing all of these attributes here in Jama Connect is it makes the assumptions explicit. Stakeholders can review the score, disagree with it, and adjust it, but we’re not hand-waving severity. And because it’s all on the same system as our requirements and validations, the cybersecurity story stays connected.
THIS IS A PREVIEW OF OUR WEBINAR, WATCH IT IN ITS ENTIRETY:
[Webinar Recap] Engineering for the Cyber Resilience Act: Navigating Compliance Across the Product Lifecycle
Manager, Solutions & Consulting at Jama Software
I take great joy in exploring how technology can be applied to business problems in new and unexpected ways to create fluid experiences for customers.
I hold a B.A. from Sewanee: The University of the South and an MBA from Goizueta Business School at Emory University. My professional experience includes project management, new product development, customer insights, and marketing strategy and spans the health, hospitality, transportation and logistics, public, and retail sectors.
I am based in Birmingham, Alabama, with my partner Ian and enjoy live music, cooking, coffee roasting, and spending time with our dogs Toby and Jude and our cat Isabella Rossellini.
I can be reached at garmapq@gmail.com.
I hold a B.A. from Sewanee: The University of the South and an MBA from Goizueta Business School at Emory University. My professional experience includes project management, new product development, customer insights, and marketing strategy and spans the health, hospitality, transportation and logistics, public, and retail sectors.
I am based in Birmingham, Alabama, with my partner Ian and enjoy live music, cooking, coffee roasting, and spending time with our dogs Toby and Jude and our cat Isabella Rossellini.
I can be reached at garmapq@gmail.com.
Latest posts by Patrick Garman (see all)
- [Webinar Recap] Engineering for the Cyber Resilience Act: Navigating Compliance Across the Product Lifecycle - January 14, 2026
- Cybersecurity by Design: Preparing for the Cyber Resilience Act - January 6, 2026
- 2026 Predictions for Consumer Electronics Product Development: AI, Sustainability, and the Rise of Connected Ecosystems - December 4, 2025