Meeting FDA vulnerability metrics with ELTON

Your Vulnerability Management Plan made promises. As of 2025, every FDA premarket submission includes one regardless of cyber device classification, and most manufacturers keep a matching SOP in the quality system. That plan names the metrics you committed to track and evidence for every software release of every product, premarket development through postmarket monitoring. The FDA reads it as a contract, and at some point someone will ask you to produce the numbers.

The premarket guidance is explicit about the shift: compliance is measured performance, not a checked box. Reviewers want vulnerability handling quantified over time so they can judge whether a product's risk is actually being monitored and mitigated across its lifecycle. We've watched teams try to collect this by hand, and I'll say it plainly. At the volume of vulnerabilities constantly surfacing against an existing device, manual collection is unsustainable. The spreadsheet dies within two release cycles.

The clocks

Three of the seven metrics are timers. Time-to-Triage runs from the moment a vulnerability surfaces, whether from SBOM monitoring or a pentest, to a documented decision: fix, defer, or accept the risk. Time-to-Remediation runs from identification to mitigation or patch. And coordinated vulnerability disclosure response timelines measure how quickly and how thoroughly you handle external reports.

Clocks need timestamps. ELTON ingests new CVEs continuously, matches them against product SBOMs and the digital twin, and logs first-detected and decision dates automatically, so Time-to-Triage and Time-to-Remediation fall out as byproducts with trend lines across products and releases. CVD intake gets the same treatment: external submissions timestamped, responses and mitigation progress logged, whether reports arrive through a third-party program or your own inbox.

The counters

Vulnerability density is the count of unresolved findings per product, per version, or per codebase, and it's the closest thing the FDA has to a hygiene score. Patch adoption rate asks what percentage of released patches actually reached devices in the field. Residual risk status is the honest snapshot of what remains after mitigations are applied.

We compute density across the portfolio, with concentrations visible by product, release, and component, down to root cause. Patch adoption we evidence by linking CVE closure to specific patch releases for connected and supported devices, so field coverage is demonstrated rather than estimated. Residual risk comes out of living vulnerability reports and contextual CVSSv4 scoring: whether a finding is still reachable or exploitable in the architecture as built, and where it isn't, the recorded justification for the no-fix determination. That last artifact is the one that saves you in an audit.

The cadence

Frequency of periodic testing rounds out the seven. The lifecycle approach expects regular penetration testing and security assessment, and it expects you to show the rhythm. So every pentest, fuzzing engagement, and SAST or DAST session lands in one log: when it ran, what it covered, how long since the last one. Demonstrating periodicity stops being an archaeology project through old statements of work.

Notice what the seven have in common. None of them is hard to define. Every one is hard to sustain, because each depends on a timestamped record created at the exact moment your team is busy doing the actual work. Metrics reconstructed after the fact are fiction with a date column.

And the number that matters most in practice isn't really a number. It's the evidence underneath: the recorded reason a fix wasn't performed. A fast Time-to-Remediation spent on findings that never needed fixing is money spent proving the wrong thing. If your program can produce all seven on demand, each backed by a defensible disposition, then the plan you filed and the process you run are the same document. Most programs I've reviewed can't say that yet, and the FDA only ever reads the plan.