SBOM EOS, EOL, & LoS for FDA 524B

Last updated: June 2026

Why this matters

The distinction between End of Support (EOS), End of Life (EOL), and Level of Support (LoS) is critical for medical device manufacturers. Failure to track and proactively manage the EOS dates of SBOM components can lead to unpatchable vulnerabilities, rendering devices insecure and non-compliant with regulatory expectations. The FDA's 'Cybersecurity in Medical Devices' Final Guidance, dated February 3, 2026, recommends that manufacturers provide a support status and, where known, an end-of-support date for every SBOM component. This guidance recommends a Total Product Lifecycle plan outlining actions when components near or reach EOS during a device's market lifespan. Ignoring these distinctions undermines a manufacturer's ability to demonstrate a controlled and secure supply chain, potentially leading to significant delays in market authorization or adverse postmarket actions. Adherence to standards like IEC 81001-5-1, ISO 14971, and AAMI TIR57 / ANSI/AAMI SW96:2023 also necessitates a clear understanding of component lifecycles to effectively manage cybersecurity risks throughout the product lifecycle.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); CISA Software Bill of Materials resources; FDA Cybersecurity in Medical Devices FAQs (Section 524B).

EOS vs EOL vs LoS

End of Life (EOL)

EOL is the umbrella roadmap milestone. The vendor has announced that the product is being wound down. EOL alone tells you nothing about whether the component is still patched, still sold, or still safe to ship. Microsoft, Cisco, and Red Hat all use EOL as a calendar event, not a technical state. Treat EOL as "we have been put on notice."

End of Support / End of Sales (EOS)

EOS is the term that matters for FDA submissions. Two flavors:

• End of Sales - the component can no longer be licensed or purchased new. Existing deployments may still be supported.
• End of Support - the vendor stops issuing security patches, bug fixes, and technical assistance.

End of Support is the cybersecurity-relevant one. It is the date the patch pipeline closes. Once it passes, every new CVE against that component lands in your risk file with no upstream remediation path. FDA guidance recommends end-of-support information; Section 524B(b)(3) does not enumerate that field. Explain unavailable information and related risk controls.

Level of Support (LoS)

LoS is the tier of service you are entitled to while a component is still supported. Common tiers:

• Mainstream / Full - security patches, bug fixes, new features.
• Extended / Sustaining - security patches only, often paid (Microsoft ESU, Red Hat ELS, Ubuntu Pro).
• Self-support / Community - documentation only, no SLA, no committed patches.
• Custom paid extension - negotiated past the public EOS date.

LoS matters because two devices using the "same" component can have very different risk postures. A component on paid extended support is materially different from one on community best-effort, and the FDA expects the SBOM to reflect that.

How vendors actually stage these

A typical Microsoft, Cisco, or Red Hat lifecycle:

GA -> End of Sales -> End of Mainstream Support -> End of Extended Support -> EOL

Each transition changes the LoS tier. Your SBOM has to track which stage each component is in today, not when the device was cleared.

What the Feb 3, 2026 FDA guidance recommends

The current premarket guidance is "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," issued February 3, 2026. It supersedes the June 27, 2025 and September 27, 2023 versions. Do not cite the older documents in new submissions.

Four expectations are directly relevant to component lifecycle:

1. SBOM with support status and end-of-support date (guidance recommendation)

For cyber devices submitted through 510(k), PMA, PDP, De Novo, or HDE pathways, Section 524B requires a postmarket vulnerability monitoring and coordinated disclosure plan, cybersecurity processes including updates and patches, and an SBOM submitted to the FDA. The FDA guidance recommends an SPDF, threat modeling, security architecture documentation, and security testing; those recommendations are distinct from the statutory requirements. Support level and end-of-support data are guidance recommendations. eSTAR submissions undergo technical screening rather than the RTA checklist.

2. Total Product Lifecycle (TPLC) plan

The 2026 guidance reinforces a QMS-integrated TPLC view. Components projected to cross EOS during the device's market life need a plan before submission: replace, upgrade, isolate, or document a risk-accept with compensating controls. "We will deal with it later" is not a TPLC plan.

