Safeguard
Compliance•

Medical device cybersecurity labeling: what to tell users

FDA suggests labeling that covers ports, secure configuration, SBOM access, logging, end of support and decommissioning. A checklist for device teams.

Safeguard Security Team
3 min read

FDA treats security information in labeling as part of safe use. Its guidance lists items to consider, including network ports, secure configuration, SBOM access, update procedures, logging, backup and restore, end of support and decommissioning. Anything you hand to the user as a task should be tested for whether that user can do it.

Why labeling matters here

The guidance notes that inadequate cybersecurity information in labeling may cause a device to be misbranded under section 502(f) if the labeling lacks adequate directions for use, and under section 502(j) if the device is dangerous when used as the labeling recommends. Labeling is therefore a regulatory surface, not only documentation.

It also says that risks transferred to the user should be considered for usability testing, so the type of user is shown to be capable of acting on them. A patient at home has a very different ability from a hospital biomedical team.

Checklist from the guidance

The guidance gives examples of information to include. Grouped for use:

Set up and network

  • Recommended security controls for the use environment, such as anti-malware, a firewall and password rules.
  • Diagrams that let users apply those controls.
  • A list of network ports and interfaces, with direction and approved destination endpoints.
  • Supporting infrastructure requirements, such as minimum network needs.

Ongoing management

  • An SBOM in a machine readable format, made available on a continuous basis.
  • How users download version identifiable, manufacturer authorized software and firmware, and how they learn an update exists.
  • Secure configuration of shipped devices, which settings users can change, and which changes raise risk.

Detection and recovery

  • How the device responds to security events, including user notification and logging.
  • How forensic evidence is captured, with log location, format, retention and how automated tools can read it.
  • Backup and restore of authenticated configurations.
  • Features that protect critical function, such as a backup mode or disabling ports.

End of life

  • Known or expected end of support and end of life for the device and its components. After end of support, the manufacturer may be unable to provide patches, so a pre-established and pre-communicated process for transferring risk is expected.
  • How to securely decommission the device by sanitizing sensitive data and software.

The guidance notes a revision controlled Manufacturer Disclosure Statement for Medical Device Security (MDS2) and customer security documentation, as described in the Joint Security Plan version 2, may cover many of these points.

Write for the real reader

The guidance asks that instructions be understandable to the intended audience, which may include patients or caregivers with limited technical knowledge. If users get documents through an online portal, links must be kept current.

If you publish an SBOM, tools such as a plain definition of an SBOM are useful for explaining it to hospital staff.

Quick check

Is an MDS2 form enough on its own?

FDA says an MDS2 and customer security documentation may address a number of the items, not all. Check the list against what you ship.

Do I have to disclose end of support dates?

The guidance recommends information on end of support and end of life if known or anticipated, along with a pre-communicated process for how risk transfers to users.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.