Manufacturers ask me some version of this question every month: our device was cleared years before Section 524B and the 2023 premarket guidance existed, so the monitoring and annual testing expectations surely don't apply to us? They do. If the product is still commercially distributed, the obligation is live. The FDA draws the line at commercial status, not clearance date.
The FDA's 2016 Postmarket Management of Cybersecurity in Medical Devices guidance remains the foundation for every marketed device. It expects manufacturers to monitor for vulnerabilities, assess their impact on safety and essential performance, and maintain a coordinated disclosure and remediation process across the device's lifecycle. Nothing in it is scoped to devices cleared after a particular date.
That matters because teams often treat 2023 as a boundary. New rules for new submissions, silence for everything older. The postmarket side has no such boundary. A device cleared in 2014 that ships today carries the same monitoring expectation as one cleared last quarter.
Section 524B attaches to new premarket submissions for cyber devices. It does not reach back and rewrite a clearance from 2016. But that's narrower comfort than it sounds. The moment a legacy product line returns to the agency for a new version or a significant change, 524B applies in full. And until then, the 2016 postmarket guidance and your quality system obligations already cover whatever you're shipping.
The 2023 premarket guidance and its 2025 update reinforce this rather than replace it. Both treat cybersecurity as a lifecycle obligation: vulnerabilities managed continuously and exploitability evaluated within each commercial release, with metrics to prove it. Neither offers an exemption for products that predate them.
The practical consequence: every release still in commercial distribution needs its own monitoring record and periodic security testing, typically annual. Evidence has to line up with the specific version customers are running, not with the product family in general. Once a release reaches end of life and is no longer distributed or supported, the recurring obligation ends with it.
Monitoring, concretely, means new vulnerabilities evaluated against the composition of each supported release, an assessment of impact on safety and essential performance, and a documented disposition with rationale. Periodic testing is the check on those assumptions. It confirms whether the vulnerabilities you deferred on paper are actually unreachable on the device.
Inspections follow the same logic. The legacy findings I see come in two flavors: no evidence of recent security testing on a device that's still selling, or vulnerability records blurred across versions so nobody can say what applies to the release under audit. Both are process failures. Both are avoidable.
The clearance date tells you which premarket rules applied. The shipping date tells you which postmarket obligations apply. Only one of those ever expires.
None of this means testing everything forever. The scope is your active, non-EOL releases and nothing else. We built ELTON around that boundary: the platform catalogs vulnerabilities and test results per release, keeps monitoring and recurring testing running for versions still on the market, and retires coverage when a release is formally end-of-lifed. What you get is a regulator-ready record for each version you still sell, and no spend on the ones you don't.
"Legacy" describes the technology, not the obligation. If you're still selling it, you're still securing it. Manufacturers who internalize that early get to treat legacy compliance as routine maintenance. The ones who don't tend to discover it during an inspection, which is the most expensive way to learn anything.
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.