Legacy Medical Device Cybersecurity: The 2026 FDA Guide

Everything a medical device manufacturer needs to know about running a defensible cybersecurity program for devices that were cleared before Section 524B, that predate modern SBOM tooling, or that are approaching end of support. Aligned to the February 2026 final premarket cybersecurity guidance, Section 524B of the FD&C Act, and IMDRF N60.

Last updated: July 2026.

Talk to us about your legacy fleet

1. What "Legacy" Actually Means

The industry uses "legacy" three different ways, and only one of them is a regulatory definition.

• Colloquial legacy - "we cleared this before 2023 so 524B doesn't apply." This is wrong. Section 524B applies to any cyber device currently in commercial distribution, regardless of clearance date.
• IMDRF N60 legacy - a device that "cannot be reasonably protected against current cybersecurity threats." This is the definition the FDA references, and it is a manufacturer determination based on the device's capability, not its age.
• Internal legacy - a device your engineering team no longer builds from source, whose original toolchain is unavailable, or whose third-party dependencies are unsupported.

Only IMDRF N60 legacy carries regulatory weight, and it is the framing you should use in every submission, MDS2, and customer communication. Age alone is not a defense - a 2011 clearance with a maintained build pipeline and a current SBOM is not legacy; a 2024 clearance shipped on a discontinued microcontroller with no update path is.

2. Why the FDA Cares About Legacy Devices

The February 2026 final guidance is explicit: cybersecurity obligations attach to the marketed device, not to the clearance decision. That means:

1. Every device in distribution needs a maintainable SBOM. If you cannot produce one, you cannot demonstrate you are monitoring for vulnerabilities.
2. Every device needs a postmarket vulnerability management plan aligned to AAMI TIR97 and referenced in your QMS.
3. Every device needs a coordinated vulnerability disclosure (CVD) path - a security.txt, a published policy, and a triage SLA.
4. End-of-Support is a regulated event. It requires written customer notice, an inspectable rationale, and (where safety-relevant) an MDR/MedWatch decision.

Legacy devices concentrate the FDA's postmarket risk model. They ship with older TLS stacks, unpatched RTOS versions, hard-coded credentials that pre-date modern threat guidance, and communication protocols (HL7 v2, DICOM without TLS) that were never designed to be internet-adjacent. The FDA cybersecurity program treats "we didn't have to worry about that when it was cleared" as an inadequate response.

3. The IMDRF N60 Lifecycle Stages

IMDRF N60 breaks a legacy device's remaining life into four stages. Use these terms in your MDS2, customer letters, and postmarket plans - reviewers and hospital procurement teams recognize them.

Publishing the transition dates for each stage - and honoring them - is the single most defensible thing a manufacturer can do with a legacy fleet. Ambiguity here is what gets manufacturers into trouble with both the FDA and hospital ISO 27001 / HITRUST auditors.

4. Reconstructing the SBOM When You Don't Have the Build

The most common legacy blocker is: "we don't have the original build pipeline, we can't generate an SBOM." That is not an acceptable answer under 524B. There are three practical paths, in order of preference.

4.1 Rebuild from source

If the source and toolchain still exist (or can be reconstructed from a container image), run a modern SBOM generator - Syft, cdxgen, or your build system's native emitter - and produce a CycloneDX 1.5+ or SPDX 2.3+ file. This is the only path that gives you a fully accurate transitive dependency graph.

4.2 Binary-only SBOM generation

When source is gone, run binary analysis against the shipping firmware or application image. Tools such as Syft (against a container or unpacked filesystem), Binwalk plus a component-identification pass, or commercial platforms (Finite State, Cybellum, Netrise, Medcrypt) can produce a component list from binaries alone. The output will be less complete than a source-built SBOM - transitive dependencies compiled into statically linked binaries can be invisible - but a documented, machine-readable binary SBOM plus a written statement of its limitations is defensible.

4.3 Supplier reconstruction

For components you cannot analyze (a closed OEM subsystem, a chip with encrypted firmware), request an SBOM from the supplier. If the supplier will not provide one, document the request, the response, and your compensating mitigations. The FDA has accepted supplier-gap disclosures when they are paired with a real mitigation plan; silence is what triggers deficiency letters.

The output of any of these paths must be a machine-readable file in a widely supported format. A PDF table copied from a vendor questionnaire is not an SBOM. See our SBOM guide and CycloneDX vs SPDX comparison for format details.

5. Vulnerability Triage Without Source Code

Once you have an SBOM - reconstructed or not - the triage loop is the same as for a modern device, with two adjustments.

Adjustment 1: exploitability determination matters more. For a legacy device you often cannot patch cheaply, so accurately dispositioning a CVE as "not affected" is what keeps your backlog manageable. Publish VEX documents alongside the SBOM to formally state not_affected, affected, fixed, or under_investigation for each match, with a machine-readable justification.

Adjustment 2: compensating controls carry more weight. If the vulnerable component cannot be patched without a new clearance, document the compensating control - network segmentation guidance in the MDS2, a firewall rule template, a physical port cover - and treat it as a mitigation of record under ISO 14971.

