fda medical device sbom · cyclonedx vs spdx
FDA Medical Device SBOM: CycloneDX vs SPDX Submission Guide
November 11, 2026
30 min read
A 2026 guide to FDA medical device SBOM requirements under section 524B: CycloneDX vs SPDX, NTIA and CISA fields, a field-level crosswalk, VEX triage, CI quality gates and eSTAR packaging.
- 01Cyber devices require an SBOM, but the statute and FDA guidance leave format choice to the manufacturer. Document the engineering rationale for choosing CycloneDX or SPDX.
- 02Both formats carry core SBOM fields. CycloneDX integrates vulnerability analysis; SPDX offers strong embedded-build support and native end-of-support fields, with capabilities varying by version.
- 03FDA recommends component support level and end-of-support information alongside baseline SBOM fields. A written SBOM profile defines the properties and conventions needed for consistent submissions.
- 04Generator disagreement and completeness barriers support independent cross-checks of the final release image. A valid schema alone does not establish that an SBOM is complete.
- 05Generate, validate, sign and archive SBOMs through the build pipeline, refresh them whenever software changes, and connect them to device versions and risk documentation. VEX supports the vulnerability assessment.
Executive Summary
For a medical device that qualifies as a "cyber device," a software bill of materials (SBOM) is not optional. Section 524B(b)(3) of the Federal Food, Drug, and Cosmetic Act (FD&C Act) requires the sponsor to provide "a software bill of materials, including commercial, open-source, and off-the-shelf software components" ([1]). FDA's February 2026 final premarket cybersecurity guidance restates that an SBOM is required for cyber devices ([2]), and FDA says an electronic Submission Template And Resource (eSTAR) file goes on Technical Screening hold if its Cybersecurity section lacks accurate responses and relevant attachments ([3]). The guidance carries an issue date of February 3, 2026 (the PDF header date) ([4]), while FDA's cybersecurity page lists the revision under a February 2, 2026 entry; this article refers to the guidance simply as the February 2026 guidance ([5]).
The statute and the guidance do not choose a file format. The guidance recommends machine-readable SBOMs consistent with the National Telecommunications and Information Administration (NTIA) minimum elements, also called "baseline attributes" ([6]), and refers to "industry-accepted formats" ([7]). As of November 2026, the guidance text does not name SPDX (Software Package Data Exchange) or CycloneDX. The International Medical Device Regulators Forum (IMDRF) document N73 lists CycloneDX, SPDX and SWID (software identification tags) as prominent formats without ranking them ([8]), and the 2026 minimum elements from the Cybersecurity and Infrastructure Security Agency (CISA) name SPDX and CycloneDX as the two widely used formats ([9]). The format decision is an engineering decision, not a legal one.
The formats differ in ways that matter for devices. CycloneDX 1.7, standardized as ECMA-424 ([10]), carries vulnerability analysis in the same schema ([11]). SPDX 2.3 has a native field for the end of a supplier's support period ([12]), which maps to FDA's request for component support level and end-of-support date ([13]), and SPDX 3.0.1 adds a Security profile for Vulnerability Exploitability eXchange (VEX) statements ([14]). Neither format proves compliance, and FDA states that VEX does not replace the vulnerability assessment it recommends ([15]).
Data quality is the larger risk. A preprint comparing six generators on 3,287 repositories reported inter-tool consistency for package detection as low as 7.84% to 12.77% ([16]), and 62% of respondents to a 2026 European Union Agency for Cybersecurity (ENISA) survey named SBOM completeness a technical challenge ([17]). This report recommends one canonical format per device line, generation in the build, supplier merge with provenance, automated quality gates, signing, archiving, and a new SBOM for every software change, consistent with IMDRF N73 ([18]). It is analysis, not legal advice.
Low inter-tool package-detection consistency reported by a preprint comparing generators on open-source repositories
Respondents in the ENISA survey who named SBOM completeness a technical challenge
SBOMs evaluated in the preprint across six tools and open-source repositories, rather than medical-device firmware
Introduction and Background
A software bill of materials is a formal inventory of software components and dependencies, with their information and hierarchical relationships; FDA's guidance adopts this definition from NTIA ([19]). For product security teams the practical question is which representation to use, how to produce it reliably for every release, how to take supplier data in, how to package evidence for FDA, and how to keep the artifact accurate after the device ships.
This report serves product security, regulatory affairs and quality teams. Every factual statement is cited to a third-party regulator, standards body, project documentation or research source, and all dates are stated as of November 2026.
The report separates three layers that are often blurred: what the law requires, what FDA recommends in guidance, and what this report recommends as implementation practice.
Regulatory Basis: Law, Guidance and Recommendation
What section 524B requires
Section 524B was added by the Food and Drug Omnibus Reform Act (FDORA) and took effect 90 days after December 29, 2022 ([20]). A "cyber device" includes software validated, installed or authorized by the sponsor ([21]), has the ability to connect to the internet ([22]), and contains technological characteristics that could be vulnerable to cybersecurity threats ([23]).
For a cyber device the sponsor must run a postmarket plan that monitors, identifies and addresses vulnerabilities, including coordinated vulnerability disclosure ([24]); provide updates and patches for known unacceptable vulnerabilities on a reasonably justified regular cycle ([25]) and out of cycle for critical vulnerabilities that could cause uncontrolled risks ([26]); and provide the SBOM ([1]). The Secretary may exempt devices or categories of devices ([27]). None of these provisions names an SBOM format or enumerates SBOM fields.
Which submissions are covered
FDA's FAQ lists covered pathways including Product Development Protocol (PDP), De Novo and Humanitarian Device Exemption (HDE) requests ([28]), alongside 510(k) and premarket approval (PMA) submissions. The requirements do not apply to a submission made before March 29, 2023, but a new submission for a change to a previously authorized cyber device is in scope.
What the February 2026 guidance adds
The guidance applies to devices with cybersecurity considerations, including but not limited to devices with software, firmware or programmable logic ([29]); cyber devices are a subset. It was revised to align with the amendments to 21 CFR Part 820, the Quality Management System Regulation (QMSR) ([30]), and supersedes the version issued June 27, 2025 ([31]). Teams should compare the 2025 and 2026 texts themselves to identify what changed.
The guidance distinguishes what is required from what is recommended. The SBOM is required by statute for cyber devices, and Section VII.C.3 recommends that it contain the information described in Section V.A.4.b ([32]). The existence of an SBOM is therefore a statutory matter, while field content and format are matters of FDA recommendation that reviewers assess for adequacy.
Table 1 summarizes the layers so that teams label each requirement correctly in design history documentation.
| Layer | Source | What it says about SBOMs | Status |
|---|---|---|---|
| Statute | FD&C Act 524B(b)(3) | Provide an SBOM including commercial, open-source and off-the-shelf components | Binding for cyber devices |
| FDA guidance | Premarket cybersecurity guidance, Section V.A.4 | Machine-readable, NTIA-consistent, plus level of support and end-of-support date ([13]) | Recommendation; adequacy reviewed |
| FDA FAQ | Cybersecurity FAQ | Technical Screening hold if the eSTAR Cybersecurity section lacks accurate responses and attachments ([33]) | Describes FDA process |
| International principles | IMDRF N73 | Baseline elements follow NTIA; formats named without ranking ([34]) | Non-binding principles |
| Implementation | This report | Single canonical format, continuous integration (CI) generation, quality gates | Analyst recommendation |
No binding layer prescribes CycloneDX or SPDX. Teams should document the format choice as a design decision with a rationale and should not describe either format as FDA-required or FDA-endorsed in submission text.
What FDA and IMDRF Expect in and around an SBOM
FDA Section V.A.4
FDA describes a robust SBOM as covering manufacturer-developed and third-party components with their upstream dependencies ([35]). The SBOM should be part of configuration management and be regularly updated to reflect software changes in marketed devices ([36]). Section V.A.4(b) recommends two attributes beyond the NTIA elements for each component: the level of support from the component manufacturer ([37]) and the component end-of-support date. If a manufacturer cannot provide SBOM information, FDA recommends a justification in the submission ([38]).
The SBOM sits inside a connected body of evidence. The security risk management report should include the SBOM, component support information and vulnerability assessments ([39]), with traceability among the threat model, risk assessment, SBOM and testing documentation ([40]). FDA asks for identification of known vulnerabilities, including those in the CISA Known Exploited Vulnerabilities (KEV) catalog ([41]), and a safety and security risk assessment of each ([42]). Labeling should make machine-readable SBOM information available to users, and manufacturers should plan for updating or replacing third-party software whose support ends ([43]).
IMDRF N73 principles
IMDRF published N73, "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity," as a final document in April 2023 ([44]). It recommends that a baseline SBOM follow NTIA ([34]), defines the author element as the entity that produced the SBOM file ([45]), and recommends a component hash ([46]). It treats the end-of-support date as supplemental lifecycle information ([47]) and recommends mapping device SBOMs to a unique device identifier so an SBOM matches the right device and version ([48]). It sets the change rule that drives operations: any event that causes the device software to change should result in a new SBOM ([18]). It also notes that an SBOM does not explicitly state whether a component has a vulnerability ([49]).
NTIA 2021 and CISA 2026 minimum elements
NTIA's 2021 minimum elements define seven data fields, including other unique identifiers, dependency relationship and author of SBOM data ([50]), and name SPDX, CycloneDX and SWID tags as formats ([51]). NTIA also requires authors to identify "known unknowns" where the dependency graph is incomplete ([52]).
The broader U.S. baseline has moved. CISA opened comment on an updated draft in August 2025 ([53]), and the final 2026 Minimum Elements, published July 29, 2026, update and replace the NTIA elements ([54]). The final adds requirements for component hash, license, SBOM tool name and SBOM generation context ([55]), renames the supplier concept "component producer" because of ambiguity around distributors ([56]), and says each software version or update should have an associated SBOM ([57]).
FDA's current text still cites the NTIA baseline, and the 2026 CISA fields are not presented there as a requirement. Treating the CISA additions as a superset is an analyst inference, not an FDA position.
CycloneDX: Capabilities, Adoption, Strengths and Limitations
Capabilities
CycloneDX is an OWASP (Open Worldwide Application Security Project) full-stack bill of materials standard ([58]). Version 1.7 was announced on October 21, 2025 ([59]), and ECMA-424 now defines v1.7, following ratification of v1.6 in June 2024 ([60]). It can represent software, hardware devices, machine learning models, source code and configurations ([61]). As of November 2026, the CycloneDX Tool Center listed 337 tools ([62]). Serializations are JSON, XML and Protocol Buffers ([63]), and the JSON Schema is the reference implementation ([64]).
Several native constructs matter for devices. A hardware device containing firmware should include a component for the physical hardware itself ([65]). The dependency graph represents direct and transitive relationships ([66]). Compositions carry a completeness aggregate ([67]). Metadata lifecycles record when data was captured ([68]), including post-build for information obtained after a build completes ([69]). Component identity can use package URLs (purl) ([70]).
Adoption
ENISA's 2026 survey of 334 respondents, mostly European organizations ([71]), found 44% using CycloneDX and 29% using SPDX ([72]), with 17% still on a proprietary format ([73]). These are respondent usage shares, not market share, and the survey is not specific to medical devices. A preprint comparing 108 open-source and 62 proprietary tools advertised for SPDX and CycloneDX ([74]) reported that CycloneDX projects show higher developer engagement and certain community-health metrics ([75]).
Strengths and limitations
Documented strengths include native vulnerability analysis states and justifications ([76]), BOM-Link for connecting separate BOM and VEX documents ([77]), enveloped signing ([78]), and name-value properties as an extension mechanism ([79]).
Limitations are practical. CycloneDX publishes a property taxonomy that defines cdx:lifecycle:milestone:endOfSupport for the end-of-support date. It defines no support-level property, so teams would document FDA's level-of-support attribute as a custom property under an agreed naming convention (analyst assessment). Mapping documents should be checked against the schema version in use, because field names change between releases.
“The most defensible approach is a written SBOM profile: a short, version-controlled specification of the fields, properties and naming conventions every SBOM in the product line will contain.
SPDX: Capabilities, Adoption, Strengths and Limitations
Capabilities
SPDX is an open source project hosted by the Linux Foundation ([80]), and is described as an international open standard, ISO/IEC 5962:2021 ([81]); that edition corresponds to SPDX 2.2.1 ([82]), which predates 2.3. The 2.3.1 text states that the latest edition is 3.0.1, from December 2024 ([83]), and that 2.3.1 adds no new fields ([84]). A 3.1 release candidate existed but no general availability release was found when checked ([85]).
SPDX 2.x supports several serializations and requires interoperability among them ([86]). SPDX 3.0.1 is RDF-based ([87]), and conformance involves structural plus semantic validation ([88]). It defines nine profiles, of which only Core is mandatory ([89]).
Device-relevant SPDX 2.3 fields include a package supplier that must be an organization or recognized author and not a website ([90]), checksums for unique identification ([91]), and a primary purpose value for firmware ([92]). The 2.3 valid-until date records the end of the supplier's support period ([12]). In 3.0.1 the equivalent is validUntilTime ([93]) with a support-level vocabulary that includes endOfSupport ([94]), and deviceDriver joins the purpose vocabulary ([95]).
Adoption
SPDX is widely used in embedded builds. The Yocto Project's OpenEmbedded build system generates SPDX SBOM information by default ([96]), Zephyr's SBOM command defaults to SPDX 2.3 and flags SPDX 3.1 support as experimental ([97]) ([98]), and Microsoft's sbom-tool defaults to SPDX 2.2 for generation ([99]).
Strengths and limitations
Strengths include the ISO lineage of the 2.2.1 edition, native license and checksum fields, a mature relationship model such as DEPENDS_ON ([100]), SPDX-lite described as satisfying NTIA minimum SBOM element requirements ([101]), and an NTIA mapping in the 2.3.1 text stating the format contains fields able to address each NTIA minimum element ([102]). The same text says it addresses only some of the 2026 CISA fields ([103]) and has no field for the SBOM author signature ([104]), so signatures must be carried externally. SPDX 3.0.1 adds relationship completeness values ([105]) and SBOM type values for generation context ([106]).
Tool support is split across versions. An SBOM aggregation tool may support only an older release, as sbom-tool's aggregation does ([107]), and the SPDX NTIA conformance checker advertises versions 2.2, 2.3 and 3.0 ([108]). Teams choosing SPDX 3.0.1 should confirm that downstream consumers read it.
Feature Comparison and Field-Level Crosswalk
- Native vulnerability analysis states and justifications support integrated VEX workflows.
- FDA support-level data needs a custom property under an agreed naming convention.
- Polyglot application stacks and integrated VEX offer a natural CycloneDX path.
- SPDX 2.3 has a native valid-until date for the end of the supplier's support period.
- SPDX 3.0.1 offers a Security profile; SPDX 2.3 relies on external references for VEX.
- Yocto or Zephyr builds and a need for an ISO-lineage artifact offer a natural SPDX path.
Neither format proves compliance. Keep one canonical format and test conversions for field loss; confirm that downstream tools support the chosen specification version.
Decision matrix
Table 2 compares the representations on criteria that usually decide a device program's choice. Where a capability was not found in the reviewed sections, the cell says so.
| Criterion | CycloneDX 1.7 | SPDX 2.3.1 / 3.0.1 |
|---|---|---|
| Standardization | ECMA-424 defines v1.7 | ISO/IEC 5962:2021 is the 2.2.1 edition; 3.0.1 is the latest edition |
| Serialization | JSON, XML, protobuf | 2.x multiple formats; 3.0.1 JSON-LD and RDF forms |
| Firmware and hardware | Firmware and device component types | FIRMWARE and DEVICE purposes in 2.3; deviceDriver added in 3.0.1 |
| Completeness assertion | Composition aggregate values | Relationship completeness in 3.0.1 |
| End-of-support data | No dedicated schema field; cdx:lifecycle:milestone:endOfSupport in the property taxonomy; support level as a custom property | validUntilDate in 2.3; supportLevel and validUntilTime in 3.0.1 |
| VEX in same schema | Native analysis states | 3.0.1 Security profile; 2.3 relies on external references ([109]) |
| Signing | JSON Signature Format (JSF) and XML signature options | No SBOM author signature field in 2.3.1 |
| Generators and embedded builds | Polyglot generator and CLI ecosystem ([110]) | Yocto and Zephyr SPDX generation |
| Conversion | CLI converts among CycloneDX serializations and SPDX JSON 2.3 ([111]) | Conversion possible; field loss must be tested |
The matrix suggests a decision rule, not a winner. Programs that build with Yocto or Zephyr, or need an ISO-lineage artifact, have a natural SPDX path; programs with polyglot application stacks and integrated VEX have a natural CycloneDX path. Many manufacturers will keep one canonical format for the submission and convert for customers who request the other.
Field-level crosswalk
Table 3 maps each FDA, IMDRF and CISA expectation to fields in both formats. The status column is an analyst assessment of whether the field is native, needs an extension or property, or belongs in a supporting document submitted next to the SBOM.
| Expectation (source) | CycloneDX 1.7 field | SPDX field | Status |
|---|---|---|---|
| SBOM author (NTIA, IMDRF) | metadata.authors | creationInfo.creators ([112]) | Native in both |
| Timestamp (NTIA) | metadata.timestamp | created ([113]) | Native in both |
| Supplier or producer (CISA 2026) | components[].supplier | supplier | Native in both |
| Name and version (NTIA) | components[].name, version | name, versionInfo (optional in 2.3 ([114])) | Native in both |
| Unique identifier (IMDRF) | purl, cpe, bom-ref | externalRefs; packageUrl in 3.0.1 ([115]) | Native in both |
| Dependency relationship | dependencies[] | DEPENDS_ON | Native in both |
| Component hash (IMDRF, CISA 2026) | hashes[] | checksums | Native in both |
| License (CISA 2026) ([116]) | licenses[] | licenseConcluded, licenseDeclared ([117]) | Native in both |
| Generation context (CISA 2026) ([118]) | metadata.lifecycles | sbomType in 3.0.1; creator comment in 2.3 | Native in CycloneDX and 3.0.1; partial in 2.3 |
| Tool name and version | metadata.tools | Tool creator entry | Native in both |
| SBOM signature | JSON Signature Format | None in 2.3.1 | Native in CycloneDX; external for SPDX 2.3 |
| Level of support (FDA) | Property extension | supportLevel in 3.0.1 | Extension in CycloneDX and 2.3 |
| End-of-support date (FDA) | Property, taxonomy-defined (cdx:lifecycle:milestone:endOfSupport) | validUntilDate | Native in SPDX; taxonomy-defined property in CycloneDX |
| Known vulnerabilities and assessment (FDA) | vulnerabilities[] analysis | Security profile | Native in CycloneDX and 3.0.1; supporting document for 2.3 |
| KEV status (FDA) | Triage record or property | ExploitCatalog relationship ([119]) | Native in 3.0.1; supporting record otherwise |
| Device identifier mapping (IMDRF) | Property on metadata.component | externalRef or externalIdentifier | Extension |
| Justification when data is unavailable (FDA) | Supporting document | Supporting document | Supporting document |
| Traceability to threat model (FDA) | Supporting document | Supporting document | Supporting document |
The core NTIA and CISA fields are native in both formats. FDA's two support attributes and IMDRF's device identifier mapping are where either format needs a convention. The most defensible approach is a written SBOM profile: a short, version-controlled specification of the fields, properties and naming conventions every SBOM in the product line will contain.
Pipeline Architecture: From Build to eSTAR
This pattern is derived from the cited sources and is not an FDA-prescribed process.
Generate, normalize and merge
- Build and generate. Produce an SBOM at build time from lockfiles, the build graph and image contents; software composition analysis tools can generate an SBOM ([120]). Yocto builds emit SPDX information by default, and general-purpose scanners such as Trivy document both CycloneDX and SPDX output ([121]).
- Normalize. Convert to the canonical format and normalize names, versions and supplier strings. FDA's FAQ describes the advantages of standard nomenclature and formats for consistent data ([122]).
- Add post-build evidence. Scan the final image to catch components that manifests miss and record the generation context.
- Collect supplier SBOMs for purchased modules and third-party libraries. The Health Sector Coordinating Council's joint security plan recommends that suppliers provide an updated SBOM for every release ([123]) and includes sample contract language to maintain an SBOM for all product versions ([124]).
- Merge with provenance. Preserve which statements came from the supplier and which from your own scan. BOM-Link can reference another BOM's components, and the CycloneDX command-line tool lists merging among its functions ([125]).
- Record unresolved components explicitly. NTIA's "known unknowns" practice maps to CycloneDX completeness aggregates.
Quality gates
- Schema validation. Reject any SBOM that fails its schema. The CycloneDX command-line tool returns a non-zero exit code on invalid BOMs ([126]), and the SPDX Python tools validate against v2.2 and v2.3 ([127]).
- Minimum-element conformance. The SPDX NTIA conformance checker validates against NTIA, CISA and other minimum element requirements ([128]).
- Completeness, age and support-status checks. Apply the metrics defined in the Data Analysis section, and fail the build if a component lacks a support level or end-of-support entry.
Sign, archive and hand off to eSTAR
- Sign. CycloneDX supports enveloped signing, Syft can create signed in-toto attestations ([129]), and Sigstore's Cosign signs attestation payloads using the Dead Simple Signing Envelope (DSSE) specification ([130]). Sigstore documentation notes that SBOM predicate types are not recommended ([131]), and suggests attesting a pointer plus a hash instead. A software attestation is an authenticated statement about software artifacts ([132]).
- Archive. Store the SBOM, build identifier, source revision, generator version and validation report in the design history file.
- Attach. The 510(k) eSTAR guidance lists a Cybersecurity/Interoperability section for applicable assessment information ([133]), and eSTAR is mandatory for 510(k) and De Novo submissions to the Center for Devices and Radiological Health (CDRH) or the Center for Biologics Evaluation and Research (CBER) unless exempted ([134]).
- Package. Include the SBOM in the canonical format, the supporting documents from Table 3, and the traceability evidence. FDA lists SBOM, vulnerability assessment and software support documentation among its premarket considerations.
- Confirm the template. Exact eSTAR question wording and attachment slots change with template versions, so confirm them against the current template.
Produce the SBOM at build time from lockfiles, the build graph and image contents.
Convert to the canonical format and normalize component names, versions and supplier strings.
Catch components that manifests miss and record when the SBOM data was captured.
Preserve which component statements came from suppliers and which came from the internal scan.
Check schema, minimum elements, completeness, age and support data; fail the build when component support entries are missing.
Sign and archive the SBOM and validation report, then package the canonical SBOM, supporting documents and traceability evidence for eSTAR.
Reject any SBOM that fails its schema or lacks a component support level or end-of-support entry.
VEX and Vulnerability Triage
Why an SBOM alone is not exploitability analysis
An SBOM states what is in the device, not whether a component is vulnerable ([49]), and not whether a vulnerability is exploitable in the device's configuration. CISA describes VEX as indicating the status of a software product or component with respect to a vulnerability ([135]), and IMDRF defines it as a machine-readable assertion about the status of a vulnerability in specific products ([136]). FDA is explicit that VEX does not provide sufficient information on its own to replace the recommended vulnerability assessment ([15]).
VEX formats
CISA's minimum requirements identify CSAF, CycloneDX and OpenVEX as formats that can carry VEX ([137]), and note that CSAF and CycloneDX carry information beyond VEX requirements ([138]). OpenVEX describes itself as lightweight and embeddable while meeting the CISA requirements ([139]). The OASIS Common Security Advisory Framework (CSAF) version 2.1 defines a VEX profile ([140]) but was still a committee specification draft on October 21, 2026 ([141]). CycloneDX treats VEX as a subset of its vulnerability disclosure content ([142]) and recommends decoupling VEX from the SBOM so it can change without reissuing the BOM ([143]). SPDX 3.0.1 expresses not-affected through a relationship restricted to the doesNotAffect type ([14]). The CISA document is not official CISA policy ([144]). For a manufacturer, VEX is a communication layer on top of the internal vulnerability assessment, not a replacement for it.
Triage workflow
- Match components to vulnerability data using purl and CPE identifiers.
- Prioritize with exploitation signals. CISA advises using the KEV catalog as an input to prioritization ([145]); it showed 1,779 entries as of November 2026 ([146]). The Exploit Prediction Scoring System (EPSS) estimates the probability that a published vulnerability will be exploited in the wild in the next 30 days ([147]), and a score of 0.05 corresponds to a 5% empirical rate ([148]).
- Assess device-specific exploitability and patient-safety impact. A 2,414-repository study found that downstream vulnerability scanners produced a very high false-positive rate in its case study ([149]), and that function call analysis pruned 61.9% of those false alarms ([150]).
- Decide status and justification. CISA lists justification values for not-affected status ([151]), treats them as assertions a consumer may accept or reject ([152]), and requires a justification or impact statement ([153]). OpenVEX discourages free-text impact statements because they break automation ([154]).
- Classify risk as controlled or uncontrolled using FDA's postmarket definition of uncontrolled risk ([155]), then route to patch, compensating control or customer notification.
Lifecycle Management and Change Control
Versioning and postmarket duties
Three sources align on the core rule: IMDRF N73 says any change to device software should result in a new SBOM, the 2026 CISA elements say each version or update should have an associated SBOM, and FDA says the SBOM should be regularly updated to reflect software changes in marketed devices.
FDA's postmarket guidance, issued December 28, 2016 ([156]), recommends monitoring third-party software components for new vulnerabilities throughout the lifecycle ([157]). As of November 2026, confirm on FDA's cybersecurity page whether a later version has replaced it. The guidance also sets conditions for its enforcement-discretion path on uncontrolled risks; read the guidance text itself, and do not treat any timeline as removing reporting obligations under 21 CFR Part 806. The Health Information Sharing and Analysis Center (Health-ISAC) describes machine-readable, standardized SBOMs as enabling automated analysis and integration into cybersecurity workflows ([158]). FDA recommends submitting the cybersecurity management plan, including its patch timeline, with the premarket submission ([159]).
Change-impact matrix
Table 4 shows a change-impact flow using hypothetical components. It illustrates the data a product security team must join: component, vulnerability, affected device versions, submissions and field units, and decision.
| Trigger | Vulnerability and status | Device versions affected | Submissions and field units | Decision path |
|---|---|---|---|---|
| Library "examplelib" 1.4.2 to 1.4.3 (Hypothetical Example) | New advisory lists 1.4.2 as affected; KEV status checked | Firmware 3.2.0 and 3.2.1 in the SBOM archive | Cleared submissions and field units by serial range from the device identifier mapping | Assess exploitability, classify controlled or uncontrolled, patch on cycle or out of cycle |
| Component reaches end of support (Hypothetical Example) | Supplier issues no new advisories | All versions containing the component | Labeling should disclose end-of-support information | Replace the component or document the pre-established transition process |
| Supplier replaces a proprietary module (Hypothetical Example) | Supplier SBOM changes the component list | Next release only | Change assessment decides whether a new submission is needed | New SBOM; supplier SBOM refreshed |
The matrix is useful only if the SBOM archive can answer "which shipped versions contain component X at version Y" in seconds. That requires indexing every archived SBOM by device version and unique device identifier in a monitoring platform. Dependency-Track, for example, documents consuming and producing CycloneDX VEX ([160]) and re-analyzing its portfolio on a schedule ([161]). The platform choice is the manufacturer's; the join is the requirement. FDA defines end of support as the point beyond which the manufacturer ceases to provide support ([162]), so component end-of-support dates should be reviewed at every release.
Performance and Benchmarks: What the Evidence Shows About SBOM Quality
Published measurements describe open-source repositories rather than medical-device firmware, so they indicate direction, not device-specific performance. A 2026 preprint evaluating 55,444 SBOMs from six tools across 3,287 repositories ([163]) reported inter-tool consistency for package detection as low as 7.84% to 12.77% ([16]). A study of 2,414 repositories ([164]) reported the scanner false-positive finding above.
Two design conclusions follow. A single generator's output should not be treated as ground truth, so an independent cross-check, such as a binary scan of the final image, should reconcile against the build-time SBOM. And identifier-based vulnerability matching produces candidates that need device-specific assessment. No public benchmark measures SBOM accuracy specifically for medical-device firmware.
Data Analysis and Evidence
Adoption and barrier statistics
The Linux Foundation's 2022 research surveyed 412 organizations with a 65-question instrument ([165]); 47% were producing or consuming SBOMs ([166]) and 78% expected to do so in 2022 ([167]). ENISA's 2026 survey found 78% had initiated SBOM adoption ([168]). The surveys differ in date, geography and sampling and should not be read as a trend line.
Vulnerability data volume is growing: as of November 2026, CVE.org's metrics page reported about 29,000 published Common Vulnerabilities and Exposures (CVE) records for 2023 ([169]) and about 48,000 for 2025 ([170]), an increase of about 67% computed from the two figures (exact counts vary slightly with snapshot date and counting basis).
Proposed SBOM completeness metrics
These formulas are analyst constructs for use as pipeline gates. The thresholds are examples each manufacturer should set and justify; none is an FDA requirement.
- Identification coverage = identified components in the SBOM / components discovered by an independent scan of the release artifact. Example gate: 95% or higher, with every gap listed.
- Version completeness = components with a version / components in the SBOM. Example gate: 100% for third-party components.
- Hash completeness = components with a hash / components in the SBOM. N73 recommends hashes and the 2026 CISA elements add them ([55]).
- Unresolved supplier components = components with unknown supplier or producer / components in the SBOM. Example gate: zero without a documented justification.
- Support-data completeness = components with a support level and end-of-support entry / components in the SBOM, derived from FDA's two additional attributes.
- Stale-SBOM age = days between the SBOM timestamp and the evaluation date. Example gate: regenerate at every release and re-triage on a defined cycle.
Case Studies and Real-World Examples
Synthetic Infusion Gateway Firmware (Hypothetical Example)
This example is entirely synthetic. "Example Medical Devices Inc.," the gateway firmware and every component, number and date are invented, and no real product, supplier or secret is represented. The JSON below was hand-written for this report and was not run through a schema validator or conformance tool; teams should validate any adopted example with the tools above and should not infer that it demonstrates compliance.
Scenario. Gateway firmware 3.2.1 is built on October 2, 2026. A post-build scan discovers 412 components, and the build-time SBOM identifies 398.
| Metric | Calculation | Result |
|---|---|---|
| Identification coverage | 398 / 412 | 96.6% |
| Version completeness | 392 / 398 | 98.5% |
| Hash completeness | 380 / 398 | 95.5% |
| Unresolved supplier components | 9 / 398 | 2.3% |
| Stale-SBOM age on November 11, 2026 | October 2 to November 11 | 40 days |
Against example gates of 95% identification, 100% version completeness and zero unresolved suppliers, the build would fail on version completeness (6 components without a version) and on 9 unresolved suppliers. The team would fix them or document each justification before the eSTAR handoff.
CycloneDX 1.7 sketch (abridged).
{
"bomFormat": "CycloneDX",
"specVersion": "1.7",
"serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
"version": 1,
"metadata": {
"timestamp": "2026-10-02T14:05:00Z",
"lifecycles": [{ "phase": "post-build" }],
"authors": [{ "name": "Example Product Security Team" }],
"component": {
"type": "firmware", "bom-ref": "fw-gateway", "name": "example-gateway-fw", "version": "3.2.1",
"manufacturer": { "name": "Example Medical Devices Inc." }
}
},
"components": [{
"type": "library", "bom-ref": "lib-examplelib", "name": "examplelib", "version": "1.4.2",
"supplier": { "name": "Example Library Project" },
"purl": "pkg:generic/[email protected]",
"hashes": [{ "alg": "SHA-256", "content": "a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90" }],
"licenses": [{ "license": { "id": "MIT" } }],
"properties": [
{ "name": "example:support-level", "value": "actively-maintained" },
{ "name": "cdx:lifecycle:milestone:endOfSupport", "value": "2028-06-30" }
]
}],
"dependencies": [
{ "ref": "fw-gateway", "dependsOn": ["lib-examplelib"] },
{ "ref": "lib-examplelib", "dependsOn": [] }
],
"compositions": [{ "aggregate": "incomplete", "assemblies": ["fw-gateway"] }]
}
SPDX 2.3 sketch (abridged).
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "example-gateway-fw-3.2.1-sbom",
"documentNamespace": "https://sbom.example.com/spdx/example-gateway-fw/3.2.1/0001",
"creationInfo": {
"created": "2026-10-02T14:05:00Z",
"creators": ["Tool: example-sbom-generator-1.0.0", "Organization: Example Medical Devices Inc."],
"comment": "Generation context: post-build"
},
"packages": [
{ "SPDXID": "SPDXRef-Firmware", "name": "example-gateway-fw", "versionInfo": "3.2.1",
"supplier": "Organization: Example Medical Devices Inc.", "downloadLocation": "NOASSERTION",
"filesAnalyzed": false, "primaryPackagePurpose": "FIRMWARE" },
{ "SPDXID": "SPDXRef-examplelib", "name": "examplelib", "versionInfo": "1.4.2",
"supplier": "Organization: Example Library Project", "downloadLocation": "NOASSERTION",
"filesAnalyzed": false, "primaryPackagePurpose": "LIBRARY",
"checksums": [{ "algorithm": "SHA256", "checksumValue": "a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90" }],
"licenseConcluded": "MIT", "licenseDeclared": "MIT", "validUntilDate": "2028-06-30T00:00:00Z",
"externalRefs": [{ "referenceCategory": "PACKAGE-MANAGER", "referenceType": "purl", "referenceLocator": "pkg:generic/[email protected]" }] }
],
"relationships": [
{ "spdxElementId": "SPDXRef-DOCUMENT", "relationshipType": "DESCRIBES", "relatedSpdxElement": "SPDXRef-Firmware" },
{ "spdxElementId": "SPDXRef-Firmware", "relationshipType": "DEPENDS_ON", "relatedSpdxElement": "SPDXRef-examplelib" }
]
}
Validation tests to automate before the eSTAR handoff:
- Schema test: validate against the schema for the declared version, using the CycloneDX validator or the SPDX Python tools.
- Round-trip test: convert to the second format and diff name, version, supplier, hash and relationship counts. The CycloneDX command-line tool converts among CycloneDX serializations and SPDX JSON 2.3; record any field loss.
- Minimum-element test: run the conformance checker for NTIA and CISA elements ([128]).
- Extension test: assert that support-level and end-of-support properties exist for every third-party component.
- Join test: confirm the SBOM resolves to a device version and unique device identifier.
Implications and Future Directions
Format convergence is incomplete but narrowing. CISA's 2026 elements emphasize machine-processable formats ([171]), and the multinational Shared Vision guidance says an SBOM should be machine-processable in a widely used format ([172]) while warning that divergent implementations could hinder adoption ([173]). CISA's earlier sharing report found that no single sharing solution had become ubiquitous ([174]), so manufacturers should expect to publish in more than one format.
Specification churn. CycloneDX 1.7 is current, SPDX 3.0.1 is the latest SPDX edition, and SPDX 3.1 had not reached general availability as of November 2026. Pin the specification version in the SBOM profile, test upgrades on a branch, and record the version in the design history file, since tools may support only some versions.
Quality-system alignment. FDA describes a Secure Product Development Framework (SPDF) as one approach to help ensure the QMSR is met ([175]); embedding SBOM gates there, with supplier contract terms for per-release SBOMs ([124]), gives reviewers one process to examine.
Regulatory questions. None of the cited sources prescribes a format, so device-specific regulatory questions belong with qualified regulatory counsel and FDA's Q-Submission process.
Frequently Asked Questions (FAQs)
Does FDA require CycloneDX or SPDX?
None of the cited sources names either format as required. The statute requires an SBOM for cyber devices, the guidance recommends NTIA-consistent, machine-readable SBOMs ([6]), and IMDRF N73 lists both formats without ranking them ([176]).
What are the FDA SBOM requirements for medical devices?
For cyber devices, provide an SBOM covering commercial, open-source and off-the-shelf components. The guidance recommends the Section V.A.4.b content: NTIA-consistent fields plus support level and end-of-support date.
Which SBOM format should be used in a premarket submission?
Choose one canonical format, document the rationale and validate it. Yocto programs may favor SPDX; programs wanting integrated vulnerability analysis may favor CycloneDX ([11]).
How does section 524B relate to the cybersecurity guidance?
Section 524B is the statute governing postmarket plans, patching and the SBOM ([24]). The guidance contains FDA's recommendations on meeting and documenting them.
What happens if the eSTAR cybersecurity section is incomplete?
FDA says the eSTAR will be put on a Technical Screening hold.
What are the NTIA minimum elements, and are they current?
NTIA's 2021 document defines seven data fields ([50]). CISA's July 2026 Minimum Elements update and replace them ([54]), while FDA's guidance still refers to NTIA baseline attributes.
What SBOM best practices apply, and how are SBOMs managed after release?
Generate in the build, merge supplier SBOMs with provenance, validate, sign, archive, and refresh with each release. Trace the SBOM to the risk file, monitor third-party components for new vulnerabilities, and plan for end of support.
What is VEX, and is it required?
VEX is a machine-readable statement of a vulnerability's status for a product ([135]). The guidance text reviewed did not mention it, and FDA states VEX alone does not replace the vulnerability assessment.
Conclusion
The February 2026 FDA guidance and section 524B together make an SBOM a statutory element of a cyber-device submission while leaving format choice to the manufacturer. The decisive work lies in the surrounding system: a documented SBOM profile covering the NTIA and CISA fields and FDA's two support attributes, a build pipeline that generates and validates SBOMs, supplier terms that deliver machine-readable inputs, a vulnerability and VEX workflow that supports the risk assessment, and change control that issues a new SBOM whenever the software changes.
CycloneDX and SPDX can both carry the core fields. CycloneDX offers integrated vulnerability analysis and signing options, and SPDX offers an ISO-lineage edition, strong embedded-build support and native end-of-support fields. The evidence on tool disagreement and completeness barriers argues for measurement and cross-checking over reliance on any single generator. Teams should verify current guidance, the eSTAR template and specification versions at the time of submission, and consult regulatory counsel and FDA for device-specific questions.
About IntuitionLabs
Build practical AI for pharma and biotech with IntuitionLabs. We help life-science teams turn complex information and workflows into useful software, governed knowledge systems and AI tools.
IntuitionLabs is an AI consulting, custom software development and data engineering firm serving pharmaceutical, biotechnology, medical-device and other life-science organizations. We work with clinical, regulatory, medical-affairs, commercial, quality and IT teams to connect technology decisions with the work people need to accomplish.
AI consulting and adoption
Our AI enablement services cover readiness assessments, use-case selection, governance and policies, team workshops, adoption measurement and ongoing advisory support. We help organizations structure the information layer behind AI: source material, context, permissions and maintained knowledge that make generated answers useful and reviewable. Private LLM inference and hosted AI options support teams evaluating how to operate AI with appropriate control over their data and infrastructure.
Software, data and life-science workflows
IntuitionLabs develops custom software for pharma and biotech, integrates enterprise systems, and builds data engineering and business intelligence solutions. Areas of focus include AI agents, regulatory research, medical writing, medical affairs, CMC information, competitive intelligence and clinical-document workflows. Our eTMF intelligence work includes cross-system reconciliation and inspection-readiness support.
Enterprise platforms and regulated delivery
We provide Veeva services, application support, managed services, integrations and custom applications, alongside enterprise content work involving platforms such as Egnyte. For regulated workflows, our services include GxP enablement, computer-system validation and software development addressing 21 CFR Part 11 requirements. The applicable controls, validation responsibilities and acceptance criteria are defined for each engagement.
Work with IntuitionLabs
Explore AI enablement, pharma and biotech software development, data engineering and BI, and Veeva services. Contact IntuitionLabs to discuss your workflow, information sources and implementation needs.
IntuitionLabs publishes educational research to help life-science teams make informed technology decisions. Coverage of a product or organization does not imply a client relationship, endorsement or partnership.
Sources / 176
Need Expert Guidance on This Topic?
Let's discuss how IntuitionLabs can help you navigate the challenges covered in this article.
I'm Adrien Laurent, Founder & CEO of IntuitionLabs. With 25+ years of experience in enterprise software development, I specialize in creating custom AI solutions for the pharmaceutical and life science industries.
The information contained in this document is provided for educational and informational purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the information contained herein. Any reliance you place on such information is strictly at your own risk. In no event will IntuitionLabs.ai or its representatives be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from the use of information presented in this document. This document may contain content generated with the assistance of artificial intelligence technologies. AI-generated content may contain errors, omissions, or inaccuracies. Readers are advised to independently verify any critical information before acting upon it. All product names, logos, brands, trademarks, and registered trademarks mentioned in this document are the property of their respective owners. All company, product, and service names used in this document are for identification purposes only. Use of these names, logos, trademarks, and brands does not imply endorsement by the respective trademark holders. IntuitionLabs.ai is an AI software development company specializing in helping life-science companies implement and leverage artificial intelligence solutions. Founded in 2023 by Adrien Laurent and based in San Jose, California. This document does not constitute professional or legal advice. For specific guidance related to your business needs, please consult with appropriate qualified professionals.
Related Articles
IEC 81001-5-1 Implementation: An Evidence Crosswalk
A 2026 implementation guide mapping IEC 81001-5-1 activities to owners and evidence, with December 2025 corrections, IEC 62304 overlap, FDA submission mapping and lifecycle coverage calculations.
AI Medical Device Cybersecurity: Regulations & Risks
Learn cybersecurity requirements for AI medical devices. Covers FDA guidance, EU regulations, SBOM mandates, and defenses against adversarial AI attacks.