How to fill in the SBOM section of an MDS2 form for a medical device

The SBOM section of the MDS2 form has eight items, SBOM-1 through SBOM-4 with four sub-items under SBOM-2. Answer each one from the same machine-readable, version-specific SBOM you prepared for FDA under section 524B(b)(3), use the Note column to say which format, which release and where the hospital gets the file, and only answer "Yes" where you can hand over the evidence on request.

Hospitals file the MDS2, compare it across vendors and quote it back to you during purchasing and incident calls, so a "Yes" you cannot back will come back to you. This post walks through each SBOM item, lines each answer up with what FDA expects in a premarket submission, and shows how to keep the answers true as software changes. It ends with how Safeguard handles the SBOM half of the job and what it does not do.

This is a practical guide for product security and regulatory affairs teams. It is not regulatory advice. Your regulatory strategy, your submission and your labeling remain your decisions.

Key takeaways

• The MDS2 form is ANSI/NEMA HN 1-2019, published by the Medical Imaging and Technology Alliance (MITA), a division of NEMA, on 8 October 2019. NEMA's standards page, as archived in January 2026, still listed it as Active.
• The SBOM section has eight items: SBOM-1, SBOM-2, SBOM-2.1 to SBOM-2.4, SBOM-3 and SBOM-4. Each takes Yes, No, N/A or See Note, plus a Note number.
• FDA asks for more than the form does. The February 2026 premarket cybersecurity guidance asks for a machine-readable SBOM with the NTIA minimum elements, plus each component's level of support and end-of-support date, plus known vulnerabilities including those in CISA's Known Exploited Vulnerabilities catalog.
• Section 524B(b)(3) of the FD&C Act requires sponsors of cyber devices to provide FDA an SBOM "including commercial, open-source, and off-the-shelf software components."
• One SBOM, one release, one MDS2 revision. FDA's guidance says a revision-controlled MDS2 may address several of its labeling recommendations, so version the form with the software.
• "Not affected" is a claim you make, not a scan result. Use a VEX format and a recognised justification, and keep the analysis behind it.
• Safeguard capabilities in this post and their labels: SBOM generation and analysis in SPDX and CycloneDX (GA); software composition analysis and vulnerability management with EPSS and KEV (GA); the per-project SBOM explorer with its Suppliers & Licenses and Mitigations tabs (GA, part of SBOM analysis); license compliance (GA); CSAF and VEX upload (GA); bulk data export (GA); the Safeguard CLI (GA); the Safeguard MCP server (GA); autonomous remediation (GA, ships switched off with every category set to Manual); Gold Open Source and Gold Registry (GA); fork and patch (GA).
• Safeguard does not fill in the MDS2 form or file anything with FDA. It produces and analyses the SBOM, tracks suppliers, licenses, vulnerabilities and mitigation decisions, and exports the data you use to answer the form.

What is the MDS2 form, who publishes it, and which version asks about the SBOM?

MDS2 stands for Manufacturer Disclosure Statement for Medical Device Security. The current standard is ANSI/NEMA HN 1-2019, published 8 October 2019 by the Medical Imaging and Technology Alliance, a division of NEMA. NEMA's page describes it as the MDS2 form plus instructions, meant to help people responsible for medical device security risk assessment, and warns the information may be inappropriate for other purposes. NEMA offers the electronic copy as a free download.

NEMA also publishes the form as an Excel worksheet, which holds the exact question wording. Every row has a Question ID, the Question, an answer column headed "Yes, No, N/A, or See Note", a Note number, and three reference columns mapping the question to IEC TR 80001-2-2:2012, NIST SP 800-53 Rev. 4 and ISO 27002:2013.

The 2019 revision is the one with a dedicated SBOM section. It sits between "ROADMAP FOR THIRD PARTY COMPONENTS IN DEVICE LIFE CYCLE (RDMP)" and "SYSTEM AND APPLICATION HARDENING (SAHD)", and its heading in the worksheet is "SOFTWARE BILL OF MATERIALS (SBoM)". Note the lower case "o"; the form writes SBoM throughout.

