Does FDA Section 524B Apply to Legacy Devices?

Legacy device questions about Section 524B keep landing in the same place: a sponsor with a cleared platform from 2015 wants to ship a connectivity update, an AI feature, or a hardware refresh, and the team assumes the original clearance grandfathers the cybersecurity work. It does not. The cyber device statute is keyed to the submission, not to the device's clearance history. The February 3, 2026 final premarket cybersecurity guidance reinforces this reading by treating every new submission for a cyber device as a 524B submission regardless of the platform's age. Sponsors that miss this draw refuse-to-accept (RTA) decisions on submissions they thought would sail through.

Key Takeaways

• Section 524B attaches to the submission, not the device's original clearance date. A new 510(k) on a legacy platform is a 524B submission.
• If a legacy device is already on the market and you are not filing a new submission for it, Section 524B does not reach back and force a 524B package on you. The FDA's separate postmarket cybersecurity rules (vulnerability monitoring, patching, and MDR reporting) still apply.
• "Special 510(k)" and PMA supplements on legacy cyber devices trigger full 524B content for the changed subsystem and often the platform as a whole.
• The PATCH Act covers the same problem space for new devices but leaves fielded legacy devices outside its premarket regime; postmarket obligations fill that gap.
• The riskiest assumption is that a pre-2023 clearance grandfathers the cybersecurity work. It does not.

Table of Contents

• What "Legacy" Means in a 524B Context
• When Section 524B Attaches to a Legacy Device
• When 524B Does Not Apply but Postmarket Obligations Do
• Submission Types and 524B Scope on Legacy Platforms
• What a 524B-Clean Submission on a Legacy Platform Looks Like
• Deficiency Patterns Specific to Legacy Submissions
• How Blue Goat Approaches a Legacy 524B Submission
• FAQ

Why this matters

Section 524B took effect on March 29, 2023, and the FDA began issuing refuse-to-accept (RTA) decisions based on 524B on October 1, 2023. The February 3, 2026 final premarket cybersecurity guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," is the operative interpretation reviewers apply. The guidance does not exempt legacy platforms. It applies to any premarket submission for a cyber device, full stop. CDRH performance data through FY2024 shows cybersecurity remains a top deficiency category in 510(k) and PMA Additional Information letters (the FDA's CDRH FY2024 Performance Report puts cybersecurity behind only software documentation and clinical evidence). Sponsors with legacy platforms are disproportionately represented in those deficiency letters because they assume the original clearance covers them. Standards reviewers expect against the legacy base include AAMI TIR57:2016/(R)2023, AAMI SW96:2023, IEC 81001-5-1:2021, and IEC 62304:2006/A1:2015. None of these standards have a legacy exemption either; the SDLC and security risk management expectations apply to the submission's design baseline, not the device's clearance year.

What "Legacy" Means in a 524B Context

The FDA does not define "legacy device" in 524B itself. The working definition reviewers apply, consistent with the FDA's 2017 Postmarket Management of Cybersecurity in Medical Devices guidance, is a device that is on the market and that the manufacturer can no longer reasonably update with the cybersecurity controls a modern submission would require. The clearance year matters less than the present-day support posture. A 2017-cleared infusion pump that the manufacturer still actively maintains is treated very differently than a 2017-cleared pump that the manufacturer stopped patching in 2021. For 524B purposes, the only question that matters is whether a new premarket submission is in the pipeline. If yes, 524B attaches. If no, the device falls under the FDA's postmarket authorities instead.

When Section 524B Attaches to a Legacy Device

Section 524B(a) attaches its requirements to any person who submits an application or submission described in section 510(k), 513, 515(c), 515(f), or 520(m) of the FD&C Act. In practice that means 510(k), De Novo, PMA, PMA supplement, PDP, and HDE submissions. The statute is keyed to the submission, not to the device's first clearance. If you are filing any of these submission types for a cyber device, 524B attaches, regardless of how old the underlying platform is.

The most common triggers on legacy platforms are:

• A Special 510(k) for a software or connectivity change to a previously cleared device.
• A Traditional 510(k) for a hardware refresh that retains the legacy software architecture.
• A PMA supplement adding an AI/ML feature, a new connectivity interface, or a cloud backend.
• A PMA supplement or 510(k) updating a component subsystem (radio module, gateway, companion app).

