SBOM End-of-Support, EOL, and Level of Support: What the FDA Expects

Last updated: June 2026

Most medical device SBOMs treat lifecycle as a footnote. Under the Feb 3, 2026 final guidance and Section 524B of the FD&C Act, it is now a first-class submission field - and a frequent source of cybersecurity deficiency letters.

This post defines the three terms in the way reviewers use them, shows how to express the data in CycloneDX 1.5+ and SPDX 2.3, walks the decision tree when a component goes EOS mid-lifecycle, and shows the canonical VEX shape for an unsupported component.

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.

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:

{
  "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.

Frequently Asked Questions

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.