A 9.8 on NVD is not a 9.8 on your device. NVD scores describe a worst-case, generic deployment. Your device has a specific architecture, specific interfaces, and specific controls, and the score that matters to a regulator is the one computed against those facts. The FDA has agreed with that position since 2017, when it qualified the MITRE CVSS Rubric for Medical Devices as a Medical Device Development Tool, MDDT Q171974.
Qualification matters more than most people realize. It means the FDA reviewed the rubric's methodology and accepted it for use in regulatory submissions. Score a vulnerability through the rubric and you're standing on an FDA-recognized process, not defending a subjective judgment call.
Enterprise CVSS interpretations fail on devices because devices aren't IT. The rubric rebuilds each base metric for clinical context, with decision trees and worked examples for every one.
Attack Vector distinguishes a wired hospital LAN from a Bluetooth implant. Attack Complexity accounts for calibration procedures and patient interaction. Privileges Required maps to real roles: clinician, technician, manufacturer. And the impact metrics get read clinically. A corrupted dosage calculation is an Integrity loss. Interrupted therapy delivery is an Availability loss. The rubric forces the score to reflect patient consequence, not just system damage.
Working the rubric by hand is fine for a dozen findings. It collapses at device scale, where a single SBOM can carry hundreds of components and every release resets the analysis. This is the gap ELTON was built to close.
Every device in ELTON is represented as a digital twin: a machine-readable model of its components, interfaces, dataflows, and controls, built from the documentation you already maintain in your QMS. When a CVE or a test finding arrives, it traverses the rubric's decision trees automatically, answered with facts from the twin. Firmware reachable only through a local USB port gets Attack Vector Physical, because the twin knows that's the only way in.
Each score carries its rationale: the CVSS vector, the decision path through the rubric, the impacted components, the mitigations in place, and the test evidence behind them. Open any rating and you can read exactly how it was derived. A reviewer can too, which is the point.
Here's the scenario that makes the whole approach concrete. A component in your SBOM picks up a critical CVE, 9.8 on NVD, network vector. But the twin shows the vulnerable service is compiled out, or bound to an internal interface no external port can reach, or gated behind authenticated access the exploit path can't satisfy. The rubric's own logic then produces a lower device-specific score, and the record shows precisely which questions and which architectural facts produced it.
That isn't score shopping. It's the FDA-qualified process doing what it was qualified to do. And it cuts in both directions: a medium sitting in the component that drives therapy delivery can rise once clinical impact is weighed honestly.
The rubric ended the methodology argument in 2017. What's left is an execution problem: applying it to every finding, every release, without an army of analysts.
Manually scored spreadsheets go stale the day after they're saved. ELTON re-runs the rubric logic whenever the inputs change: a new CVE lands on a shared library, a patch alters an interface, a control gets added or removed. That's what regulators mean by continuous cybersecurity risk management. Not a promise to rescore eventually, but ratings that move when the facts move.
We've carried this approach through more than 600 regulatory submissions. My take after all of them: subjective severity debates are the single largest waste of time in device security programs. The FDA handed the industry a qualified instrument years ago. The manufacturers who win reviews are the ones who actually operationalize it.
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.
One issue a month on AI, exploitability, and FDA cybersecurity review. No spam, unsubscribe anytime.
It is a scoring rubric the FDA qualified in 2017 as a Medical Device Development Tool, MDDT Q171974. Qualification means the FDA reviewed the methodology and accepted it for use in regulatory submissions, so a score produced through it rests on an FDA-recognized process rather than a subjective judgment call.
A 9.8 on NVD is not a 9.8 on your device. NVD scores describe a worst-case, generic deployment. Your device has a specific architecture, specific interfaces and specific controls, and the score that matters to a regulator is the one computed against those facts.
It rebuilds each metric for clinical context, with decision trees and worked examples. Attack Vector distinguishes a wired hospital LAN from a Bluetooth implant. Attack Complexity accounts for calibration procedures and patient interaction. Privileges Required maps to clinician, technician and manufacturer roles, and impact is read clinically.
Yes, when the rubric's own logic produces it. If the vulnerable service is compiled out, bound to an internal interface no external port can reach, or gated behind authentication the exploit path cannot satisfy, the device-specific score drops and the record shows which facts produced it. It cuts both ways: clinical impact can raise a medium.
Working the decision trees manually is fine for a dozen findings and collapses at device scale, where a single SBOM can carry hundreds of components and every release resets the analysis. Manually scored spreadsheets also go stale the day after they are saved, and ratings are supposed to move when the facts move.