Attackers do not study your source code before they touch your device. They find an exposed interface, probe it, and follow whatever gives. Nobody attacking a CT scanner on a hospital network holds perfect knowledge of the binary running inside it. Yet many vulnerability management tools decide whether a known CVE matters by asking a question only that imaginary attacker could answer: is the exact vulnerable function called?
Function-based analysis can be precise in certain environments. But it does not scale to medical devices, where the broader architecture defines the actual risk, not a code snippet in isolation.
An attack on a device is a traversal. It starts at an exposed surface, a network listener or a data input, and moves through components and trust zones toward something worth reaching. The outcome is decided by architecture: what access the attacker needs, what privileges they can gain along the way, and which controls sit in the path.
Path-based analysis models exactly that. It evaluates architectural attack paths and asks whether an attacker can reach a vulnerable library given the access required and the mitigations standing between entry point and flaw. It does not depend on proving that a specific function is directly invoked. That distinction sounds academic. It's the whole game.
It also matches observed attacker behavior. Real intrusions start from reachable surfaces: exposed services, permissive interfaces, weak session handling. Nobody begins by reverse engineering firmware to confirm a call chain. An analysis that starts from the exposed surface is asking the same question the adversary asks: can I get there from here, and what would it cost me?
Function-level verdicts typically come from static call graph inspection or dynamic instrumentation. For third-party software, both are shaky. Function names change between builds. Calls get obfuscated or dispatched indirectly. And the vulnerable code may be reachable only through indirect call chains or runtime conditions a static tool never sees.
Runtime analysis is supposed to close that gap. On a cloud platform with full observability, it often does. Embedded medical devices are a different animal. They were not designed with introspection in mind, and dynamic tracing needs a live environment, representative workloads, and instrumentation that legacy hardware often lacks the memory or performance headroom to support.
Even when you pull it off once, the answer doesn't stay true. Dynamic testing has to be repeated for every configuration, mode, and software version to remain accurate. Across a portfolio with varying firmware maturity, that becomes unsustainable fast. So teams leaning on function-level precision end up with gaps, or worse, confident false conclusions about risk that nobody revisits.
ELTON's methodology is path-based. We model how an attacker could move through the system, which trust boundaries they would cross, and whether mitigating controls stand in the way. That is enough to determine whether a vulnerability is reachable, and whether it is plausibly exploitable, without function-level certainty. And the answer holds up across releases, because architecture changes far less often than code.
Devices get attacked through architecture and threat paths, not perfect binary knowledge. Analysis should work the same way.
The practical output is focus. Path analysis surfaces the small subset of findings that merit deeper investigation and gives you documented grounds to stand down on the rest. Less unnecessary patching, and no deep binary reverse engineering for every single release.
I've watched teams burn weeks trying to prove a function is never called, when an afternoon with the architecture would have shown the component sits behind two authenticated boundaries with no exposed input path. The attacker would have reached the same conclusion in minutes, just by probing. Your analysis should think the way they do.
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.