ELTON builds a working twin of each device from documentation your quality system already produces, plus source code or runtime scanning where available. Every vulnerability lands on that model, which answers what is reachable, what defends it, and what a new finding means on this device. First thing we build, last thing we stop updating. Not a binary inventory rebuilt from firmware: the twin models the security architecture, interfaces, controls, and paths, the level where exploitability is decided.
Standing up the twin does not begin with a questionnaire. It begins with artifacts your quality system has already produced, reviewed, and submitted. Most manufacturers are surprised by how much of the model already sits in their files.
System diagrams, data flow maps, and deployment context define what the device is, what talks to it, and where it sits on a hospital network.
The software bill of materials binds every component and version into the model, so a new CVE resolves to a real location instead of a keyword match.
DICOM, HL7, and MQTT listeners, trust boundaries, and documented countermeasures become claims the platform can test, not lines in a PDF.
The twin is level 1 of exploitability verification. It typically resolves 30-40% of findings as Not Affected, each with reasoning a reviewer can follow, before vulnerability chaining analysis clears roughly another 50%, and on-hardware automated verification testing kills the remaining 10%.
The twin is not rebuilt for each engagement. It accumulates, assessment after assessment, release after release. That is why triage with ELTON never starts from zero.
The twin starts from existing documentation and a first assessment. That is already enough to answer reachability and retire the findings with no path. Every question it cannot yet answer becomes a test the platform schedules.
Verified paths, confirmed behavior, and dependency graph structure feed back in. A CVE that drops today lands in a model that already knows the component, the interface, and everything between them.
Send the documentation your quality system already holds. We stand up the twin, run L1 verification, and show you what it answers on day one.
A working model of one device release: its components, interfaces, data flows, assets, trust boundaries and documented countermeasures, held as a single graph. ELTON builds it from documentation your quality system already produces. Every vulnerability lands on that model, which is what makes reachability a computed answer rather than an opinion.
In four stages. Data ingest takes design and security documentation, and optionally a code or firmware scan, runtime internals and physical observation. That data is structured into components, interfaces, data flows and assets, with trust levels and attack surface layered over it. Vulnerability context is added from the SBOM and scanner feeds, then attack path analysis resolves reachability.
Typically 30 to 40 percent, each closed as Not Affected with reasoning a reviewer can follow. The twin is level 1 of exploitability verification. Vulnerability chaining analysis then clears roughly another 50 percent, and on-hardware automated verification testing resolves the remaining 10 percent.
No. It accumulates, assessment after assessment and release after release. Verified paths, confirmed behavior and dependency graph structure feed back into it, so a CVE that drops today lands in a model that already knows the component, the interface and everything between them. Triage never starts from zero.
It resolves the CVE to a real location instead of a keyword match. The SBOM says which component and version this device actually ships, and the graph says whether anything can reach it and what defends it. The answer is specific to this device and this release.