FDA has recognized CVSS v4.0 as a consensus standard, and the new metrics ask questions v3.1 never did. Re-rating a portfolio by hand does not scale. ELTON automates the migration with the context v4 demands. The goal is simple: every score current, every score defensible.
ELTON’s rating practice was built on the MITRE CVSS Rubric for Medical Devices, the FDA-qualified MDDT (Q171974). v4.0 scoring gets the same discipline, automated.
ELTON MDCVJ (Medical Device Contextual Vulnerability Justification) is under review in FDA’s MDDT program, the only CVSS v4.0 scoring solution in that pipeline. Every rating is computed from the digital twin, per product and release, and traces to your submission documentation. No hand-adjusted scores. Opinions break down under audit. ELTON’s ratings are facts.
Every CVSS 4.0 decision is computed from the device’s documented architecture. Same inputs, same score, every run. This is the full path a rating takes, and every stop on it is traceable.
ELTON starts from documentation you already produce for FDA review: architecture views and data flow diagrams, SBOM, threat model, risk management report, security controls, and cybersecurity testing reports. No new paperwork, no questionnaires.
The documentation becomes a machine-readable graph. Components become nodes carrying trust level, assets with CIA sensitivity, countermeasures, and deployment configurability. Data flows become directed edges typed Network, Adjacent, Local, or Physical. Every element is tagged to the document it came from, and every manual edit is logged.
Each finding attaches to the exact component it lives on, whether it arrives from a pentest report, an SBOM scan, the public CVE feed, or a user entry. The vulnerability carries SSVC context and an on-component exposure indicator before any path analysis begins. The unit of analysis is always one vulnerability on one component in one device design.
For each initial access point in the threat model (Wi-Fi, Bluetooth, USB, the user interface, a debug port), ELTON derives the feasible paths an attacker can take to reach the component and the propagation paths after compromise. Traversal respects trust boundaries and directionality, so infeasible paths never inflate a score. Each entry point is scored as its own scenario.
Each metric is computed by rules that extend the FDA-qualified rubric (Q171974) to v4.0. Exploitability metrics read the entry interface, trust levels traversed, countermeasures, configurability, and user interaction. Impact metrics read asset sensitivity on the vulnerable component and everything downstream. If no feasible path exists, the scenario is marked non-exploitable. No questionnaires, no judgment calls.
Every entry point gets a complete vector, score, and metric-level justification naming the components, interfaces, trust levels, and assets that drove it, cited back to your submission documents. The canonical score is the highest-severity feasible scenario; the others are retained as context. Change the architecture and the score changes with it. Nothing else moves it.
The biggest changes reward manufacturers who actually know their device’s context. That knowledge is exactly what most rating workflows lack.
The new AT metric asks whether exploitation depends on deployment conditions an attacker cannot simply create. Answering it honestly requires a model of the deployed device.
Scope is gone. v4 scores impact on the vulnerable system and on the systems beyond it separately, which is exactly where chained findings live.
Temporal becomes Threat. Exploit maturity now moves scores meaningfully and changes over time, so ratings need revisiting, not archiving. ELTON refreshes them as the threat picture moves.
A v3.1 vector cannot be mechanically converted. The new metrics need information a score alone does not carry. The twin and the dependency graph supply it.
Network segmentation, required pairing, physical access assumptions: the digital twin already holds the deployment conditions AT asks about.
The dependency graph knows which findings produce the conditions others require, so subsequent system scores reflect real chains, not guesses.
Every finding carries both scores during the transition. Submissions already in flight stay consistent while new work adopts v4. Nothing gets re-rated by hand on a deadline.
See your current findings scored in v3.1 and v4.0 side by side, with Attack Requirements answered by the twin.