The section opens with a one-paragraph definition: an SBoM lists all the software components incorporated into the device, for operational security planning by the healthcare delivery organization. It then adds a line that tells you how hospitals will read your answers: "This section supports controls in the RDMP section." In other words, the SBOM is the evidence behind your RDMP answers on secure development, support dates and end-of-life planning.

NEMA's standards page, as archived in January 2026, still marked HN 1-2019 Active with no later revision listed. NEMA has since moved much of its web presence to a new site, so confirm the current revision with MITA before you publish, and check whether any later revision renumbered the SBOM items.

Which SBOM questions does the MDS2 ask, and what does a "yes" commit you to?

Here is every item in the section, with the question text exactly as the 2019 worksheet words it, and what a "Yes" puts on the record.

SBOM-1: Is the SBoM for this product available?

This is the gate question. A "Yes" here means a hospital can get the file. It does not have to mean the file is attached to the MDS2. Most manufacturers answer "Yes" and use the Note column to say how the SBOM is delivered: on request under NDA, through a customer portal, or in the labeling package.

Two things to get right. First, the SBOM must match the product named in DOC-3 (Device Model) and the release the form describes, not "the platform" in general. Second, FDA's labeling recommendations say manufacturers should provide or make SBOM information available to users on a continuous basis, and if a portal is used, the links should stay current. If your "Yes" depends on a portal, the portal is part of the answer.

If you cannot provide an SBOM yet, "No" is a legitimate answer. A "No" with a Note explaining the plan and date is far easier to defend than a "Yes" you cannot back.

SBOM-2: Does the SBoM follow a standard or common method in describing software components?

Answer "Yes" when the SBOM is in SPDX or CycloneDX, and name the format and version in the Note (for example "SPDX 2.3 JSON"). The NTIA minimum elements report names SPDX, CycloneDX and SWID tags as the formats that meet its automation support element. A spreadsheet on its own is not "a standard or common method." Sub-items 2.1 to 2.4 then test completeness.

SBOM-2.1: Are the software components identified?

"Yes" means each component has a name. The NTIA report defines Component Name as the designation assigned to a unit of software by the original supplier. Use upstream names, not internal module codes, and add unique identifiers such as package URLs or CPEs where you have them, because those are what a hospital's tools match against vulnerability feeds.

SBOM-2.2: Are the developers/manufacturers of the software components identified?

This maps to the NTIA element Supplier Name. It is easy to answer "Yes" here when the truthful answer is "partly." Open source components frequently have no clear supplier, and embedded vendor libraries sometimes carry only a product name.

Do not guess. SPDX 2.3 lets you write NOASSERTION in the package supplier field when you could not determine the supplier. In CycloneDX you leave the supplier out and record the gap. NTIA calls this "known unknowns": the SBOM should say where its knowledge stops. If some suppliers are unknown, answer "See Note" and give the share that is identified, or answer "Yes" with a Note that says unknown suppliers are marked as such. Our post on how to mark unknown supplier and version in an SBOM covers the mechanics.

SBOM-2.3: Are the major version numbers of the software components identified?

The form asks only for major versions. FDA's guidance and the NTIA minimum elements expect the version of the component as the supplier states it. Give the full version string. A major version alone cannot be matched against a vulnerability advisory, and a hospital's tooling will treat it as unknown.

SBOM-2.4: Are any additional descriptive elements identified?

This is where the FDA additions belong. If your SBOM or an addendum carries license, hashes, dependency relationships, level of support and end-of-support date, answer "Yes" and list them in the Note. Hospitals care most about the last two, which are exactly the fields FDA asks for beyond NTIA.

SBOM-3: Does the device include a command or process method available to generate a list of software components installed on the device?