3. The four recommended architecture views

EOS components show up explicitly in two of the four recommended views:

• Updateability and Patchability View - if the upstream is EOS, the patch path is broken. Show the broken path and how the architecture compensates.
• Security Use Case View - the compensating controls (network isolation, allowlisting, monitoring) for unpatchable components live here.

The other two views (Global System, Multi-Patient Harm) inherit consequences from EOS components but are not the primary place to document them.

4. Risk management tie-in with AAMI TIR57 and ANSI/AAMI SW96

Every EOS component must be evaluated for patient-harm impact through your ISO 14971 risk file, using TIR57 principles premarket and SW96 across the lifecycle. "We cannot patch it" is not a risk treatment. The defensible position is compensating controls plus a documented residual risk acceptance, signed by the same risk authority that signs the rest of the file.

How to express lifecycle data in the SBOM

If you want this done for your device, see our FDA-compliant SBOM services.

CycloneDX 1.5+

CycloneDX supports lifecycle phases, which are not the same as vendor support status. This illustrative fragment uses custom properties and notes for support data:

{
  "component": {
    "name": "openssl",
    "version": "1.1.1w",
    "supplier": { "name": "OpenSSL Project" },
    "pedigree": {
      "notes": "EOS 2023-09-11; no upstream patches. Compensating controls in Security Use Case View v3."
    },
    "properties": [
      { "name": "lifecycle:status", "value": "end-of-support" },
      { "name": "lifecycle:eos-date", "value": "2023-09-11" },
      { "name": "support:level", "value": "community-only" }
    ]
  }
}

See also: FDA Section 524B Subsections Explained, SBOM for Third-Party Chip Firmware, and 510(k) Cleared, No Postmarket Cybersecurity: Legal?.

The lifecycles element at the BOM root captures the overall lifecycle phase; per-component status is best expressed via properties plus pedigree notes until tooling standardizes.

SPDX 2.3

SPDX is weaker here. Use annotations with a structured comment convention so downstream consumers can parse:

Annotator: Tool: bgc-sbom-lifecycle
AnnotationDate: 2026-06-01T00:00:00Z
AnnotationType: OTHER
AnnotationComment: <text>lifecycle.status=end-of-support; eos.date=2023-09-11; support.level=community-only</text>

If you have a choice, ship CycloneDX 1.5+ as the primary format for the FDA submission and SPDX as a secondary export.

The EOS decision tree

When a component is EOS (or will be during market life), there are four defensible branches. Pick one per component and document the choice in both the architecture views and the risk file.

Component going EOS
|
+-- Replace      -> swap to a supported alternative, re-verify, file as material change if required
|
+-- Fork / fund  -> in-house fork or paid extended-support contract (LoS = extended)
|
+-- Isolate      -> compensating controls in the Security Use Case View; residual risk accepted under ISO 14971
|
+-- Accept       -> risk-accept with executive sign-off; allowed only when patient-harm impact is demonstrably low

Reviewers reject submissions where the branch is implicit. Make it explicit, per component, with traceability into the risk file.

The canonical VEX statement for an EOS component

When a new CVE lands against an EOS component you have chosen to isolate, the defensible VEX shape is:

{
  "vulnerability": { "id": "CVE-2026-XXXXX" },
  "products": [{ "id": "device-model-x", "version": "3.2" }],
  "status": "affected",
  "action_statement": "Apply documented network isolation and access restrictions; evaluate supported replacement.",
  "response": ["will_not_fix"],
  "detail": "Component openssl 1.1.1w is end-of-support (2023-09-11). Compensating controls: network segmentation per Security Use Case View v3, allowlisted egress, signed firmware. Residual risk accepted in RMF-2026-014."
}

This is a conceptual record, not a schema-valid example of a particular VEX format. An affected statement needs an action statement, not a not_affected justification. A will_not_fix decision needs risk evidence and does not establish regulatory acceptability.

Reviewer red flags