Score each finding using CVSS as the technical baseline and layer AAMI TIR57 / ANSI/AAMI SW96:2023 safety impact on top. A CVSS 9.8 in a component that is compiled in but never invoked is not the same emergency as a CVSS 6.5 in a component directly exposed to an unauthenticated network interface.

6. Communicating End-of-Support to Customers

End-of-Support is a regulated communication, not a marketing announcement. The February 2026 guidance and the FDA's postmarket cybersecurity guidance both expect written notice to affected users, with enough lead time for them to plan replacement or compensating controls.

A defensible EOS notice contains:

• Effective date of EOS, and separately of EOL if different.
• What continues during EOS (monitoring, CVD intake, MDS2 updates) and what stops (security patches, feature releases).
• Known unmitigated risks at the time of EOS - the specific CVEs you are leaving unpatched and why.
• Compensating controls hospitals can deploy (network segmentation, credential rotation, disabled services).
• Migration path to a supported product, if one exists.
• A point of contact for questions and vulnerability reports through EOL.

Send the notice through every channel the customer contract permits - email to the biomed contact, portal notification, physical letter for older accounts. Log every send. Hospitals will ask for this letter during their next Joint Commission or HITRUST audit, and the FDA will ask for it during any postmarket inspection that touches the device.

7. When a Cyber Fix Requires a New 510(k)

The hardest legacy decision is: we found a vulnerability, we know how to fix it, does the fix require a new submission? The framework is the FDA's 2017 software change decision tree, overlaid with the cyber-specific guidance in the 2026 final document.

A rough decision aid:

• Patch that only fixes a security defect, does not add capability, does not change intended use, and does not alter the risk profile - typically can be handled under design controls with a letter to file. Document the change control, the regression tests, and the SBOM delta.
• Patch that changes cryptographic algorithms, key management, authentication scheme, or network protocol - almost always a new 510(k). These are considered a change to the security architecture, not a bug fix.
• Change to add a modern update mechanism (OTA, signed firmware, TLS 1.3) - usually a new 510(k) or a Special 510(k), because it changes device capability and creates a new attack surface.
• Removal or disablement of a vulnerable feature - often a letter to file if the intended use is unchanged and safety is preserved, but document the risk-benefit analysis.

See our companion post on letter-to-file vs new 510(k) for cybersecurity changes for a fuller decision walk-through.

8. The Legacy Postmarket File - What to Keep

Assemble a single postmarket file per legacy device (not per legacy program), stored in the QMS, that a reviewer or inspector can pull in one request. Contents:

1. Current SBOM (machine-readable) and a note on how it was generated (source, binary, supplier).
2. Current VEX document covering all open CVE matches.
3. Postmarket cybersecurity management plan, aligned to AAMI TIR97.
4. CVD policy and a log of every externally reported vulnerability, with disposition.
5. MDS2 at its current revision, updated at each patch or at least annually.
6. IMDRF N60 lifecycle stage declaration and the dates of any transitions.
7. EOS communication log (drafts, send-list, and confirmations).
8. Change history - every letter to file, every 510(k) submitted for a cyber change.
9. Risk management file entries for each identified vulnerability, per ISO 14971 and AAMI TIR57 / ANSI/AAMI SW96:2023.

A hospital procurement review or an FDA inspection that finds this file complete will not escalate. One that finds it fragmented or missing will.

9. How Blue Goat Cyber Approaches Legacy Fleets

We work legacy programs in three phases.

Phase 1 - Baseline. We reconstruct the SBOM (source, binary, or supplier as needed), score the current vulnerability posture, and produce the IMDRF N60 stage declaration. Typical duration: two to four weeks per device family.

Phase 2 - Remediate and mitigate. For findings that can be patched under design controls, we scope and validate the change. For findings that cannot, we author the VEX disposition, the compensating-control guidance for hospitals, and the postmarket monitoring plan that will carry the device to EOS.

Phase 3 - Operate. Monthly SBOM refresh, monthly CVE triage, quarterly VEX update, annual EOS review, and a single postmarket file that any auditor or reviewer can be handed on request.

If you know the device is heading to end-of-support in the next 24 months, we also author the EOS customer communication, the internal decision memo, and the MDR/MedWatch analysis for any unmitigated safety-relevant risks.

See our postmarket services · See our SBOM services

Frequently Asked Questions

Does Section 524B apply to a device cleared in 2015?

Can we skip the SBOM if we cannot rebuild from source?

How long do postmarket obligations continue after End of Support?

Do we need to report every CVE that matches our SBOM?

Can we outsource EOS to a third party?

Related Reading

• SBOM for Medical Devices
• Postmarket Cybersecurity Readiness Plan
• Postmarket Cybersecurity Monitoring Program
• VEX Document for Medical Devices
• Coordinated Vulnerability Disclosure for Medical Devices
• AAMI TIR57 vs TIR97
• FDA 2026 Premarket Cybersecurity Guidance