This question is about the device, not the document. Can a field engineer or the hospital list what is actually installed on a given unit, from a service menu, a diagnostic command or a documented procedure? It matters because the SBOM describes a release, while the hospital owns units that may not all be on that release.

Answer "Yes" only if the method exists and is documented. If only a service technician can run it, say "See Note" and explain. Many devices have no such method, and "No" is the honest answer. No SBOM tool can answer this for you.

SBOM-4: Is there an update process for the SBoM?

"Yes" means a new or changed release produces a new SBOM, and customers get it. FDA's guidance says an SBOM should be maintained as part of the device's configuration management and updated to reflect changes to the software in marketed devices. NTIA's Frequency practice says the same: a new build or release means a new SBOM.

In the Note, state the trigger (every released software or firmware version, plus corrections), the channel (portal, labeling, on request) and how customers learn a new version exists. That last part links to your CSUP answers on update notification.

The neighbouring questions a hospital will cross-check

A careful reviewer reads the SBOM section next to these. Keep them consistent.

• DOC-8, coordinated vulnerability disclosure, and DOC-9, membership of an Information Sharing and Analysis Organization.
• DOC-11 and its sub-items on Software as a Medical Device, operating system and hosting. If DOC-11.2 says the SaMD relies on an owner-provided operating system, your SBOM should say whether that operating system is in scope.
• RDMP-3, whether you keep a web page or other source of information on software support dates and updates, and RDMP-4, whether you have a plan for managing third-party component end-of-life. These are the form's closest match to FDA's level-of-support and end-of-support fields.
• CSUP-1 to CSUP-11, on which software in the device may need security updates (operating system, drivers and firmware, anti-malware, other commercial components) and who installs them. Every category answered "Yes" in CSUP-2, CSUP-3, CSUP-5 or CSUP-6 should have components in the SBOM.

How do the MDS2 answers line up with the SBOM FDA expects under section 524B?

Section 524B of the Federal Food, Drug, and Cosmetic Act was added by Public Law 117-328 on 29 December 2022 and took effect 90 days later. FDA's guidance says it applies to sponsors submitting a 510(k), PMA, PDP, De Novo or HDE for a "cyber device." Subsection (c) defines a cyber device as one that includes software validated, installed or authorized by the sponsor as or in a device, has the ability to connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats.

Subsection (b)(3) is short. The sponsor shall provide FDA a software bill of materials, "including commercial, open-source, and off-the-shelf software components." Our post on what counts as a cyber device covers the definition in more depth.

FDA explains how it wants that SBOM in its guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions." The current version was issued on 3 February 2026 and supersedes the June 27, 2025 version, which carried the older "Quality System" title. The docket is FDA-2021-D-1158. Like all FDA guidance, it contains nonbinding recommendations; the statute is what binds cyber devices.

Three parts of the guidance matter for the MDS2.

1. Section V.A.4, Third-Party Software Components. Part (a) describes what an SBOM should cover: manufacturer-developed components, third-party components including purchased or licensed software and open source, and their upstream dependencies. Part (b) lists what the premarket submission should contain, covered in the next section.
2. Section VI.A, Labeling Recommendations. FDA recommends that labeling include an SBOM in machine-readable form, that SBOM information be available to users on a continuous basis, and that labeling include known or anticipated end of support and end of life information. The same section then says that a revision-controlled MDS2, together with customer security documentation as outlined in the Medical Device and Health IT Joint Security Plan version 2 (JSP2), may address a number of these recommendations.
3. Section VII.C.3, Software Bill of Materials (Section 524B(b)(3)). For cyber devices, FDA recommends SBOMs that contain the information in Section V.A.4.b.

So FDA names the MDS2 as one way to carry labeling content to users. If your MDS2 and your labeling describe the same device differently, both lose credibility.

Which fields does FDA want beyond the NTIA minimum elements?

