Reachability analysis is genuinely useful when it is certain. Prove that a vulnerable function is never called, or that a flagged dependency never loads, and the finding stops costing you attention. The environments these tools grew up in can deliver that certainty: cloud-native applications with full runtime observability and a CI/CD loop that re-validates assumptions on every deploy. Firmware is not that environment.
I want to be precise about why, because the failure isn't "the tool is bad." The failure is that the tool's confidence outlives the conditions that justified it.
Static reachability walks a call graph from entry points down to the vulnerable symbol. On embedded targets that graph is full of holes. Dynamic dispatch sits everywhere in device code: function pointers, ops tables, vtables, callback registration, interrupt handlers. An analyzer can't resolve those edges before the code runs, so it either over-approximates and marks everything reachable, or it drops the edge and quietly under-approximates.
IPC ends the graph entirely. When a request crosses a message queue, a socket, or shared memory between an RTOS task and a Linux service, the analyzer sees a write into a queue. It never sees the consumer on the other side. And a meaningful share of any device image is closed vendor code: baseband stacks, Bluetooth SDKs, bootloader blobs. No source, no visibility.
Even where source exists, release engineering fights you. Link-time optimization and aggressive inlining rewrite the graph the analyzer thought it knew. Stripped production builds mean the binary in the field only loosely resembles what you analyzed. And configuration decides what actually runs: the same image ships with features compiled in but disabled, or disabled by default yet reachable through a service menu.
Over-approximation is merely annoying, since you get no noise reduction. Under-approximation is dangerous, because it produces a confident "not reachable" that actually means "not visible."
Here's why this matters more for medical devices than for SaaS. When you dismiss a CVE in a premarket file or a postmarket record, you own the justification. "Our tooling marked the function unreachable" won't survive a reviewer's follow-up when the tool never resolved the dispatch table and never saw past the message queue. A reachability verdict without runtime proof is a claim, not evidence.
Time erodes it further. Device software releases slowly while vulnerability discovery against an existing device runs fast, so a verdict computed at release keeps getting cited months later. A small firmware or configuration change can invalidate the assumption underneath it, and nobody re-runs the analysis to notice.
We took a different route with ELTON. Rather than betting on function-level granularity, we model the whole product in a digital twin: architecture, dataflows, access controls, trust boundaries, threat surfaces. New vulnerabilities are overlaid onto that living model, and reachability gets judged from system context: which interfaces expose the path, what privileges the attacker needs, what they must already control, which architectural mitigations stand in the way, and which other vulnerabilities could change the answer.
That filters the bulk of findings with evidence that holds. Not "the function isn't called," but "the component sits behind an authenticated service on an isolated bus, and here's the record." Where the answer still hinges on runtime behavior, we verify on the physical device. Exploitability is a runtime question, and runtime questions get runtime answers.
Function-level analysis still has a place in that flow. It's a fine microscope. The mistake is doing triage with a microscope. Let the system model pick the handful of findings that deserve function-level attention, then spend the deep engineering hours there instead of spreading them across a thousand findings.
I'll take an honest "reachable until proven otherwise" over a confident guess. In this industry the justification is the deliverable. A "not reachable" you can't defend in front of a reviewer isn't a triage win. It's a finding about your process.
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.