Your Essential CRA Compliance Guide

If you build, ship, or sell digital products within the European Union, there is a massive regulatory shift heading your way: the Cyber Resilience Act (CRA). If your organization has historically treated product security as a “nice-to-have” or an afterthought to be patched later, the CRA is about to completely rewrite your playbook.

To help product security teams, developers, and compliance officers translate complex legal jargon into concrete application security practices, a vital new video series has launched. It breaks down exactly what the CRA requires and how to tackle it without slowing down your development pipeline.

Here is a comprehensive summary of the first two foundational episodes in this must-watch series.

The Experts in this Video Series

Dr. Aram Hovsepyan, CRA Technical Expert

An application security expert with over 25 years of experience as a researcher and industry professional. He is the founder and CEO of Codific, a cybersecurity firm focused on application security and secure software development.

He holds a PhD in application security from DistriNet KU Leuven. His key professional contributions include:

• Serving as a core contributor to the OWASP SAMM project.
• Acting as a founding board member of OWASP EU.
• Refining the LINDDUN privacy engineering methodology, which has been incorporated into both ISO and NIST standards.

Lara Brito, CRA Legal Expert

Lara Brito da Costa is a legal consultant and CRA expert specializing in digital governance and compliance. She works with Codific to provide guidance on Cyber Resilience Act (CRA) requirements, automation, and legal advisory for secure software development. Her work includes researching the intersection of cybersecurity maturity models, such as OWASP SAMM, and EU regulatory frameworks. She focuses on helping organizations translate complex legal requirements into actionable application security practices.

Episode 1: What is the CRA and Why Do We Care?

The debut episode of the series establishes the foundations of the EU Cyber Resilience Act (CRA). The hosts dive straight into the core purpose of the regulation, who it impacts, and why ignoring it could spell disaster for your business.

Key Takeaways from Episode 1:

• Secure by Design Mandate: The CRA shifts the burden of security onto manufacturers, enforcing strict “secure by design” and “secure by default” principles before products can even hit the EU market.
• Broad Scope: The law applies to almost all products with digital elements (both hardware and software) connected directly or indirectly to a network, though certain product categories face vastly different levels of scrutiny.
• The High Stakes of Non-Compliance: This isn’t a toothless regulation. Failing to comply means facing massive financial penalties, potential product recalls, and losing market access to the entire EU.

To help visualize how the regulation differentiates products, the episode highlights three main CRA product categories:

Pro Tip: Figuring out where your software falls can be tricky. The creators of this series built a free CRA Screening Tool that walks you through scoping questions to determine your specific obligations.

Watch episode 1 on Youtube:

Episode 2: CRA Sessions – Risk Assessment

Once you know your product category, where do you actually begin? Episode 2 addresses the absolute starting point of any mature Application Security (AppSec) program and CRA compliance strategy: Risk Assessment and Threat Modeling.

Aram and Lara deconstruct the myth that risk management is purely a technical headache. Instead, they argue that robust compliance relies on bridging the gap between business risk and engineering reality.

Key Takeaways from Episode 2:

• The Two-Part Risk Equation: True risk isn’t just about code vulnerabilities; it requires balancing two distinct components:
  1. The Business Component (Loss Magnitude): What is the business impact if things go sideways? This must be dictated by business leadership, not the dev team.
  2. The Technical Component (Threat Event Frequency): How likely is a specific attack vector to succeed?
• Sequence Matters: You cannot effectively threat-model the infinite universe of technical bugs without first establishing the business context. The CRA explicitly requires teams to start by defining the product’s context, baseline operational risks, and risk acceptance criteria.
• Practical Threat Modeling: The episode dives into turning abstract regulatory requirements into an actionable threat-modeling framework. Done right, this framework satisfies auditors while actually making your software more resilient.

“If there is no risk, you don’t really need security. Unfortunately, we don’t live in that world. Creating a crystal-clear understanding of the risk profile for each of your products is no longer optional—it’s the law.”

Watch episode 2 on Youtube:

Episode 3: CRA Sessions – Technical Security Requirements

In this episode, the focus shifts to the concrete technical security requirements of the Cyber Resilience Act. Moving away from reactive models where fines typically only followed a data breach, the CRA mandates a proactive, continuous approach to security. The hosts explain how true compliance should simply be a byproduct of implementing genuine, robust security by design throughout a product’s entire lifecycle.

Key Takeaways from Episode 3:

• Security Requirements Must Be SMART: Simply stating a product needs to “be secure” is insufficient. Requirements must be Specific, Measurable, Actionable, Relevant, and Time-bound to effectively ensure confidentiality, integrity, and availability.
• Architecture Cannot Be an Afterthought: You cannot code your way out of a bad design. Solid architecture built on established security principles—like defense in depth, zero trust, and least privilege—is fundamental.
• Tools Enable, But Processes Protect: While security tools are essential (e.g., for generating an SBOM or checking configurations), they are only part of the solution. Truly managing third-party dependencies requires a formal approval and management process, and configuration hardening ensures products are shipped “secure by default”.
• Automated Requirements Testing: Validating that security requirements are correctly implemented is critical. Best practice dictates automating these tests at the code level to prevent security regressions every time the software changes.

“My philosophy is that compliance should be a bonus coming from real security.”

Watch episode 3 on Youtube:

Episode 4: CRA Sessions: Vulnerability Management

In this episode, the focus shifts to vulnerability management and the operational side of the Cyber Resilience Act. The discussion explores how organizations can continuously detect, assess, prioritize, and respond to vulnerabilities throughout a product’s lifecycle – turning vulnerability management from a security best practice into a legal requirement.

Key Takeaways from Episode 4:

• Vulnerability Management Is Mandatory: The CRA makes vulnerability management a legal obligation, requiring manufacturers to actively manage security issues throughout the product lifecycle.
• Incident Response Must Be Planned: Effective incident management means having clear detection, escalation, classification, and notification processes in place before an incident occurs.
• Manage Findings Based on Risk: Security issues from scanners, testing, and other sources should be centrally tracked and prioritized based on risk, severity, and the sensitivity of affected data.
• Patching Needs to Be Continuous: Regular patching and updates are essential, but critical vulnerabilities may require action immediately rather than waiting for the next scheduled update.
• Security Must Reach Production: Secure deployment means protecting the integrity and authenticity of software from source code through the build process and all the way to the deployed product.

“You need a systematic approach that starts with risk.”

Watch episode 4 on Youtube:

Why This Video Series Belongs on Your Radar

As the enforcement timelines for the Cyber Resilience Act (CRA) draw closer, software vendors and hardware manufacturers cannot afford a wait-and-see approach. What makes this specific video series highly valuable is its emphasis on practical application. Rather than just admiring the problem or reading legal clauses line-by-line, the hosts focus on what vulnerability handling, Software Bills of Materials (SBOMs), and conformity assessments actually look like when you are actively trying to ship real products.

Bookmark these videos, run your product through the screening tool, and stay tuned as upcoming episodes dive deeper into the technical mechanics of secure product engineering.