Start with the baseline. The NTIA report "The Minimum Elements For a Software Bill of Materials (SBOM)," dated 12 July 2021, sets out three groups: data fields, automation support and practices and processes. The data fields are Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data and Timestamp. The practices are Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control and Accommodation of Mistakes.

FDA's Section V.A.4.b says manufacturers should provide machine-readable SBOMs consistent with the minimum elements, which it also calls "baseline attributes." It cites them to the October 2021 NTIA document "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)." The baseline attributes in that framing document and the minimum elements in the July report describe the same core idea; in practice teams use the seven data fields from the July report as the checklist.

Then FDA adds, for each component in the SBOM:

• The software level of support provided through monitoring and maintenance from the component manufacturer. FDA's examples are that the software is actively maintained, no longer maintained, or abandoned.
• The component's end-of-support date.

FDA lets you include these in the SBOM itself or provide them separately, for example in an addendum. If you cannot provide SBOM information at all, FDA asks for a justification of why.

The same section asks for something the MDS2 SBOM section does not: identification of all known vulnerabilities associated with the device and its components, including those in CISA's Known Exploited Vulnerabilities catalog. For each known vulnerability, FDA wants to know how it was discovered, a safety and security risk assessment, and details of the risk controls, including compensating controls.

Where those extra fields go in SPDX and CycloneDX

SPDX 2.3 has a direct home for the end-of-support date. Clause 7.27, "Valid until date," records the end of the support period for a package from the supplier, in a timestamp format such as 2030-12-30T18:30:00Z. SPDX also has Release date and Built date fields in the same clause.

We could not confirm a component field with that exact meaning in the CycloneDX 1.6 JSON reference, so CycloneDX users typically carry these values in component properties or an addendum. FDA explicitly allows an addendum in either format. What matters for the MDS2 is that SBOM-2.4's Note says where the fields are.

Level of support has no standard enumeration in either format. Pick a small fixed vocabulary that follows FDA's examples (actively maintained, no longer maintained, abandoned) and use it everywhere: the SBOM addendum, the MDS2 Note and your support-dates web page under RDMP-3. Our post on end of sale, end of support and end of life explains why those dates should not be mixed up.

Who decides the support level?

You do. A scanner can show when a package last released or whether its repository is archived. It cannot tell you how long a commercial real-time operating system supplier will patch the version you ship. That comes from supplier contracts, published lifecycle pages and your own decisions about components you maintain. Record the source for each statement.

SPDX or CycloneDX: what to hand a hospital, and how to make it readable?

Both are fine for SBOM-2. FDA does not mandate either; it encourages industry-accepted formats. The practical choice depends on who reads the file.

Our advice: generate both from the same source of truth if your tooling allows it, deliver whichever the hospital asks for, and name it in the SBOM-2 Note.

Readability is a separate problem. A clinical engineering team managing many device models will not open a JSON file to check this morning's vulnerability news. Give them three things alongside the machine-readable SBOM:

1. A flat table export (CSV or spreadsheet) with component, supplier, version, level of support and end-of-support date.
2. A short cover sheet: product name and model as in DOC-2 and DOC-3, software version, SBOM format, timestamp, author, and where updates are published.
3. A vulnerability statement or VEX file for the known vulnerabilities, so the hospital's tools do not raise alarms you have already analysed.

For more on what FDA expects in the file itself, see our guide to FDA SBOM requirements under section 524B and in our earlier post on the FDA premarket SBOM in 2026.

How do you keep the MDS2 answers and the SBOM in step across releases?

The MDS2 describes one device and, implicitly, one software state. The device changes. Here is a method that keeps them aligned.

