Every CVSS argument in a review cycle has the same weak spot: the score is somebody’s opinion. ELTON rates with the MITRE Rubric for Applying CVSS to Medical Devices, qualified under FDA’s MDDT program as Q171974. The methodology walked into review long before your submission did.
Under the MDDT program, FDA evaluates a tool for a stated context of use and agrees its output can be relied on within that scope. Reviewers can accept rubric-based ratings without re-arguing the method itself.
The Medical Device Development Tools program exists so industry does not have to re-argue methods inside every submission. A sponsor proposes a tool, FDA evaluates it against a specific context of use, and qualification means data produced by that tool is accepted within that scope.
The MITRE Rubric for Applying CVSS to Medical Devices went through that process and holds qualification Q171974. It adapts CVSS to clinical reality: how the device is deployed, what an attacker can actually reach, and what a compromise means for the patient on the other end of it.
One thing we will not do is inflate that. Qualification covers the rating methodology, not the ELTON platform as a whole. FDA has not endorsed our product, and no vendor can honestly claim that kind of blanket blessing. What you get is narrower and more useful: every score ELTON produces rests on a method FDA has already reviewed for exactly this job.
Hand the same CVE to ten experienced people and you get ten ratings, each defensible in the room and none defensible on paper. A rubric replaces taste with rules.
The rubric asks concrete decision questions about vector, access, interaction, and clinical impact. The score falls out of the answers, not out of seniority.
Every answer is recorded. When a reviewer asks why the score is a 5.9, the response is the decision trail, not a shrug and a resume.
The same finding rated next quarter, or by a different analyst, lands on the same number. Consistency is what makes a rating program auditable.
Applying a rubric to one CVE is easy. Every finding, every release, reasoning written down, is where humans run out of hours. ELTON runs the full backlog, rationale attached: which questions were asked, what the twin says, what evidence supports each answer.
Context moves the number. A generic 9.8 assumes network reachability and no controls. When the digital twin shows the path is blocked, the score drops, rationale on the record. A defensible re-rating, not a quiet downgrade, and it feeds straight into finding the 1%.
Scoring is not standing still either. CVSSv4 changes the math and the vocabulary, and we are building that path now. See CVSSv4 migration, and how ratings connect to executed evidence in Proof Over Probability.
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.
Pick your ugliest CVE. We will re-rate it through the qualified rubric against your device twin and show you the decision trail a reviewer would read.