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 we have no cybersecurity obligations." This is wrong. Section 524B applies to submissions made after March 29, 2023, so it does not reach back to older clearances on its own, but fielded devices are still covered by the FDA's postmarket cybersecurity guidance and quality system rules, and the next submission for a modified version brings Section 524B in.
• 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 premarket guidance does not impose retroactive documentation mandates on every marketed device. For legacy fleets, we recommend these risk-management practices alongside applicable quality system and reporting obligations:

1. Maintain component information where feasible. SBOM reconstruction can support vulnerability monitoring, but is not a universal retroactive requirement.
2. We recommend each device have a postmarket vulnerability management plan aligned to AAMI TIR97 and referenced in your QMS.
3. We recommend each device have a coordinated vulnerability disclosure (CVD) path - a security.txt, a published policy, and a triage SLA.
4. Plan end-of-support communication. Document the rationale, inform customers, and assess applicable reporting obligations based on the facts.

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 for postmarket vulnerability management, and it will not pass at your next Section 524B submission. 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. Disclose supplier gaps and mitigations transparently. Their adequacy is device-specific; disclosure does not establish that the FDA will accept an incomplete SBOM.

The output of any of these paths should preferably be a machine-readable file in a widely supported format. A PDF component table may be less useful for automated monitoring; format alone does not determine statutory adequacy. 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, or network protocols - evaluate under the FDA's software-change 510(k) decision framework, considering intended use, safety, effectiveness, and verification and validation. These changes do not automatically require a new 510(k).
• Change to add a modern update mechanism - apply the same software-change decision framework and document the rationale for whether a new 510(k) is needed.
• 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. Optional 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 cybersecurity guidance

Free tools for this

• Legacy / End-of-Support Triage - triage components approaching end of support and plan the evidence.