1. Make the release the unit. Every released software or firmware version gets one SBOM, one timestamp, one author and, if anything on the form changes, a new MDS2 revision identified by DOC-4 (Document ID) and DOC-7 (Document Release Date).
2. Generate the SBOM from the tagged build, and keep it under the same configuration management as the release, as FDA recommends.
3. Diff each new SBOM against the last one. New, removed and changed components should prompt a review of SBOM-2.2, SBOM-2.3, RDMP-4 and the CSUP answers.
4. Re-check support data on a schedule. A component can reach end of support between releases; treat a passed date as a change even if the software did not change.
5. Re-run vulnerability matching daily. New CVEs change your known-vulnerabilities statement, not your SBOM. The postmarket plan required by 524B(b)(1) assumes you watch for this.
6. Publish in one place and keep it current, as FDA's note about up-to-date portal links expects.

NTIA's Accommodation of Mistakes practice applies to the fourth row: SBOMs will contain errors, and the expectation is that you correct them openly rather than leave the old file in circulation.

How do you say a listed vulnerability does not affect the device without overpromising?

Hospitals will run your SBOM against vulnerability databases, and some matches will not apply. If you stay silent, every match becomes a support ticket. If you speak carelessly, you have made a written statement about patient-connected equipment that may turn out to be wrong.

The standard way to make this statement is a Vulnerability Exploitability eXchange (VEX) document. CISA's "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)," published April 2023, requires every VEX statement to carry one of four statuses: not affected, affected, fixed or under investigation. For "not affected," a statement should provide a justification, and if it does not, it must provide an impact statement explaining why the product is not affected.

CISA's June 2022 document on VEX status justifications lists five justifications:

• Component not present
• Vulnerable code not present
• Vulnerable code cannot be controlled by adversary
• Vulnerable code not in execute path
• Inline mitigations already exist

CycloneDX 1.6 has its own vocabulary. Its analysis states include exploitable, in triage, false positive and not affected, and the specification says every not-affected case should carry a justification, such as code not present, code not reachable, requires configuration, requires environment or protected at perimeter.

To stay on the right side of overpromising:

• Scope each statement to a version. "Not affected in software version 4.2.1" is a fact you can check. "Not affected" on its own is a promise about every unit in the field.
• Prefer the narrow justification. "Component not present" and "vulnerable code not present" can be shown from the build. "Cannot be controlled by adversary" depends on assumptions about the deployment environment; say what those assumptions are.
• Be careful with "protected at perimeter." A hospital network is not your perimeter. If your statement depends on segmentation, say so and point to the network guidance in your labeling.
• Use "under investigation" early. It beats silence when a widely reported issue matches your SBOM.
• Keep the evidence. FDA asks how each known vulnerability was assessed and what controls address it. The same analysis backs your VEX statement.
• Sign and timestamp. CISA's minimum requirements expect an identified author and timestamps, and recommend tying the author's identity to a signature.

Our post on ingesting and sharing VEX and CSAF to say a CVE does not affect you goes deeper on the formats.

How Safeguard does this job, step by step

Everything above works with any SBOM tooling. This section shows how Safeguard handles the SBOM half of the MDS2: generating a version-specific SBOM, checking suppliers and licenses, matching vulnerabilities, recording not-affected decisions, and exporting the data you use for the form. Every step follows Safeguard's own docs. Where the docs do not show a screen or command, we describe the outcome instead.

Step 1: Create one project version per device release

In the app, open Integrations from the sidebar. The Integrations page lets you filter by All, Source Code (SCM), Container Image, AI Model or Upload. Source code options include GitHub, GitLab, Bitbucket and generic Git; container options include Amazon ECR, Docker Hub, GCP Cloud Source and OCI registries; uploads include manifest files and CSAF/VEX.

When you connect a repository, the review step lets you choose the Branch/Tag, set the Project Name and set the Version (it defaults to 1.0.0). Point the branch or tag at the release tag of the device software, and set the version to the software version you will put on the MDS2. Safeguard's generation options also auto-detect the version from git tags.

This one decision does most of the work for SBOM-4. If each release is its own project version, each has its own SBOM, its own vulnerability list and its own mitigation records.

Step 2: Generate the SBOM

