The SBOM CVE feed never stops. SAST dumps arrive loaded with false positives. Vulnerability scans, penetration test reports, and third-party research reports each show up with their own scoring assumptions. The engineer modifies the CVSSv3 vector by hand, attempts a CVSSv4 calculation nobody has standardized, and reconciles the result against what a consultant wrote six months ago.

The output is immense variability across sources. The same finding rates 7.8 from the scanner, 5.1 from the pentest report, and 9.1 from the researcher. Bob and Joe triage with different criteria and both are defensible to no one. And all of it, every rating change, every rationale, every disposition, lives in Excel.

Under the SPDF model, testing is supposed to find and fix vulnerabilities during development. By the time your final reports reach an FDA or MDR submission, they should show little to nothing open, and a lot of history: prior discovery, remediation, and re-verification across builds.

And when no vulnerabilities remain, the report still has to prove you looked. That means an enumerated list of every cybersecurity test case launched against the product's scope, so a reviewer can see coverage of the attack surface even where the finding count is zero. A single late pentest produces the exact opposite: one snapshot, open findings, no fix history, no coverage story.

Traditional V&V asks "is the requirement present?" Threat mitigation testing asks a harder question: is the control implemented correctly, and does it hold up against the threat it was designed to stop? Those are different disciplines with different evidence.

The only practical way to do this at device scale is a digital twin that enumerates the security controls where they exist in your documentation, overlays them on the architecture, and employs AI to create a test plan and execute test cases against each control. The output is test case evidence per control: implementation confirmed, efficacy measured, and any associated weakness or vulnerability captured against that control.

The fix is resolution. Manufacturers should use AI to consume the threat model they have, overlay it on a digital twin, and expand it to significantly more detail: not just the high-level system, but the intimate behavior of each process inside the product. ELTON does this with proper access from the manufacturer, using not just static scans of code and firmware but real threat actor runtime access to the device.

The result is an enumeration of threats and a cybersecurity test plan 10x anything a human could produce. Is that a problem? Is that too many tests now? For a human, yes. Not for ELTON AI, which executes remotely in your lab or ours. The goal is closing the loop: your FDA-required threat model, your cyber testing, and the vulnerabilities you disposition, moving together in concert, with FDA MDDT rating criteria applied throughout.

If a single vulnerability sits untriaged with a default rating that, evaluated against your cybersecurity patient safety criteria, looks like uncontrolled risk, you have failed. It does not matter that the severity is wrong and was simply never adjusted. You missed it, and the record shows you missed it.

For every finding that arrived as a CVSSv3 HIGH or CRITICAL and was reduced (which is common, and often correct), the reduction needs documented rationale. No justification, and FDA can take issue with the change. And when Bob's rating and Joe's rating differ because they triaged with different criteria, that inconsistency itself is audit risk. This is why digital twins and automated triage with built-in FDA MDDT criteria for CVSSv3 and CVSSv4 are critical: one set of criteria, every finding, rationale attached automatically.

The same vulnerability has to be evaluated within each release, against that release's unique attributes: its own digital twin, its own component versions, its own mitigations, and its own set of co-resident vulnerabilities that could chain. A disposition that is true for v3.0 can be false for v2.1, and an auditor will ask about both.

Manual teams collapse this to one row per CVE because per-release triage multiplies the workload by the size of the installed base. That shortcut is exactly what an investigator is trained to find.

ELTON runs manual and automated continuous vulnerability discovery across every source: code, dynamic scanning, fuzzing, reverse engineering, penetration testing, and SBOM CVE proof-of-concept work. Delivery is your choice: the ELTON managed service via subscription testing, or your own team using self-service TestLink™ appliances.

Testing is executed by experienced penetration testers working with an agentic AI physical device testing loop, custom-built over three years, purposely for medical devices. Here's the part most people miss: it is not about the model. It is about the harness. ELTON built an extensive ability for AI to reason about the attack surfaces ELTON identified, to interact with physical interfaces, and to employ loot obtained in one area of the product to iteratively bypass the next. The model provides reasoning. The harness provides a decade of device muscle memory.

Connect a TestLink™ appliance to the device. Log in to the platform and associate it with a digital twin. Tell the platform which physical connections the appliance has by selecting the twin component that matches each physical connection. Then push the button: the test plan executes, test case results stream in, and vulnerabilities appear as findings, live.

As testing continues, move the appliance across different interfaces (Ethernet to USB to serial) and execute more of the plan, completing the assessment interface by interface. The engineer who wrote the code watches the results arrive at the same bench where the code runs.

The old economics were brutal: book a consultancy, wait for the slot, ship them hardware, wait for the report, dispute the findings, then book again to re-test the fixes. Weeks per cycle, repeated for every release. A TestLink™ fleet inverts that. Developers run self-directed pentesting the moment a build lands, test plans come from the digital twin, and results stream into the platform while the build is still warm. That is where the 90% goes: the waiting, the shipping, the scheduling, the re-engagement, all gone. Products ship faster because testing moves at the speed of the team, not the vendor's calendar.

And here is the part your regulatory team will ask about first: self-directed does not mean self-invented. Every fleet test executes ELTON's methodology, every finding is rated with the FDA MDDT criteria, and every report retains the ELTON brand and the FDA approved vendor credentials reviewers already recognize from 600+ submissions. Your engineers push the button. The evidence still carries the vendor's name.

ELTON attempts real exploitation on real runtime access, on demand, as soon as an SBOM CVE is recognized. When the platform identifies a new CVE or SAST finding, it creates a test, identifies the test case to run, and if a TestLink™ or a build environment is connected, attempts the exploit.

The result is a test case outcome that records exactly when exploitation was and was not possible, relative to the test case and the access used. That evidence lets the vulnerability status change immediately and automatically to Not Affected in VEX, and removes the issue from all vulnerability chaining analysis. The disposition is not an opinion about reachability. It is the recorded outcome of an attempt.

ELTON's platform lets a manufacturer take that position on the record, and defend it, because ELTON can defensibly define what is and is not exploitable. The digital twin builds attack paths from known initial access points (the attack surface) to identify what is directly exploitable. Those are the root vulnerabilities, and they are the only findings that are directly exploitable.

Everything gained through a root is an indirect, conditionally exploitable vulnerability: real, but only alive while its enabling conditions are produced upstream. Findings with no path and no met conditions are weaknesses. Three states, computed from the graph, not asserted by an analyst.

Who says a CVSS 10 matters when it is not even exploitable? The FDA does, if you are calling it a vulnerability. But it is not a vulnerability if it is not exploitable. That is a weakness. ELTON determines what is directly exploitable based on conditions that are met (keys that are known, credentials, runtime access) and the graph path of the digital twin: which root vulnerability meets conditions that enable the other, indirect vulnerabilities, and which findings have no conditions or paths at all.

Try it below. The kiosk breakout is a root vulnerability. It produces one condition: OS access. Every vulnerability living on the OS needs that condition to be exploitable. Fix the kiosk root and watch the OS findings become weaknesses on the fly. Their isolation scores never change. Their status does.