The European Union’s Cyber Resilience Act (CRA) began requiring manufacturers of connected products to report actively exploited vulnerabilities on a tight schedule in September 2026.
Medical device makers have lived with similar post-market expectations from the U.S. Food and Drug Administration (FDA) for years, and industrial and operational technology (OT) vendors are now being pulled into the same regime. Across all three, the underlying demand is consistent: know what is in your software, identify which products a given vulnerability affects, judge the real risk, reduce that risk when a patch is not available, and document all of it across product lifecycles that can run for decades.
While the requirements read as procedural, in practice they expose a gap most teams underestimate: the distance between generating a Software Bill of Materials (SBOM) and being able to say, quickly and defensibly, whether a specific product is actually affected by a specific vulnerability.
On a recent RunSafe Security webinar, “Embedded Devices and Compliance Pressure,” a panel of security leaders from across regulated industries worked through that gap in detail. The panel included Maciej Halasz, Director of EMEA Open Source Solutions at Lynx; Joel Max, Senior Manager of the Product Security Incident Response Team at Rockwell Automation; John Howie, Chief Information Security Officer (CISO) of Zimmer Biomet; and Shane Fry, CTO of RunSafe Security.
Their industries answer to different regulators and operate under different constraints, but they converged on the same conclusion about where teams get caught out.
A Good SBOM Often Surfaces Hundreds of Vulnerabilities
Many manufacturers believe their software supply chain is well understood, right up until they generate a complete, accurate SBOM. Fry explained how he’s seen this play out.
“We talk to a lot of companies that think they don’t have any vulnerabilities,” Fry said. “Then, they get a good SBOM and find, whoa, I’ve now got 100-200 for one single product.”
The opposite failure is also just as common. Halasz described what he calls a CVE storm, where a scan returns hundreds or thousands of Common Vulnerabilities and Exposures (CVEs) at once and much of the list is noise. “You look closely at the list and you realize that over 50% of those vulnerabilities are false positives,” he said, and legitimate CVEs are sometimes missing entirely.
Part of the problem is that the inventory teams have is not the inventory they shipped. Halasz pointed to “situations where build-time inventory does not equal the shipped product inventory,” because components get statically linked, patched, or vendored on the way into a firmware binary. Package manifests and dependency lists describe the plan, not the product.
Version identity adds another layer of difficulty. Vulnerability matching relies on identifiers tied to a component’s upstream name, so a fork or a rename severs that link. “The moment you start fiddling with the package names, that’s when you start missing vulnerabilities that apply to a product,” Halasz said.
Presence Is Not the Same as Exploitability
Even a clean, accurate SBOM only answers half the question. “An SBOM establishes the presence of a specific component, but not necessarily its exploitability,” Halasz said. Closing the rest of the gap is triage work, usually owned by a Product Security Incident Response Team.
That work runs through a sequence of narrowing questions. The team has to confirm whether the vulnerable implementation is actually present or the fix was already backported, and whether the affected code was even compiled into the build. A Linux kernel ships thousands of drivers, Halasz noted, but only a handful reach any given product.
The last question is the hardest to answer and the easiest to skip: “Even if a vulnerability ends up in your executable, can that code execute?” Findings from that process get recorded in a shared format such as VEX, the Vulnerability Exploitability eXchange, which can be attached directly to an SBOM.
Howie pushed the standard one step further. In medical devices, exploitability alone does not settle the question, because the team still has to establish harm. He offered a hypothetical: a device uses an outdated OpenSSL library to encrypt read-only telemetry, such as heartbeat data, between an implant and an external monitor. The library is vulnerable and the traffic can be eavesdropped, but the data is not identifiable and nothing can be pushed back into the device.
“Just because something’s exploitable, there might not be harm coming out of it. You’ve got to go a little bit further,” Howie said. He also warned that inbound components are frequently modified in-house, which undermines any assessment built on the original library alone. “You can’t wholly rely on an SBOM of inbound libraries that go into a product to say, yes, you’ve got a vulnerability,” he said, because your developers may have added, removed, or changed code after it arrived.
The Reporting Clock Rewards Preparation, Not Improvisation
For a long time, teams could find an issue on a scanner, fix it, and move on without telling anyone. The CRA and FDA reporting obligations end that habit and replace it with a clock. Fry expects reported vulnerability counts to climb as a result, driven by the reality that teams “are now required to report instead of silently fixing and just hoping that nobody downstream notices or cares.”
The volume is what makes the deadline hard. Max explained that a single critical CVE can affect 20 products, each requiring its own validated fix or mitigation, and that the burden then falls on customers who are triaging every vendor at once. “They’re having to look at thousands, perhaps on a regular basis, and figure out which ones do I patch,” he said. Those pressures stack up as bottlenecks at intake, validation, and disclosure, and Max expects AI-accelerated discovery to make them worse.
Whether a manufacturer can identify affected products, make an initial risk call, coordinate internally, and communicate externally within a 24-hour window comes down to one thing. “The answer is yes, if you have a playbook, a pre-existing playbook in place,” Max said. That means a standing vulnerability management policy, a defined intake-to-disclosure flow, a channel to reach customers, and legal and executive stakeholders already primed. Teams improvising the process after the clock starts are unlikely to make the window.
Start with an Accurate SBOM, Then Automate
Asked what one capability a manufacturer should stand up in the next 90 days, the panel returned to the same answer. “Automate as much as possible,” Halasz said, pointing specifically at SBOM generation, vulnerability scanning, initial assessment, and reporting. Manual triage does not scale to the volume the reporting clock now demands, and automation is what shortens the path from a new CVE to a defensible answer.
Fry made the case that the path begins with the SBOM itself, because it converts unknowns into a list that a team can act on. He backed the point with a number from a large OT vendor that had reviewed years of its own triage history. “One of the major OT device manufacturers said that 75% of their vulnerabilities are coming through the supply chain,” he said. A team that cannot see its supply chain accurately cannot answer the affected-or-not question at all, let alone inside a reporting window.
None of this is only a compliance exercise, and Howie’s background in the medical field provides a good reminder of why. “When you put something into a human body or attach it to them, or someone becomes dependent on it for their quality of life, you can’t just turn around after two years and go, yeah, it’s no longer a problem,” he said. A vulnerability report on a decades-old product is, ultimately, a question of whether that person is still safe, and the manufacturer owes them an answer.
The reporting clock has made the speed of that answer the deciding factor. An accurate SBOM turns unknowns into a list, automation turns the list into triage, and triage turns into an affected-or-not decision measured in hours instead of weeks. Manufacturers who build that pipeline now will meet the next critical CVE with a routine call rather than a scramble, and they will spend the coming decade able to answer the question regulators and patients are really asking: are we affected, and are you sure?
Watch the full panel discussion, “Embedded Devices and Compliance Pressure,” on demand.