Generation happens when the project is connected. The documented generation options are Project Name, Version, Branch/Tag, Include Dev Dependencies and Deep Analysis (Griffin AI deep analysis). For a device release, leave development dependencies out unless they ship on the device, because the MDS2 describes software incorporated into the device.

If you prefer to scan locally, Safeguard's docs show the CLI flow:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash
# Open the terminal, then type /login and /scan .
safeguard
# Or scan from the command line, writing results under ./output
safeguard scan --dir .

The docs say a scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and that source code does not leave the machine. The CLI docs describe safeguard scan as building an SBOM and matching it against vulnerability databases.

Step 3: Turn on continuous scanning

Safeguard's docs say it scans all projects daily to catch newly disclosed vulnerabilities. You can add triggers: On Push, Scheduled (daily, weekly or custom) and On Release, which scans when new tags are created. On Release fits a device team well, because a new tag is the moment a new SBOM and possibly a new MDS2 revision are due.

Step 4: Check the SBOM against the form, tab by tab

Open the project from Projects. The Project Overview page has these tabs, and each one feeds a part of the form.

• Info shows Project Name, Project Version, Generation Method (SCM, Container or Manual), Source Code Repository and Branch/Tag. Use it to confirm the SBOM describes the release named on the form.
• Dependencies shows a tree view with parent-child relationships and depth, and a table view with component name and version, license type and vulnerability count. This is your check for SBOM-2.1 and SBOM-2.3: sort by version and look for blanks.
• Suppliers & Licenses shows, per component, Supplier Name, Supplier URL, Contact and Verification, and classifies suppliers as Open Source Project, Commercial Vendor, Internal or Unknown. Filter for Unknown before you answer SBOM-2.2. The count of Unknown suppliers is the number to put in your Note, or to resolve first.
• Vulnerabilities shows the total count, a severity breakdown, affected components and fix recommendations.
• Mitigations holds the decisions you record in Step 6.

The Suppliers & Licenses tab also covers license compliance (GA): a license summary with categories such as permissive, weak copyleft and strong copyleft, compliance status per component, and license policies you create under Settings › License Policies. License data is one of the "additional descriptive elements" you can cite under SBOM-2.4.

Step 5: Review known vulnerabilities with EPSS and KEV context

Vulnerability management (GA) matches components against vulnerability sources, and the offering lists NVD, GHSA, OSV, CISA KEV and vendor bulletins among them, with EPSS and KEV used in prioritisation. For the premarket submission, FDA asks you to identify all known vulnerabilities including KEV entries. For the MDS2, this list is the input to your vulnerability statement.

What Safeguard gives you is the match and the context. The safety and security risk assessment FDA asks for, including device and system impacts, is your engineering and clinical judgement.

Step 6: Record each "does not affect" decision in Mitigations

From the Vulnerabilities tab, find the vulnerability, open the ⋮ menu and choose Add Mitigation. The mitigation form has these fields, as Safeguard's docs list them:

• Type: Risk Acceptance, False Positive, Workaround or N/A (required)
• Justification (required)
• Expiration Date (Risk Acceptance only)
• Approved By (required)
• Evidence (optional)
• Scope: this version only, or all versions (required)

For device work, set Scope to this version only unless you have checked every release. Record the VEX-style reason in the Justification field, for example "vulnerable code not present: the affected module is not compiled into this build," and attach the build evidence. Safeguard logs who created, changed, approved, expired or revoked each mitigation, and its History tab shows the trail.

Two cautions. Active mitigations exclude a vulnerability from gate failures, so a careless "N/A" quietly hides a finding from your release gates. And a mitigation record in Safeguard is your internal decision record. Safeguard's docs do not describe it producing a signed VEX document for you. Write and sign the VEX statement you give hospitals with your own process, using the justification you recorded here.

Step 7: Load supplier VEX and CSAF

