CISA's 2026 SBOM minimum elements: when they'll reach your medical device.

At the end of July, CISA published the 2026 Minimum Elements for a Software Bill of Materials, replacing the 2021 NTIA minimum elements reference by FDA Cybersecurity guidance since 2023.

If you're mid-submission, nothing about your FDA documentation needs to change today. The current premarket cybersecurity guidance still points at the 2021 NTIA material, and the CISA document itself is explicit that it creates no new legal requirements. So the useful question isn't "what's in" the new guidance but "when does it start affecting me?".

When this reaches your submission

I'd expect the next revision of the FDA's premarket cybersecurity guidance to reference the 2026 CISA document, just as the current version references the NTIA 2021 guidance.

That won't happen immediately. But I do expect FDA reviewers to start comparing submitted SBOMs against the 2026 minimums within the next twelve months, probably well before updated guidance is published. When a reviewer deems it relevant, they can request additional information (AINN) during a review, before guidance revisions are published. And reviewers aren't the only route; US hospitals have been popular adopters of SBOMs from manufacturer teams, and security questionnaires tend to adopt this kind of baseline faster than regulators do.

The biggest change is already required by the FDA

For non-medical software teams, the headline change is coverage: the old guidance didn’t require transitive dependencies (the dependencies of your dependencies), but the new one expects the full dependency tree, including transitive dependencies, with no maximum depth.

For medical devices, that's a non-event. The FDA already expects your SBOM to cover your own components, third-party components, and "the upstream software dependencies that are required/depended upon by proprietary, purchased/licensed, and open-source software". If your SBOM meets the FDA's expectation today, the new Coverage element asks nothing extra of you. The rest of the software industry is catching up to where medical devices already are.

The gap worth closing early: hashes

One new requirement isn't clearly covered by FDA guidance, and if you are currently evaluating an SBOM tool, I would consider adding it to your evaluation and validation criteria.

The NTIA's October 2021 Framing document identifies the Component Hash field as recommended and not required. The 2026 CISA guidance ends the ambiguity by making the hash value and algorithm required fields. This is new for medical devices, as the FDA officially never required component hashes.

A hash is a digital fingerprint of the compiled component, and it's what lets anyone (including you) verify that the SBOM describes the software actually running on the device, rather than what the build server thought it shipped. If your tooling doesn't emit hashes yet, this is the gap to close first, and it's usually a configuration change rather than a project.

The hash needs to be captured during the initial SBOM generation stage, either at the source or build stage. An SBOM enrichment and surveillance tool like Threat Detective can’t retrospectively add the hash to each component in an SBOM. The original set of binaries must be available to generate an accurate hash.

The other new fields (licence, generating tool, and generation context) are similar in character: typically already in your SBOM tool's output, or a settings change away.

In one area, the FDA still asks for more than CISA does: the level of support for each component (actively maintained, no longer maintained, abandoned) and its end-of-support date. Those stay in your submission regardless.

The EU angle

The international authorship makes this document useful beyond the FDA. The guidance itself points to the EU Cyber Resilience Act, which requires an SBOM as part of technical documentation, and the Commission's involvement in drafting signals where European expectations are heading. Medical Devices are exempt from the EU CRA, and the EU MDR doesn't mention SBOMs by name, but if you follow IEC 81001-5-1:2021, you are required to maintain a software component inventory as part of your secure development lifecycle. Most inventory implementations are SBOMs, so when a notified body reviews what that inventory should contain, they may consider the 2026 minimum elements guidance. Practically speaking, I haven’t observed notified bodies rigorously reviewing SBOMs to the depth that the FDA does.

Conclussion

There is no need to rush to adopt the new CISA 2026 SBOM guidance; much of the required data is already available to you and may require only a small configuration change to access it. This can be done during maintenance. If you were setting up an SBOM process from scratch today, I would consider including the CISA 2026 SBOM changes in your requirements to avoid future work, particularly support for “Component hashes”.