SBOM End-of-Support, EOL, and Level of Support

Part of our Medical device SBOM and VEX series for FDA submissions. For the full overview, start with Medical Device SBOM: FDA Requirements and Submission Guide.

Last updated: June 2026

Key Takeaways

• EOS (End of Support) is the regulatory anchor - no upstream patches, no clean remediation path.
• EOL is a roadmap announcement, not a technical state; vendors use it inconsistently.
• LoS describes the tier of service (mainstream, extended, community) while a component is still supported.
• Section 524B(b)(3) requires support status and end-of-support date in the SBOM, per component.
• The Feb 2026 FDA guidance expects a Total Product Lifecycle plan covering components that will cross EOS during market life.
• CycloneDX 1.5+ expresses this natively via lifecycles and pedigree; SPDX 2.3 requires custom annotations.
• The defensible VEX status for an EOS component with no patch is typically affected + will_not_fix with a documented compensating control.

Table of Contents

• Key Takeaways
• EOS vs EOL vs LoS
• What the Feb 3, 2026 FDA guidance requires
• How to express lifecycle data in the SBOM
• The EOS decision tree
• The canonical VEX statement for an EOS component
• Reviewer red flags
• How this connects to the rest of the program

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, explicitly requires manufacturers to declare a support status and, where known, an end-of-support date for every SBOM component. Furthermore, this guidance mandates 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 also necessitates a clear understanding of component lifecycles to effectively manage cybersecurity risks throughout the product lifecycle.

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. Section 524B(b)(3) explicitly calls out end-of-support date as an SBOM field. If the column is blank, expect a question.

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 requires

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 (statutory)

Section 524B(b)(3) requires the SBOM to capture, for each component, the support status from the developer or maintainer and the end-of-support date where known. Missing or "unknown" entries without justification are a documented deficiency-letter trigger.

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 required architecture views

EOS components show up explicitly in two of the four required 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

CycloneDX 1.5+

CycloneDX has native lifecycle support. The two relevant blocks:

See also: FDA Section 524B Explained Subsection by Subsection: What Each Requirement Means in 2026, SBOM for Third-Party Chip Firmware in Medical Devices, and Does FDA Section 524B Apply to Legacy Devices?.

{
  "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" }
    ]
  }
}

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",
  "justification": "vulnerable_code_not_in_execute_path",
  "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."
}

Three things make this defensible: an explicit will_not_fix (not silence), a justification grounded in the architecture, and a pointer to the risk-management file entry that owns the residual risk.

Reviewer red flags

The Feb 2026 guidance has not changed what reviewers check on lifecycle - it has changed how strict they are about it. Common deficiency-letter triggers:

• 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.

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.

What is Level of Support (LoS)?

LoS is the tier of service a component is entitled to while still supported - typically mainstream, extended, or community. Two devices using the same library version can have very different risk profiles based on LoS. The SBOM should capture which tier applies today.

Does the FDA require an EOS date in the SBOM?

Yes, where known. Section 524B(b)(3) requires the SBOM to include the support status and end-of-support date for each component. Blank or "unknown" entries without justification are a documented deficiency trigger under the February 2026 premarket guidance.

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 1.5+ supports lifecycle natively via the lifecycles element, plus per-component pedigree notes and properties for status, EOS date, and support level. SPDX 2.3 requires structured annotations since the schema does not have first-class lifecycle fields. Prefer CycloneDX 1.5+ as the primary submission format.

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

Typically affected with will_not_fix and a justification tied to the architecture (e.g. vulnerable_code_not_in_execute_path or a documented compensating control). Avoid leaving EOS components in under_investigation long-term - reviewers read that as an unmanaged risk.

Where does this live in the four required architecture views?

Primarily in the Updateability and Patchability View (to show the broken patch path) and the Security Use Case View (to show the compensating controls). The Global System View and Multi-Patient Harm View inherit the consequences. All four are required under the February 3, 2026 premarket guidance.

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.

About the author

Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance. Read more about Christian.

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 ensure your premarket submissions meet FDA expectations, and if the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our specialized FDA premarket support at: https://www.bluegoatcyber.com/services/fda-premarket-cybersecurity-services