When a supplier of a commercial component sends you a VEX file or publishes a CSAF advisory, upload it through Integrations, filtered by Upload, on the Upload CSAF/VEX card. CSAF and VEX upload is GA. Tie it to the project name and version it applies to, so supplier statements about their component inform your own analysis. You still decide whether to trust each supplier's claim.

Step 8: Export what you need for the form and the hospital

Safeguard's Explore SBOM docs list export options including SPDX (JSON, XML, RDF), CycloneDX (JSON, XML), CSV, Excel with multiple sheets, PDF and raw JSON. For a hospital package:

• Export the SBOM in the format you named in SBOM-2.
• Export the dependency table to CSV or Excel as the readable companion, then add your level of support and end-of-support columns, which you maintain yourself.
• From Suppliers & Licenses, use Export › Attribution Notice (TXT, HTML or Markdown) or Export › License Report if the hospital or your labeling needs them.
• From the Mitigations area, the docs describe mitigation reports in PDF, CSV or Excel, which you can use as the internal record behind your vulnerability statement.

Then fill in the MDS2 yourself, using these exports as the evidence for each answer. On the next release, the On Release trigger scans the new tag; review new Unknown suppliers and new vulnerabilities, carry over mitigations only where you have re-checked them, and publish the new SBOM and MDS2 revision together.

Mapping the form to the flow

What Safeguard does not do

Be clear on these before you build a process around any tool.

• It does not fill in the MDS2 form or file anything with FDA. Safeguard produces and analyses the SBOM and the vulnerability data. The form, the premarket submission, the labeling and every answer on them are yours.
• It does not supply level of support or end-of-support dates. FDA's two extra fields are the manufacturer's statements, drawn from supplier agreements and lifecycle commitments. Safeguard's supplier data and risk signals can inform them; they cannot replace them.
• It only lists what it scanned. Components in firmware images, binary blobs, bootloaders, FPGA bitstreams or third-party modules that never pass through a scanned repository, container image or uploaded manifest will be missing. Safeguard does not produce a hardware bill of materials. For a device, the gap between "what the scan saw" and "what is on the board" is your responsibility to close and to disclose as known unknowns.
• It does not author or sign your VEX. A mitigation record is an internal decision with an audit trail. The VEX or CSAF document you give a hospital, and the justification in it, are your assertion and need their own evidence and signature. CSAF and VEX upload (GA) reads files; it does not write your advisories.
• It does not perform your safety risk assessment. FDA asks for a safety and security risk assessment for each known vulnerability, including device and system impacts. EPSS and KEV context help prioritise; they are not a clinical risk judgement.
• The documented REST endpoints for mitigations and suppliers are not available yet. Safeguard's docs mark the /v1 paths on those pages as not yet available. Use the app, the CLI and exports.

Common mistakes

• Answering "Yes" to SBOM-1 with no delivery path. If the hospital asks for the file and it takes three weeks, the answer was wrong. Put the channel in the Note.
• One SBOM for a product family. The form describes a model. If variants carry different software, each needs its own SBOM.
• Guessing suppliers. A wrong supplier is worse than "unknown," because it misdirects the hospital's follow-up.
• Leaving out the operating system. Device teams often scan the application and forget the embedded operating system, the board support package and drivers, which are often the components that need the most patches. If CSUP-2 or CSUP-3 says "Yes," they belong in the SBOM.
• Mixing up end of support and end of life. RDMP-3, RDMP-4 and FDA's end-of-support field are about when security fixes stop. Use the supplier's support date, not a marketing end-of-sale date.
• Over-broad "not affected" statements. Scope them to a version, use the narrowest justification you can prove, and do not rely on hospital network controls you do not own.
• Letting the MDS2 go stale. Revise it with each release, as FDA's "revision-controlled" wording expects.

FAQ

Is the MDS2 form required by FDA?

No. The MDS2 is a voluntary industry standard published by NEMA's MITA division, and hospitals often request it during purchasing. FDA's premarket guidance says a revision-controlled MDS2 and customer security documentation per JSP2 may address a number of its labeling recommendations. Section 524B separately requires an SBOM for cyber devices.