The February 2026 revision primarily aligns with the QMSR, not a demonstrated increase in reviewer strictness. Recommended internal review checks include:

• SBOM entries with no support_status field, or "unknown" without justification.
• Known-EOS components (OpenSSL 1.1.1, CentOS 7, Python 2.7, older Linux kernels) shipped with no Updateability View commentary.
• Patchability View that shows a patch channel for a component whose upstream is dead.
• Risk file that scores an EOS component identically to a supported one with no compensating-control analysis.
• VEX statements that mark EOS components as "under investigation" indefinitely.
• TPLC plan that ends at clearance with no maintenance horizon.

How this connects to the rest of the program

EOS is a cross-cutting concern. It touches:

• The SBOM (Section 524B(b)(3) fields)
• The threat model (assets behind unpatchable components)
• The architecture views (Updateability, Security Use Case)
• The risk file (ISO 14971 + SW96 residual risk)
• The postmarket plan (VEX, monitoring, CAPA triggers)
• The labeling (customer security documentation for unsupported components)

Treat it as a single thread that runs through every cybersecurity artifact in the submission, not as an SBOM-only field.

Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.

How Blue Goat approaches this

Blue Goat Cyber's approach to SBOM End-of-Support management focuses on proactive risk mitigation and regulatory compliance. Our experts assist manufacturers in accurately delineating EOS, EOL, and LoS for all medical device software components, aligning with the FDA's 'Cybersecurity in Medical Devices' Final Guidance dated February 3, 2026. We help integrate lifecycle data into SBOMs using formats like CycloneDX 1.5+ and develop thorough Total Product Lifecycle plans for managing components approaching EOS. Our team, comprised of CISSP and OSCP certified professionals, including ex-military red team personnel, specializes in identifying potential vulnerabilities arising from unsupported software and formulating defensible VEX statements for non-remediable issues. We help align premarket submissions with FDA recommendations, and if the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Learn more about our specialized FDA premarket support at: FDA premarket cybersecurity services

---

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.

To keep your SBOM and vulnerability records current after clearance, GoatWatch matches components to new CVEs and tracks VEX decisions.

Need ongoing help tracking component support dates and SBOM updates? See our medical device security advisory.

FAQ

Is End of Life the same as End of Support?

No. End of Life is an umbrella roadmap announcement that a product is being wound down. End of Support is the specific date the vendor stops issuing security patches. EOL is calendar; EOS is technical. The FDA cares about EOS because that is when the patch path closes under Section 524B.

Does the FDA require an EOS date in the SBOM?

Section 524B(b)(3) requires an SBOM including commercial, open-source, and off-the-shelf software components; it does not enumerate support-status or EOS fields. FDA guidance recommends supporting information on each component’s level of support and end-of-support date. Explain unavailable information and its risk-management implications.

Can we ship a device with EOS components?

Yes, but only with a defensible plan. The acceptable patterns are replace, fork or fund extended support, isolate with compensating controls, or risk-accept with executive sign-off and demonstrably low patient-harm impact. The choice must be reflected in the architecture views and the ISO 14971 risk file.

How do we express EOS in CycloneDX vs SPDX?

CycloneDX lifecycle phases describe stages such as build or operations, not vendor support status. Support level and EOS dates can be recorded through documented custom properties or notes; SPDX 2.3 annotations can carry a documented convention. Validate the chosen schema and explain the convention. FDA does not require a preference for CycloneDX over SPDX.

What is the right VEX status for an EOS component with no patch?

EOS alone does not determine VEX status. Assess the specific product and vulnerability. An affected status should communicate remediation or mitigation through an action statement; vulnerable_code_not_in_execute_path is a justification for not affected, not affected. Use format-specific response fields only where supported, and document the basis and review date.

Which FDA guidance should we cite?

Cite "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," issued February 3, 2026. It supersedes the June 2025 and September 2023 versions. Do not cite the older documents in new submissions.

More on this topic

• Docker Containers in Medical Devices: FDA
• Secure Update Infrastructure for Medical
• Medical Device Incident Response Plan