In every case the cybersecurity content scope covers the changed subsystem at minimum, and often the platform as a whole because the threat model and architecture views cannot meaningfully address the change in isolation.

When 524B Does Not Apply but Postmarket Obligations Do

A legacy device that the manufacturer is not currently submitting to the FDA does not pick up 524B obligations retroactively. The statute has no look-back provision. That does not make the device cybersecurity-exempt. The FDA's postmarket authorities for cybersecurity, anchored in the FDA's 2017 Postmarket Management of Cybersecurity in Medical Devices guidance and the agency's general quality system and adverse event reporting rules, continue to apply. Manufacturers of fielded legacy cyber devices remain responsible for monitoring vulnerabilities in deployed software components, assessing patient safety impact of new vulnerabilities, communicating with users and customers about uncontrolled risk, and reporting under 21 CFR Part 803 when a cybersecurity event meets the malfunction or serious-injury threshold.

The PATCH Act provisions added by the Consolidated Appropriations Act, 2023 codified the premarket cybersecurity expectations into 524B but did not create a retroactive sweep for fielded legacy devices. The legacy gap the industry talks about is real: a 2014-cleared pump with hard-coded credentials is not picked up by 524B today, but it is also not invisible to the FDA. Postmarket obligations and MDR reporting still apply.

Submission Types and 524B Scope on Legacy Platforms

Submission type on a legacy cyber device	Does 524B attach?	Scope of cybersecurity content
Special 510(k) (software/UI change)	Yes	Changed subsystem; threat model and SBOM updated to reflect change
Special 510(k) (cybersecurity update)	Yes	Changed subsystem and any control surface the change touches
Traditional 510(k) (hardware refresh)	Yes	Full 524B(b)(1)-(3) content for the device as filed
De Novo (new indication on legacy platform)	Yes	Full 524B(b)(1)-(3) content
PMA supplement (AI/ML feature, connectivity, cloud)	Yes	Full 524B(b)(1)-(3) content; the changed subsystem usually pulls in the platform
30-Day Notice (Class III mfg change, no software)	Often no	Cybersecurity only if the change affects security posture; reviewers may still ask
No submission pending (fielded device only)	No	Postmarket obligations apply under the 2017 postmarket guidance and 21 CFR 803

The pattern: any submission that touches device software, connectivity, or any control surface that could be vulnerable to a cybersecurity threat triggers 524B content. Mechanical-only or labeling-only changes are the rare exception.

What a 524B-Clean Submission on a Legacy Platform Looks Like

See also: FDA Section 524B Explained Subsection by Subsection: What Each Requirement Means in 2026, Documenting Update Cadence for an FDA 524B Submission, and CAPA and Medical Device Cybersecurity: Closing the Loop on Vulnerabilities and FDA Deficiencies.

A 524B-clean submission on a legacy platform organizes evidence subsection by subsection, the same way a new-device submission does, but it pays explicit attention to the legacy gap. The submission opens with an unambiguous 524B(c) cyber device determination naming every interface that touches device software (Ethernet, Wi-Fi, Bluetooth, BLE, NFC, USB service ports, JTAG, companion app, cloud backend, gateway). The 524B(b)(1) postmarket plan covers the current platform end-to-end, not just the changed subsystem. The 524B(b)(2) SDLC evidence shows that current development controls meet AAMI SW96:2023 and IEC 81001-5-1:2021 going forward; legacy code that predates these standards is addressed through a gap analysis and a remediation plan, not by claiming retroactive compliance. The 524B(b)(3) SBOM covers every component in the shipping build, including legacy commercial and open-source dependencies that the original submission never enumerated. The VEX statement set classifies known vulnerabilities in those legacy components by exploitability in the current deployed configuration.

The honest framing is: the legacy code is what it is, but the cybersecurity controls, monitoring, and update cadence going forward meet 524B. Reviewers accept this framing when it is explicit. They reject submissions that pretend the legacy gap does not exist.

Deficiency Patterns Specific to Legacy Submissions

Three deficiency patterns recur on legacy submissions:

• No 524B(c) determination. The submission carries forward the original device description, which predates the cyber device concept, and never states that the device is a cyber device. Reviewer treats it as silence and asks for a determination at best, RTAs at worst.
• SBOM that covers only the changed subsystem. A Special 510(k) for a software update produces an SBOM for the updated module only. 524B(b)(3) requires an SBOM for the device, not for the change. Reviewer asks for a full-device SBOM.
• Postmarket plan that references procedures that do not exist for the legacy platform. The plan describes a vulnerability monitoring and CAPA workflow that the manufacturer runs for new products but does not run for the legacy line. Reviewer flags the inconsistency.

The common thread: legacy submissions get into trouble when the cybersecurity content is treated as a delta against the previous clearance instead of a complete 524B response for the device as it ships today.

How Blue Goat Approaches a Legacy 524B Submission

We start with a 524B(c) determination and an interface inventory for the legacy platform as it ships today, not as it was cleared. We update the threat model and security architecture views to AAMI TIR57:2016/(R)2023, AAMI SW96:2023, and IEC 81001-5-1:2021, calling out the legacy code gaps explicitly with a remediation plan rather than claiming retroactive coverage. We regenerate the SBOM from the actual current build so transitive and legacy dependencies are captured, and we pair it with a VEX set scoped to the device's deployed configuration. The postmarket plan plugs into the manufacturer's CAPA procedure so vulnerability response has a closure record. Our engineers hold CISSP, OSCP, and prior military red-team credentials. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our FDA premarket cybersecurity service or read the 524B subsection-by-subsection walkthrough.

FAQ

Does FDA Section 524B apply to legacy medical devices?

Section 524B applies to any new premarket submission for a cyber device, including submissions built on a legacy platform. It does not retroactively sweep in devices already on the market with no submission pending. Fielded legacy devices remain subject to the FDA's separate postmarket cybersecurity authorities and to MDR reporting under 21 CFR Part 803.

Does a Special 510(k) for a small software change on a legacy device trigger 524B?

Yes. Any 510(k), Special or Traditional, for a cyber device is a 524B submission. The cybersecurity content must cover the changed subsystem at minimum, and reviewers usually expect threat model, SBOM, and architecture views for the device as it ships today, not for the changed subsystem in isolation.

What if the original clearance predates 524B?

The original clearance year is irrelevant to applicability. Section 524B(a) keys to the submission type, not to the device's first clearance. A 2015-cleared platform with a 2026 Special 510(k) is a 524B submission and must contain the full 524B(b)(1)-(3) content set.

How does the PATCH Act fit with legacy devices?

The PATCH Act provisions in the Consolidated Appropriations Act, 2023 codified premarket cybersecurity expectations into 524B. The statute did not retroactively cover fielded legacy devices, which is the "legacy gap" the industry talks about. Postmarket obligations under the FDA's 2017 postmarket guidance and 21 CFR Part 803 reporting still apply to those fielded legacy devices.

Do I need an SBOM for a legacy device with no pending submission?

Section 524B(b)(3) requires an SBOM as part of a premarket submission. With no submission pending, 524B does not compel one. The FDA's postmarket guidance still treats SBOM as the foundation for vulnerability monitoring, and HSCC and procurement frameworks like MDS2 expect one, so most manufacturers produce SBOMs for fielded legacy devices regardless.

Can I claim my legacy device is exempt from 524B because it has no Wi-Fi?

Almost never. The 524B(c) connectivity prong covers any interface that touches device software, not just network interfaces. USB service ports, Bluetooth, BLE, NFC, serial or JTAG ports, companion apps, cloud backends, and gateway-mediated paths all qualify. The only legacy devices that escape 524B are those with no software at all or software with no interface of any kind.

Ready to file a 524B-clean submission on a legacy platform?

If your next submission rests on a platform that predates 524B and the cybersecurity section is being written as a delta against the previous clearance, you are leaving deficiency exposure on the table. We can structure the submission so every 524B subsection has a labeled response and the legacy gap is addressed explicitly. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.

---

About the author. Christian Espinosa, Founder, Blue Goat Cyber, CISSP. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance, with deep experience on legacy platform submissions under Section 524B. Read more about Christian.