What is the latest version of the MDS2 form?

ANSI/NEMA HN 1-2019, published 8 October 2019. NEMA's standards page, as archived in January 2026, listed it as Active. Check with MITA for any later revision before publishing a new form.

Do I have to attach the SBOM to the MDS2?

No. SBOM-1 asks whether it is available. State in the Note column how the hospital obtains it, and make sure that channel works.

What does FDA require in a medical device SBOM beyond the NTIA minimum elements?

For each component, FDA's February 2026 guidance asks for the level of support from the component manufacturer and the component's end-of-support date. It also asks for a list of known vulnerabilities, including those in CISA's KEV catalog, with a risk assessment and risk controls for each.

Should I give hospitals SPDX or CycloneDX?

Either satisfies SBOM-2. Ask what the hospital's tools accept. SPDX 2.3 has a native "Valid until date" field for end of support; CycloneDX can carry vulnerability analysis alongside components. Many manufacturers produce both from the same source.

How do I answer SBOM-2.2 when some open source suppliers are unknown?

Mark them as unknown in the SBOM, then answer "See Note" with the share identified and how unknowns are marked. Never invent a supplier.

How often should the SBOM and the MDS2 be updated?

The SBOM with every released software or firmware version and every correction; the MDS2 whenever an answer or the software version it describes changes.

Can I say a CVE does not affect my device in the MDS2?

The SBOM section has no field for that. Use a separate VEX document or vulnerability statement with one of the recognised statuses and a justification, scoped to the software version, and reference it in your customer security documentation.

What should I do when a component listed in my MDS2 SBOM has a known vulnerability?

Assess it, record the decision, and tell customers with a version-scoped statement. An MDS2 that lists a component with a known vulnerability is only half the story, because hospitals will ask when the fix ships. The section below explains how Safeguard helps close that gap for the open source dependencies and container images you build into device software, while firmware and vendor components still depend on their suppliers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, asks it to fix the lodash CVE in a repository, and shows it reading the finding and advisory, asking before any command that changes something, editing package.json to lodash 4.17.21, running npm install and npm test with approval, and printing a summary without pushing anything. It then shows /permissions, /model and /scan. For a device team, the /scan step is the same local scan that produces the SBOM behind your SBOM-1 answer, run against the release tag of your device software.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. For MDS2 work, that lets a regulatory or product security lead ask questions about a project's components and vulnerabilities in plain language while preparing answers, and because you choose the tools, you can limit Claude to reading project data. The answers on the form still come from you.

Click through it at your own pace, or open it full screen.

To try the SBOM flow on your own device software, get the apps and CLI at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs.

Quick check

Sources

• NEMA, Manufacturer Disclosure Statement for Medical Device Security, ANSI/NEMA HN 1-2019 (archived January 2026)
• NEMA, MDS2 form worksheet (xlsx, archived January 2026)
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, guidance page (archived 12 October 2026)
• FDA, Cybersecurity in Medical Devices guidance, PDF issued 3 February 2026 (archived 19 October 2026)
• 21 U.S.C. 360n-2, Ensuring cybersecurity of devices (FD&C Act section 524B), Legal Information Institute
• NTIA, The Minimum Elements For a Software Bill of Materials (SBOM), 12 July 2021
• CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX), April 2023
• CISA, Vulnerability Exploitability eXchange (VEX) Status Justifications, June 2022
• CISA, Known Exploited Vulnerabilities Catalog
• SPDX Specification 2.3.1, Clause 7: Package information
• CycloneDX v1.6 JSON reference
• CycloneDX, Vulnerability Exploitability eXchange (VEX)
• Safeguard docs, Generate SBOM
• Safeguard docs, Explore SBOM
• Safeguard docs, Suppliers & Licenses
• Safeguard docs, Mitigations
• Safeguard docs, CLI
• Safeguard download page

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.