CRA in Practice: SBOMs, Vulnerabilities, and Real Action Required in 2026

[0:08] Shinobi: Welcome back to Sushi Bytes – the podcast where we slice through software risk, compliance, and security one byte at a time. I’m Shinobi.

[0:18] Gen: And I’m Gen. Season two is officially underway – and today, we’re doing something new.

[0:25] Shinobi: That’s right! For the first time on Sushi Bytes, we’ve got a guest in the studio. And given what’s happening in the software world right now, we couldn’t think of a better way to kick things off.

[0:36] Gen: Yep! In 2026, one acronym is dominating conversations across OSPOs, security teams, and software teams: CRA – the EU Cyber Resilience Act.

[0:50] Shinobi: So, joining us today is Gary Armstrong, Global Head of Customer Success at FossID. Gary just published a whitepaper titled “Software Supply Chain Integrity and SBOM Obligations under the EU Cyber Resilience Act.” Wow – Quite a mouthful, right?

[1:05] Gen: Yeah, but don’t let that scare you. I read it, and it’s a very practical guide for software risk leaders — and very much required reading right now.

[1:14] Shinobi: Gary, welcome to Sushi Bytes.

[1:17] Gary: Thanks Shinobi and Gen. It’s great to be here and congratulation on season two.

[1:22] Gen: Alright Gary, let me kick it off with this question. Since the Cyber Resilience Act is a regulation — not just guidance, what’s the biggest structural shift CRA introduces for software teams?

[1:32] Gary: The biggest shift is that software supply chain transparency and accountability are now enforceable legal obligations, not voluntary best practices.

The CRA doesn’t just ask teams to follow good security principles – it requires manufacturers to be able to demonstrate that they understand what’s in their products, how risks are managed and how vulnerabilities are handled across the product lifecycle.

In practice, that means teams need reliable, repeatable visibility into their software components. The regulation explicitly mentions the use of the SBOM, but it doesn’t prescribe a specific format or tooling.  What it does require is accuracy and traceability, and generating and maintaining SBOMs as part of your technical documentation is the most effective and defensible way to meet those expectations. That’s where the structural change really lands for software teams.

[2:27] Shinobi: So, what deadlines really matter to teams in 2026 and leading into 2027?

[2:32] Gary: The CRA is being applied in stages, and each milestone signals a shift from preparation to enforcement.

11th June 2026 is when Member States must designate conformity assessment bodies. That’s when the compliance ecosystem itself starts to become operational.

Then, from 11th September 2026, vulnerability and incident reporting obligations apply. If a manufacturer becomes aware of an actively exploited vulnerability or a serious incident, they must report it to ENISA, the EU Agency for Cybersecurity, within strict timeframes.

Finally, from 11th December 2027, the remaining CRA obligations apply in full for products placed on the EU market, including technical documentation that demonstrates software supply-chain transparency and vulnerability management.

The important point is that 2026 isn’t a waiting period, it’s when organizations need to have processes up and running.

[3:34] Gen: I’m hearing you say teams should be building capability now — not waiting until enforcement. That window between mid-2026 and end of 2027 seems critical. So, here we are sitting in early 2026 right now. It sounds like big enterprises that move slowly really need to get the wheels in motion yesterday!

[3:54] Gary: That’s right.

[3:56] Gen: SBOMs are the centerpiece of the whitepaper — but what do they actually need to include under the CRA?

[4:04] Gary: At a minimum, the CRA expects manufacturers to be able to identify their top-level third-party components and dependencies and demonstrate that understanding as part of their technical documentation.

The regulation doesn’t prescribe a specific format or a fixed set of fields. In practice, most organizations rely on established SBOM standards like SPDX or CycloneDX because they already capture the kind of component metadata regulators expect – things like component name, version, supplier and, in practice, license information.

The most important requirement isn’t the format itself, it’s accuracy. Whatever mechanism you use has to reflect what was actually shipped for that specific product version.

[4:56] Shinobi: And that means automation! With large, complex codebases, manually or occasionally creating SBOMs just won’t scale or hold up under compliance examination.

[5:03] Gary: Exactly. Automation is essential here. To meet CRA expectations at scale, teams need tooling that can accurately identify components – including those cases where open source code appears as modified or embedded snippets, which in practice often requires in-depth snippet scanning – you then have to keep that component information accurate and up to date over time.

That level of traceability, especially across large and evolving codebases, is extremely difficult to achieve without automated Software Composition Analysis integrated into the development lifecycle.

[5:43] Shinobi: Absolutely! And the CRA doesn’t stop at transparency — it mandates action. Gary, walk us through the vulnerability obligations.

[5:53] Gary: Visibility alone isn’t enough under the CRA. Manufacturers are required to actively monitor for vulnerabilities and act when issues arise.

If a vulnerability is actively exploited or a serious incident occurs, it must be reported to ENISA within defined timeframes, typically between 24 and 72 hours depending on the notification stage.

Beyond reporting, there’s also an obligation to patch and maintain products throughout their defined support period. In many ways, this formalizes what mature security teams already do – but now it’s regulated, documented, and enforceable.

[6:35] Gen: OK Gary, if a team takes just one thing out of this interview and does it this first quarter of 2026 — what should it be?

[6:44] Gary: If teams do one thing this quarter, it should be getting clear on scope and ownership – knowing which products fall under the CRA and who is accountable for compliance and vulnerability reporting.

Once that’s clear, the most important technical step is building continuous visibility into what’s actually in those products. In practice, that means integrating automated SBOM generation into the CI/CD pipeline, so it stays accurate as the software changes.

If the tooling isn’t there yet, engaging an experienced audit team to establish a reliable baseline inventory can give you something concrete to work from, which you can then build on as you integrate SBOM generation into your CI/CD processes.

[7:30] Shinobi: Looking at the time, that’s a perfect place to pause. Thank you so much, Gary! Everyone, this guide is in our show notes — it’s a really clear place to start for tackling the CRA in 2026. Please, I highly encourage you to download it, read it, and use the checklist to get your CRA plan started.

[7:52] Gen: Thanks for joining us, Gary — and thanks to everyone listening. If you do have a product with digital elements in the European market, CRA readiness isn’t optional — it’s inevitable!

[8:03] Shinobi: Right! Gary, Gen this has been a great start to season two! Let’s go grab lunch.

[8:13] Gary: Sounds good, thanks!