ELTON derives threats from the digital twin, test cases from the threats, and findings from the tests, so a reviewer can walk any verdict back to the design.
Each link is generated from the one before it, so nothing in the report exists without a parent.
Each component's EMB3D properties map to threats, and each threat becomes an instance on every component it applies to.
| Threat · Instance | Test cases | Component | Type | PID | Status | Result | Finding |
|---|---|---|---|---|---|---|---|
| ▾ Applications Binaries Modified TID-301 EMB3D (8 instances · 8 test cases) | Blocked | Failed | |||||
| TH-Qm7Lr-Xe2Bd | 1 test case | Dock gateway | Generic application | PID-31 | Complete | Failed | EL-2231 |
| TH-b3KpV-Tn8Zs | 1 test case | Pump application | Local application | PID-31 | Complete | Passed | · |
| TH-R9wYd-Lc4Hm | 1 test case | Clinician app | Local application | PID-31 | Complete | Passed | · |
| TH-uE5Jq-Vf1Gx | 1 test case | Service tool | Local application | PID-31 | Complete | Passed | · |
| TH-N2sAz-Pk6Wr | 1 test case | EHR gateway | Generic application | PID-31 | Blocked | Incomplete | · |
| TH-g8TcB-Mh3Dy | 1 test case | Vireo cloud API | Generic application | PID-31 | Complete | Passed | · |
| 2 more instances | |||||||
| ▸ Device Allows Unauthenticated Firmware Installation TID-211 EMB3D (3 instances · 6 test cases) | Complete | Passed | |||||
| ▸ Remotely Accessible Unauthenticated Services TID-310 EMB3D (11 instances · 14 test cases) | Complete | Passed | |||||
Open an instance and the mapping is on the page: the component, the property, the threat, and each test case with who ran it and what it returned.
| Test case | Test case instance | Last run by | Status | Result | Finding |
|---|---|---|---|---|---|
| Application binary and runtime-library integrity verification | TC-Jk4Tn-9wVbP | DAST | Complete | Failed | EL-2231 |
The finding is then analyzed for exploitability: which conditions it needs, and what access or attack surface produces them.
What has to be true before the flaw can be used. Each condition is named, and each one traces to the finding or setting that produces it.
Vulnerability Chaining →Which entry vectors reach it: a network port, a radio, a service connector, hands on the case. The twin already holds them.
Digital Twin Traceability →Directly exploitable, conditionally exploitable, unexploitable weakness or mitigated weakness, proven on the device where the answer depends on it.
FDA Vulnerability Verification →A finding is not closed by opinion. Every test case comes from the device’s own threat model, runs at the deepest tier you open, and lands as evidence: an unbroken chain from CVE to determination that reviewers can follow. Deeper access closes more findings as Not Affected, and every VEX statement gets stronger.
Three of the eleven activities in every subscription exist to answer it.
| ELTON activity | What FDA asks for | Where | How ELTON evidences it |
|---|---|---|---|
| Threat-model-driven test case creation | A threat model that informs the risk assessment and the test plan, so what gets tested follows from how the device can be attacked. | Premarket guidance, Section V.A.1 Threat Modeling and Section V.A.3 threat mitigation testing. | Test cases are generated from the twin's components and their EMB3D properties, so coverage reads as a list before testing starts. |
| Test case traceability to design | Traceability from security requirements and design controls to the tests that verified them, kept in the design history file. | Premarket guidance, Section V.A.3 and Appendix 2; QMSR, 21 CFR Part 820 incorporating ISO 13485 clauses 7.3.3 and 7.3.6, design inputs and design verification. | Every test case maps to the twin component and the control it exercises, and the matrix exports with the report. |
| Vulnerability traceability to test cases | Findings tied to the tests that produced them, including a security assessment of unresolved anomalies. | Premarket guidance, Section V.A.3 test reports and Section V.A.1, assessment of unresolved anomalies. | Every finding links to its test case, its evidence and its component, so a reviewer can walk from the vulnerability back to the test. |
A verified ELTON finding is not a row in a spreadsheet. It is a package a reviewer can replay: the test case that ran, the execution log it produced, the observed result, and the VEX status that follows. Dismissals carry the same package, because not affected is a claim that needs proof too.
Each verdict also answers the questions SSVC actually asks. Is the attack automatable? Does it end in total compromise of the device? Which vectors reach the flaw? Is there a working proof of concept? Grounded in an executed test, those four answers turn a score into a decision you can defend.
Proof is the foundation the rest of the platform stands on. It is how ELTON can find the 1% that matter, why an FDA-qualified rating methodology holds up in review, and what separates the pipeline from a prompt. The mechanics live on the verification page.
The same chain carries the verification, the twin and the compliance map.
How a finding is proven or dismissed on the running device, with the executed test as evidence.
The model of the device that threats and test cases are derived from.
Every activity in the subscription, mapped to the FDA requirement it evidences.
Bring one device. We build the twin, derive the threats and test cases, and hand you a finding you can trace to the component it started on.
FDA's premarket cybersecurity guidance asks for a threat model that informs the test plan, test reports in the submission, and an assessment of unresolved anomalies. Traceability is the ability to walk between them: from a design element to its threats, from a threat to the tests that exercised it, and from a finding back to the test that produced it.
The digital twin holds the device's components, interfaces, data flows and assets. Each component type carries MITRE EMB3D properties, each property maps to threats, and each threat becomes an instance on every component it applies to. Test cases are generated per instance, so coverage reads as a list before testing starts.
A failed test case is promoted to a finding, and the result stays attached as its evidence. The finding is then analyzed for exploitability: the conditions it needs, and the access or attack surface that would produce them. The verdict is directly exploitable, conditionally exploitable, unexploitable weakness or mitigated weakness.
Yes. Every finding links to its test case, the threat instance the test case came from, the EMB3D threat and property behind it, and the twin component it sits on. The matrix exports with the report.