A real attack on a medical device is almost never one vulnerability. It is a sequence: a mediocre bug on an exposed interface, a privilege boundary that gives way, a trusted update path that was never supposed to be reachable from there. Each link might rate a 4-something on its own. The chain ends in control of a safety-critical function.
FDA knows this. The June 2025 final premarket guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, makes chained analysis an explicit expectation rather than a nice-to-have. If your threat model scores vulnerabilities one at a time and stops, it is answering a question FDA is no longer asking.
The guidance defines vulnerability chaining directly:
The sequential exploit of multiple vulnerabilities where one or more exploits at the end of the chain require the successful completion of prior exploits in order to be exploited.
Around that definition sit concrete expectations. Map the attack surface and threat model in the context of related systems, not just the device itself: firmware, software components, network and cloud connections, update servers, third-party modules, the hospital environment the device operates in. Document unresolved anomalies and trace them through potential exploit paths to a mitigation or a residual risk you can stand behind.
Leave chaining out and you should expect Additional Information requests, or a slower review while FDA asks the questions your submission should have answered.
Score a vulnerability alone and you learn its theoretical severity. Score it inside the device and you learn something different. A 9.8 in a component with no path to it and no privileges behind it can be practically inert. A 4.3 local bug sitting on the firmware update routine can be the first link in a chain that ends the product's integrity.
Anyone who has done offensive work on devices has seen the pattern. A low-privilege flaw in a USB driver becomes the pivot into a privileged update routine. Remote code execution in a third-party library becomes lateral movement across a trust boundary and into the hospital network. A compromised vendor module becomes the foothold that makes every downstream weakness suddenly relevant. The path decides the risk. The individual nodes never did.
Chaining analysis by hand is miserable at any real scale, which is why it mostly does not happen. We automated it on top of the digital twin.
ELTON models the product as a graph: components, interfaces, trust boundaries, update paths, cloud and third-party dependencies, built from SBOMs, firmware inventories, network topology, and the architecture documentation already in your QMS. Every ingested vulnerability, whether it arrives from a CVE feed, a penetration test, or an SBOM alert, gets pinned to its location in that graph along with the privileges it requires and the boundaries it spans.
Then the engine walks the paths. From each entry point, a network interface, a USB port, a cloud API, it computes feasible exploit sequences, pivoting across trust zones until it reaches, or provably fails to reach, a safety-relevant function. Each chain is scored for likelihood and impact, so remediation priority reflects what an attacker can actually assemble rather than what a scanner can enumerate. Supply chain risk rides along in the same computation: a vendor component with known flaws behind a trusted interface starts chains too, and ELTON models them.
And the analysis does not sit still. New CVEs land weekly, and a chain that did not exist last month can exist today because a single new link appeared. ELTON re-evaluates paths as the picture changes, which is what keeps the postmarket story continuous instead of episodic.
The output is traceability from architecture to vulnerability to exploit chain to residual risk, in a form that maps onto premarket expectations for threat modeling, unresolved anomalies, and SBOM documentation. Teams that fold this into their secure product development framework early never face the job of reconstructing attack paths from memory in the middle of a review.
My view is simple. The CVE was never the right unit of analysis for a connected medical device; the path was, all along. FDA has now written that into guidance, and manufacturers still ranking risk by standalone scores are not just carrying more risk than they think. They are walking into a review that has already moved past them.
Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.