A late-stage device manufacturer came to us with a problem that will sound familiar. Their premarket submission included an accurate SBOM listing nearly 100 unresolved vulnerabilities across embedded firmware, cloud components, and a clinician mobile app. Default CVSS ratings made a number of them look critical, several sat in third-party components already end of life, and FDA responded with Additional Information requests asking the obvious question: why are these acceptable?
An AI request also freezes the review clock. Every week spent assembling a response is a week added to launch, so speed mattered as much as substance.
Patching or replacing those dependencies weeks before submission was not a real option. Swapping an end-of-life library that close to the line risks destabilizing a validated product and pushing market entry out by months. Some flagged components were end of support entirely, meaning no patch was coming at any price. And the team's initial justifications for leaving CVEs open were developer opinion, sincere and probably right, with nothing behind them a reviewer could verify. Opinion does not survive an AI letter.
There were two ways to respond. Validate only the CVEs FDA had flagged, or analyze the full SBOM. The narrow path was cheaper and faster, but any unexamined vulnerability was an open invitation for the next round of questions. The manufacturer chose full coverage, with a hard constraint: it had to land inside the FDA response window.
A digital twin of the product already existed from penetration testing, so every SBOM component could be mapped to its logical place in the system: which subsystem, which interfaces, which trust boundaries. From there ELTON rescored each vulnerability in context rather than in the abstract. No CVE was skipped on the theory that nobody would ask about it.
Ratings were recalculated with the MDDT-aligned CVSS rubric and native CVSSv4 metrics, including Attack Requirements, with SSVC intelligence layered in for real-world compromise signals. Then path analysis: from each attack surface on the device (Bluetooth, Wi-Fi, and physical interfaces) to each CVE, accounting for vulnerability chaining across components. Every score shipped with a written justification for each metric and a reference into the twin, so a reviewer could reproduce the reasoning instead of taking our word for it.
Inside the response window, the manufacturer submitted a complete report justifying every SBOM CVE with product-specific reasoning and revised CVSSv3 and CVSSv4 ratings tied to their threat model and security controls. The deliverable was deliberately unglamorous: a workbook covering every entry, line by line. Reviewers do not want narrative. They want line-item defensibility they can check, and the conclusions held up.
"We see no purpose in procuring other vulnerability assessment tools with this type of methodology and defensibility." (Director of R&D at the manufacturer, a late-stage startup)
The AI response was the urgent problem, but it is not the interesting one. The same twin, rubric, and path analysis now run continuously for this manufacturer's postmarket monitoring, and the next submission starts from evidence instead of a blank page. Answering FDA once is a fire drill. Being able to answer FDA any day of the year is a process, and that is the thing worth having.
An AI letter is survivable. Building your vulnerability story out of opinion, and hoping nobody asks, is the actual risk.
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.