Every commercial release of a medical device is a distinct combination of software, firmware, and third-party components, and regulators treat it that way. Audits and submissions are evaluated per release, not per product family. So testing evidence that describes v3.2 says very little about v4.0, and blending findings across versions is how manufacturers end up with records nobody can defend.
The FDA's 2016 postmarket guidance set the expectation directly:
Cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually).
One sentence, large consequences. Testing has to reflect the current commercial state of the product, not a prior build or a legacy release. The 2023 premarket guidance reinforces the same principle through its ongoing risk management and vulnerability metrics expectations. And the practical translation the industry settled on is recurring testing per active release, usually annual. Roughly three quarters of manufacturers of connected devices already run on that cadence.
Other regulators land in the same place. MDCG guidance under EU MDR expects periodic verification of security controls for each distributed version. Australia's TGA expects recurring testing for networked devices. Health Canada points testing at the released configuration. IMDRF recommends periodic security testing, and Japan's lifecycle expectations under JIS T 81001-5-1 translate to the same per-release rhythm in practice. The wording varies. The expectation doesn't: marketed versions carry a recurring testing obligation until EOL.
Here's the tension. The obligation is per release, but the traditional delivery mechanism (a scheduled penetration test engagement, once a year) is per calendar. A portfolio with six active releases either funds six engagements every year or quietly lets one test stand in for versions it never touched. Most portfolios drift into the second option, and audits find it: the tested configuration doesn't match the release under review, or vulnerabilities aren't tracked to the version they actually affect.
I spent years on the delivery side of those engagements. The work was real. The economics were the problem, because no team can hand-test every release of every product every year, and the annual pentest quietly became a sampling exercise pretending to be coverage.
This is why testing in ELTON is a platform function, not a service engagement. The platform runs SAST, DAST, protocol fuzzing, and pentest-class attack testing against the actual device, and it runs them per release, because the release is the unit the compliance record keeps. A new release gets its own testing cycle and its own evidence the moment it exists. An EOL release drops out of coverage. The annual interval stops being a scheduling problem and becomes a floor the platform maintains on its own.
Per-release testing also answers the question SBOM monitoring can't: is this vulnerability exploitable in this version's architecture? A CVE that matters in v3.2 can be unreachable in v4.0 because an interface closed or a component moved. Verifying that on the real device is what lets you fix the small set that's exploitable and document why the rest isn't, instead of patching on speculation and destabilizing a cleared configuration.
The artifact that gets you through an inspection is boring on purpose: for each active release, a current test record, vulnerabilities cataloged against that exact version, dispositions with written rationale, and a clean line back to the SBOM entry each finding came from. ELTON keeps that lineage per release automatically and exports it in regulator-ready form, VEX included, so the evidence for the audited version is never entangled with its siblings.
Annual testing per release was never really the burden manufacturers thought it was. Manual delivery was. Once testing is automated and bound to the release lifecycle, the defensible standard is also the affordable one, and there stops being any reason to argue with the regulation.
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.