A critical CVE lands tonight. Can your team make the call by tomorrow?

When a serious vulnerability appears in a connected product, finding the component is only the beginning. Your team still needs to determine which released products are actually affected, decide what can safely change, reduce exposure if a patch will take time, and document a decision that can stand up to scrutiny.

Join leaders from Lynx, RunSafe Security, Rockwell Automation, and Zimmer Biomet for a practical cross-industry conversation about vulnerability response in long-life embedded devices.

Live panel: September 9, 2026 · 10:00 a.m. ET

Abstract embedded Linux lifecycle assurance graphic

The response clock starts before you have certainty.

Imagine this happens tomorrow:

A critical vulnerability is identified in a component used somewhere in your connected product line. The product has been in the field for years. A validated patch will take time.

Now the questions start:

Which released products contain the component?
Which configurations are actually affected?
Can you safely backport, validate, and deploy a fix?
What reduces exposure while remediation is pending?
Who owns the risk decision—and can the organization explain it later?

These are not only security questions. They are product, engineering, safety, quality, regulatory, and lifecycle-management questions.

The EU Cyber Resilience Act’s reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 11, 2026—two days after this panel. But the operational challenge is larger than reporting: teams need the evidence and decision-making capability to respond to a real product-security event under pressure.

Which part of the response breaks first?

Evidence

We can find the component, but not the affected product.

An SBOM may tell you a component is present. It does not automatically answer how it was configured, whether relevant functionality is enabled, which released variants are in scope, or what evidence supports a decision.

Explore the 24-hour evidence problem

Patch gap

The patch exists, but we cannot safely ship it.

An upstream fix may still require a backport, hardware validation, regression testing, safety analysis, certification work, and an update window you do not control.

Explore the patch gap

Lifecycle

The product will outlive its software platform.

Long-life devices depend on the ability to understand, rebuild, change, test, and support software years after the product ships.

Explore the long-life device problem

Four perspectives on the same difficult decision.

Medical and industrial teams operate under different constraints. A medical device cannot casually be taken offline; neither can a system that keeps a plant running. Both must reconcile cybersecurity with safety, availability, product support, and long field lifecycles.

This panel compares what carries across those environments, where the approaches diverge, and which capabilities manufacturers should establish now.

What the panel will cover

moving from a component finding to a defensible product-level decision
building evidence beyond a static software inventory
responding when immediate patching is unsafe or impractical
evaluating mitigation options during the patch gap
aligning security, engineering, safety/quality, regulatory, and leadership teams
preserving vulnerability-response options across a product lifecycle measured in decades

Who should attend?

This conversation is for people responsible for the security, supportability, and operational resilience of connected products, including directors and leaders of cybersecurity or product security; PSIRT and cybersecurity engineers; embedded software, firmware, and platform engineers; system architects; product security and program leaders; and quality, regulatory, and lifecycle stakeholders who participate in vulnerability decisions.

Webinar questions

No. The panel uses current compliance pressure as context, but the core discussion is about the embedded-device capabilities needed to identify product impact, manage remediation constraints, and make defensible vulnerability decisions across long lifecycles.

Yes. The patch gap—and the options available when immediate remediation is impractical—is a central part of the discussion.

A better response starts before the next vulnerability.

Hear how medical and industrial teams are approaching affected-product determination, delayed-patch decisions, interim controls, and emerging reporting requirements in deployed devices.