IEC 81001-5-1 Explained: Health Software Security, SBOM and FDA

IEC 81001-5-1:2021 is the international standard that defines the security activities a manufacturer must build into the life cycle of health software, from planning and design through release, maintenance and vulnerability handling. It was published by the IEC on 16 December 2021, written by subcommittee SC 62A, and it applies to health software in general, not only to software that regulators classify as a medical device.

In practice it is the security companion to IEC 62304, the medical device software life cycle standard, and it is built so that a team following it can also support conformance to IEC 62443-4-1, the industrial secure development standard. Both the US FDA and the European medical device framework point to it, which is why it has become the default answer to the question "what secure development process do you follow?" in a health software audit.

This post goes one level deeper than our earlier pieces on FDA SBOM requirements under Section 524B, what counts as a cyber device, designing medical device software updates, choosing an SBOM tool for medical device compliance and IEC 62443 roles, zones and conduits. Those cover the regulatory triggers and the industrial standard. This one is about the health software standard itself and how to run it day to day.

We worked from the IEC records for the three standards, the full text of the FDA's February 2026 premarket cybersecurity guidance, section 524B of the FD&C Act, IMDRF N73, MDCG 2019-16, the Commission's harmonised standards page, the NTIA minimum elements and the official CycloneDX tool documentation. IEC 81001-5-1 is a paid document, so we describe its structure and intent from the IEC abstract and its clause headings and do not reproduce its text.

Key takeaways

• IEC 81001-5-1:2021, "Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle", was published on 16 December 2021 as edition 1.0. It runs to 114 pages, is owned by IEC TC 62/SC 62A, and a corrected version including Interpretation Sheet 1 (December 2025) is now on sale.
• Its scope is health software, which is broader than medical device software. It covers software intended for health purposes whether or not a regulator treats it as a device, and it explicitly excludes the content of accompanying documentation.
• Its process clauses mirror IEC 62304 (development, maintenance, risk management, configuration management, problem resolution) and add security tasks to each one, so a team that already runs 62304 extends its existing process rather than starting a second one.
• Its purpose, in the IEC's words, is to support conformance to IEC 62443-4-1 "taking the specific needs for health software into account", which is why the security testing and issue handling activities look so similar across the two standards.
• Third-party software, including the open source that IEC 62304 calls software of unknown provenance (SOUP), has to be identified, assessed for known vulnerabilities, monitored after release and planned for end of support. That is, in practice, an SBOM with lifecycle data.
• The FDA's February 2026 premarket guidance names IEC 81001-5-1 as one framework a manufacturer can use as its Secure Product Development Framework. For cyber devices, section 524B makes an SBOM, a postmarket vulnerability plan and update processes legal requirements, and the guidance asks for each SBOM component's support level and end-of-support date.
• In Europe the MDR and IVDR require software to be developed "in accordance with the state of the art" including information security. The European adoption is EN IEC 81001-5-1:2022. We could not confirm from the Official Journal whether its reference has been published as a harmonised standard, so check the Commission's list before claiming presumption of conformity.

What is IEC 81001-5-1?

IEC 81001-5-1 is a process standard. It does not prescribe particular cryptography, authentication schemes or coding languages. It defines processes, activities and tasks that, when carried out and recorded, give a reasonable basis for saying a piece of health software was built and is maintained securely.

The IEC abstract states the purpose plainly: the standard defines the life cycle requirements for development and maintenance of health software needed to support conformance to IEC 62443-4-1, taking the specific needs for health software into account. It says the set of processes, activities and tasks establishes a common framework for secure health software life cycle processes, and that the goal is to increase the cybersecurity of health software both by adding activities to the life cycle and by making the life cycle processes themselves more secure.

That second goal is easy to miss. The standard also covers the build system, the source repository, the release pipeline and the people with access to them. A compromised build server can ship a signed, fully tested product that contains someone else's code, so the integrity of the development process counts as part of the product's security.

When was it published, and who wrote it?

The IEC webstore lists the publication date as 2021-12-16, edition 1.0, with a stability date of 2028. The responsible committee is IEC TC 62/SC 62A, "Common aspects of medical equipment, software, and systems". That is the same subcommittee that owns IEC 62304. The ISO catalogue lists it too (reference 76097); we could not load the ISO page during research, so committee and date details here come from the IEC record.

The webstore now sells a "corrected version 2025-12" and notes that the contents of Interpretation Sheet 1 (2025-12) are included in that copy. If your quality system references the 2021 text, check whether the interpretation sheet changes how you read any clause you rely on. Interpretation sheets clarify intent; they do not create a new edition, so the designation stays IEC 81001-5-1:2021.

The European adoption is EN IEC 81001-5-1:2022, with the same technical content.

Which products does it cover?

The standard uses the term health software, defined in the 81001 family as software intended to be used specifically for managing, maintaining or improving the health of individual persons, or the delivery of care. That is wider than "medical device software". It covers:

• Software that is itself a medical device, such as a diagnostic algorithm or a dosing calculator.
• Software embedded in a medical device, such as the firmware and applications on an infusion pump or a patient monitor.
• Health software that is not a regulated device in a given market, such as many clinical workflow tools, care coordination platforms, patient engagement apps and health IT systems.

This is deliberate. Hospitals run regulated and unregulated software on the same networks, and an attacker does not care which side of the regulatory line a system sits on. A vendor of unregulated health IT can adopt the standard and show it to hospital buyers as evidence of a secure development process.

The abstract also states what the standard leaves out: it excludes the specification of accompanying documentation contents. It requires that certain security information reach users but leaves the format of those documents to regulators and to other documents, such as the FDA guidance and the MDS2 form.

How is IEC 81001-5-1 structured?

The standard's main clauses follow the process model of IEC 62304, which makes adoption straightforward for teams that already have a 62304 process. The clause headings are:

Informative annexes give rationale, guidance on threat modelling, a mapping to the practices of IEC 62443-4-1, guidance on documents for transition to operation, and an approach for software that was already in the field before the organization adopted the standard (the standard calls this transitional health software).

Why it mirrors IEC 62304

IEC 62304 applies, in the words of its IEC abstract, to the development and maintenance of medical device software when software is itself a medical device or when software is an embedded or integral part of the final medical device. Its consolidated edition (the 2006 first edition plus Amendment 1 of 2015, published 2015-06-26) is the process standard most medical software teams are already audited against. It defines software safety classes A, B and C, a development process, a maintenance process, a risk management process, a configuration management process and a problem resolution process.

IEC 81001-5-1 takes those same five processes and adds security activities to each. A team does not need a second life cycle, only extra inputs, tasks and records in the one it already has.

Why it draws on IEC 62443-4-1

IEC 62443-4-1:2018, "Security for industrial automation and control systems, Part 4-1: Secure product development life-cycle requirements", is published by IEC TC 65 (industrial process measurement, control and automation). Its IEC record shows edition 1.0, published 2018-01-15, 54 pages. It organizes secure development into eight practices: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management, and security guidelines.

IEC 81001-5-1 adapts those practices for health software and maps them in an annex, so a manufacturer selling into industrial and healthcare markets can run one secure development process for two sets of auditors. The FDA guidance makes the same link from the other side: it lists ANSI/ISA 62443-4-1 as a framework from another sector that may also satisfy its quality requirements.

The balance with safety

The abstract asks for an appropriate balance of safety, effectiveness and security, as discussed in ISO 81001-1. A control that locks a clinician out of a ventilator in an emergency, or an update that reboots an infusion pump mid infusion, is a safety hazard. Security risk management feeds into safety risk management under ISO 14971; it does not override it.

What does IEC 81001-5-1 require for SOUP and third-party components?

Third-party software is where most health software risk sits, because most health software is mostly third-party code. A typical connected device or clinical application contains an operating system or runtime, cryptographic libraries, network stacks, UI frameworks, database drivers and hundreds of open source packages pulled in transitively by a package manager.

SOUP in IEC 62304 terms

IEC 62304 calls this software of unknown provenance, or SOUP: software that is already developed and generally available, and that was not developed for the purpose of being incorporated into the medical device, or software previously developed for which adequate records of the development process are not available. Under 62304 a manufacturer identifies each SOUP item by title, manufacturer and version, specifies its functional and performance requirements, specifies the hardware and software it needs, and evaluates anomaly lists published by the SOUP supplier for risk.

That 62304 approach was written for safety. It asks whether a library's known bugs could cause a hazard. It does not, on its own, ask whether a library has known vulnerabilities, whether those vulnerabilities are exploitable in this product, or whether the library will still receive security fixes during the device's service life.

What 81001-5-1 adds

IEC 81001-5-1 adds security tasks to the handling of third-party components. In summary, a conforming manufacturer:

1. Identifies every third-party software item that ships in the product, including transitive dependencies, at a level of detail that allows matching against vulnerability sources.
2. Assesses each item for known vulnerabilities before it is incorporated and before each release, and records the decision for each vulnerability that applies.
3. Considers the security capability and support of each supplier, including whether security fixes are provided and for how long.
4. Monitors third-party items after release for newly disclosed vulnerabilities, and feeds those into the problem resolution process in clause 9.
5. Plans for the case where a third-party item reaches end of support before the health software does.

None of these tasks require the term "SBOM". All of them require one in practice. You cannot monitor components after release for vulnerabilities unless you have a reliable, machine readable list of exactly which components and versions shipped in each release.

How that maps to an SBOM

Here is how the third-party component tasks line up with SBOM data, using the NTIA minimum elements and the extra fields the FDA asks for.

The NTIA report, published in July 2021, groups its minimum elements into data fields, automation support and practices and processes. Automation support means a machine readable format: the report names SPDX, CycloneDX and SWID tags. The practices cover how often to regenerate the SBOM, how deep the dependency tree goes, how to mark "known unknowns", and how to distribute and correct SBOMs.

What does it expect for threat modelling, requirements, coding, testing and post-market handling?

The FDA's own test and documentation list in its 2026 guidance tracks the IEC 62443-4-1 practices closely, and IEC 81001-5-1 sits between the two. Below we describe what each activity means in a health software team. Where we refer to FDA expectations, we quote or paraphrase the guidance text.

Threat modelling and security risk management

Clause 7 sets out a security risk management process, and the development clause expects a threat model as an input to security requirements and architecture. The process runs in five steps: establish the context, identify vulnerabilities, threats and their adverse impacts, estimate and evaluate the risk, control it, and monitor whether the controls work.

The context step is where health software differs from general software. It covers the clinical environment (hospital network, home use, ambulance), the users (clinicians, patients, biomedical engineers, field service staff), the data (health information, therapy settings) and connected systems, plus the security controls a hospital is assumed to provide. Write those assumptions down so they can be passed to users.

Threat modelling then asks, for each interface and data flow, what can go wrong. An infusion pump that accepts drug library updates over Wi-Fi has a threat of an unauthorized library being installed. A cloud dashboard that aggregates patient vitals has a threat of cross-tenant data exposure. A mobile companion app has threats from a compromised phone. The FDA guidance asks that threat modelling be performed throughout the design process and that a rationale be given for the methodology selected; it also asks for traceability between the threat model, the cybersecurity risk assessment, the SBOM and testing.

Security risk is then estimated. Unlike safety risk under ISO 14971, it cannot be estimated from a probability of occurrence, because attackers choose their targets, so most teams combine exploitability with severity of impact. The FDA guidance notes that exploitability is likely to increase over the device lifecycle.

Where a security risk could lead to harm, the output must flow into the safety risk file. That is the bridge between the security and safety processes that the abstract's reference to balancing safety, effectiveness and security is about.

Security requirements and secure design

The development clause expects explicit security requirements, derived from the threat model, the intended use environment and regulatory expectations. Typical requirements in health software include authentication and authorization for each role, session handling, audit logging, integrity checks on software and configuration, encryption of data in transit and at rest, secure update, secure decommissioning, and behaviour on loss of connectivity.

The architecture must then show how those requirements are met, with defence in depth: more than one layer of control between an attacker and a hazard. The design also defines trust boundaries, which interfaces are exposed and to whom, and what each component trusts. Clear trust boundaries are what make later testing and vulnerability analysis tractable, because they tell you which inputs an attacker can actually reach.

Secure implementation

The implementation activity expects secure coding standards to be defined and followed, along with checks that they are followed. In practice that means a written coding standard per language, static analysis in the build, review of security relevant changes, and rules for how third-party components are added. The FDA guidance lists "static and dynamic code analysis, including testing for credentials that are hardcoded, default, easily guessed, and easily compromised" in its vulnerability testing list. It also recommends that manufacturers keep custodial control of device source code throughout the lifecycle, for example through source code escrow or backups.

For third-party components, implementation is where dependency policy lives: which registries are allowed, whether lockfiles are mandatory, whether install scripts may run, how quickly a pinned version must be updated when a fix appears, and who approves a new dependency. These are the controls that keep the SBOM accurate and keep surprises out of it.

Verification and security testing

Before release, IEC 81001-5-1 expects security testing in four categories that come from IEC 62443-4-1: security requirements testing, threat mitigation testing, vulnerability testing and penetration testing. It also expects the independence of testers from developers to be managed. The FDA guidance asks for the same four categories in premarket submissions and spells out what vulnerability testing should include:

• Abuse or misuse cases, malformed and unexpected inputs, including fuzz testing.
• Attack surface analysis.
• Vulnerability chaining.
• Closed box testing of known vulnerability scanning.
• Software composition analysis of binary executable files.
• Static and dynamic code analysis.

For penetration testing, the guidance asks that reports show the independence and technical expertise of testers, the scope, the duration, the methods used and the results. It also asks manufacturers to state who did the testing and how independent they are from the developers. Software composition analysis of the final binaries matters here because it catches components the source SBOM missed: statically linked libraries, vendored code and anything a build step pulled in.

Release, accompanying information and decommissioning

At release the standard expects the security information users need: the assumed security context, required controls in the environment, secure installation and configuration, how to receive updates, and how to decommission without leaking data. The FDA guidance expects cybersecurity labeling that includes the SBOM, and IMDRF N60 treats the SBOM as customer security documentation.

Post-market vulnerability handling

Clause 9 is where most of the long term work happens. It covers receiving notifications about vulnerabilities (from researchers, customers, suppliers and public sources), reviewing them, analysing their impact on each affected release, and addressing them through updates, compensating controls or communication. General requirements in clause 4 add that the organization must have a policy for disclosing security issues and must periodically review how well its defect management works.

This lines up closely with section 524B(b)(1) of the FD&C Act, which requires sponsors of cyber devices to submit "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures". The FDA guidance describes coordinated vulnerability disclosure as covering vulnerabilities found by external parties (including third-party software suppliers and researchers), vulnerabilities found by the manufacturer, and the manufacturer's procedures for telling users and customers.

What is its regulatory status?

IEC 81001-5-1 is a voluntary consensus standard. No regulator makes it mandatory by name. What regulators do is set legal requirements and then point to standards as a way to show those requirements are met.

European Union: MDR and IVDR

The Medical Devices Regulation (EU) 2017/745 and the In Vitro Diagnostic Regulation (EU) 2017/746 contain the binding requirements. MDCG 2019-16 Rev.1 (December 2019, revised July 2020) explains that Annex I section 17.2 of the MDR, and section 16.2 of the IVDR, require that software be "developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation". Other Annex I sections cover IT security measures, protection against unauthorized access and information for users.

When MDCG 2019-16 was written, IEC 81001-5-1 was still in development. Its standards annex lists it under its earlier working designation, ISO/IEC 80001-5-1, with the same subtitle "Activities in the product life-cycle". That annex carries a disclaimer that the standards it lists cannot provide a presumption of conformity unless they are harmonised and published in the Official Journal.

Harmonisation is the key legal question. The European Commission's harmonised standards page explains that harmonised standards for the MDR and IVDR are developed by CEN and CENELEC under standardisation request M/575, issued on 14 April 2021 and amended on 31 January 2023 and 27 May 2024, and that once their references are published in the Official Journal of the European Union, voluntary use of those standards confers a presumption of conformity. The same page lists the Commission Implementing Decisions that publish those references, the most recent for the MDR being Implementing Decision (EU) 2026/1231 of 11 June 2026.

We could not retrieve the annexes of those decisions during research, so we cannot confirm here whether EN IEC 81001-5-1:2022 is among the cited references. Being the state of the art for Annex I section 17.2, which is how the standard is widely used, is a separate point from being harmonised. Before you write "presumption of conformity" in a technical file, check the current consolidated annex of Implementing Decision (EU) 2021/1182 on EUR-Lex.

United States: FDA premarket guidance and section 524B

In the US the binding requirements come from two places: the Quality Management System Regulation in 21 CFR Part 820, which since its revision incorporates ISO 13485:2016 by reference, and section 524B of the FD&C Act for cyber devices.

The FDA guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" was issued on 3 February 2026 under docket FDA-2021-D-1158 and supersedes the version issued on 27 June 2025. It recommends that manufacturers use a Secure Product Development Framework (SPDF), which it describes as "a set of processes that help identify and reduce the number and severity of vulnerabilities in products", and says that using an SPDF is one way to help meet the QMSR. It then names possible frameworks: the medical device specific framework in the Medical Device and Health IT Joint Security Plan (JSP2) and IEC 81001-5-1, and from other sectors ANSI/ISA 62443-4-1. In its section on security architecture it again lists IEC 81001-5-1 among medical device specific frameworks.

So, for the FDA, IEC 81001-5-1 is a named route to an SPDF, not a requirement. The FDA also keeps a database of recognized consensus standards that manufacturers can cite in a declaration of conformity. It was not reachable from our research environment, so we do not quote a recognition number. Before declaring conformity in a 510(k), De Novo or PMA, look the standard up there and note the recognition number and extent of recognition.

Section 524B was added by section 3305 of the Food and Drug Omnibus Reform Act of 2022, enacted on 29 December 2022, and took effect for premarket submissions on 29 March 2023. It defines a cyber device as a device that includes software validated, installed or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. The guidance treats even a brief USB service connection as an ability to connect. For a cyber device, the sponsor must:

1. Submit a plan to monitor, identify and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure (524B(b)(1)).
2. Design, develop and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks (524B(b)(2)).
3. Provide an SBOM, including commercial, open source and off-the-shelf software components (524B(b)(3)).
4. Comply with other requirements the FDA may set by regulation (524B(b)(4)).

How IEC 81001-5-1 lines up with the FDA guidance and 524B

The fit is close but not exact. IEC 81001-5-1 tells you what processes to run; the FDA guidance tells you what evidence to submit and in what form, and adds specifics such as the two extra SBOM fields, the KEV check and the architecture views.

How does it relate to IMDRF guidance?

The International Medical Device Regulators Forum publishes guidance that its member regulators, among them the FDA and the European Commission, draw on. Two documents matter here.

IMDRF/CYBER WG/N60FINAL:2020, "Principles and Practices for Medical Device Cybersecurity", sets out a total product life cycle approach and treats the SBOM as part of the customer security documentation that a manufacturer prepares and provides to device users.

IMDRF/CYBER WG/N73FINAL:2023, "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity", builds on N60. It covers what an SBOM is, how to generate and maintain one, how to share it, and how healthcare providers should use it. Several points are directly useful for an IEC 81001-5-1 program:

• It recommends a component hash as an additional element because it helps map a component to relevant data sources.
• It suggests that life cycle data, such as a component's end-of-support date, be provided as supplemental information because it aids risk management across the total product life cycle.
• It names CycloneDX, SPDX and SWID as the automated SBOM formats.
• It defines Vulnerability Exploitability eXchange (VEX) as a machine readable assertion about the status of a vulnerability in a product, and describes VEX as a complement that tells healthcare providers whether a device is affected by a new vulnerability.
• It notes that an SBOM helps manufacturers track and prepare for software component end of life.

N73 also reuses ISO 81001-1:2021 definitions throughout, which is a sign of how closely the regulators' vocabulary and the 81001 family now line up.

IEC 81001-5-1 compared with IEC 62304, IEC 62443-4-1 and the FDA guidance

The short version: IEC 62304 gives you the life cycle, IEC 62443-4-1 gives you the secure development practices, IEC 81001-5-1 merges the two for health software, and the FDA guidance tells you what evidence of all that a premarket submission should contain.

Step by step: run IEC 81001-5-1 on an existing health software team

The steps below assume a team that already has an ISO 13485 quality system and an IEC 62304 process, builds with standard package managers, and ships a mix of application code and container images or embedded images. Adjust the tools to your stack. Nothing here replaces reading the standard itself.

Step 1: map your existing SDLC to the standard's activities

Start with a gap analysis, not a new process. Take your 62304 procedures and add a column for each security activity. A spreadsheet works. The aim is one row per activity, with the procedure that covers it, the record that proves it, and the gap.

Most gaps cluster around third-party software, threat modelling, security testing and vulnerability intake.

Step 2: write down the security context and threat model

For each product, create a short security context document: intended use environment, users and roles, data handled, external interfaces, assumed environment controls, and the trust boundaries. Then build the threat model from it, listing each interface, the threats against it, the controls, and the residual risk. Link each threat to the security requirements and tests that address it. That traceability is what the FDA guidance asks for and what an auditor will sample.

Step 3: generate an SBOM for every release

Generate the SBOM in the build that produces the release, not afterwards from a developer laptop. Use one format across products; CycloneDX JSON is used below because its tooling covers the most ecosystems, but SPDX works equally well.

For a Node.js service, npm can produce a CycloneDX SBOM natively, or you can use the CycloneDX project's own generator:

# npm's built-in SBOM command (npm 10 or later), production dependencies only
npm ci
npm sbom --sbom-format cyclonedx --omit dev > sbom/app-npm.cdx.json

# Or the CycloneDX project's npm generator
npx --package @cyclonedx/cyclonedx-npm cyclonedx-npm \
  --omit dev \
  --output-file sbom/app-npm.cdx.json

For a Python service, generate from the exact environment you ship:

python -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
pip install cyclonedx-bom
cyclonedx-py environment --output-file sbom/app-py.cdx.json .venv/bin/python

For a Java service built with Maven, add the CycloneDX Maven plugin to the build so every package run writes target/bom.json:

<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>makeAggregateBom</goal>
      </goals>
    </execution>
  </executions>
</plugin>

For a container image or a full source tree, the Safeguard CLI can scan and produce results you keep with the release:

safeguard scan --dir .
safeguard scan --image registry.example.com/clinical-dashboard:4.2.0
# results are written as JSON under ./output

Then validate each SBOM and merge them into one product SBOM with the CycloneDX CLI:

cyclonedx validate --input-file sbom/app-npm.cdx.json --fail-on-errors
cyclonedx validate --input-file sbom/app-py.cdx.json --fail-on-errors
cyclonedx merge \
  --input-files sbom/app-npm.cdx.json sbom/app-py.cdx.json target/bom.json \
  --output-file sbom/product-4.2.0.cdx.json

Store the merged SBOM with the release record in your design history file, and keep every released version's SBOM for as long as that version is in the field.

Package managers cannot see an embedded operating system, a vendored C library, a statically linked codec or radio module firmware. Add those by hand or from the supplier's SBOM, and mark them as such.

Step 4: record support level and end-of-support for each component

The FDA guidance asks, for each component, for the level of support from the component's manufacturer (for example actively maintained, no longer maintained, abandoned) and the end-of-support date. It allows these to be provided in the SBOM or separately, such as in an addendum. IMDRF N73 suggests the same data as supplemental information.

A practical approach is to keep a small, reviewed support register keyed by package URL and merge it into the SBOM as CycloneDX properties. The property names below are an internal convention, not a CycloneDX standard field, so document them in your SBOM procedure.

{
  "pkg:npm/express@4.21.2": { "level": "actively-maintained", "eos": "unknown-no-published-date" },
  "pkg:pypi/requests@2.32.3": { "level": "actively-maintained", "eos": "unknown-no-published-date" },
  "pkg:maven/org.example/legacy-hl7@1.4.0": { "level": "no-longer-maintained", "eos": "2024-06-30" }
}

jq --slurpfile s support-register.json '
  .components |= map(
    . as $c
    | ($s[0][$c.purl] // {level: "unassessed", eos: "unassessed"}) as $x
    | .properties = ((.properties // []) + [
        {name: "internal:support:level", value: $x.level},
        {name: "internal:support:end-of-support", value: $x.eos}
      ])
  )' sbom/product-4.2.0.cdx.json > sbom/product-4.2.0.enriched.cdx.json

# List components nobody has assessed yet
jq -r '.components[]
  | select(any(.properties[]?; .name == "internal:support:level" and .value == "unassessed"))
  | .purl' sbom/product-4.2.0.enriched.cdx.json

Be honest in the register. Many open source projects publish no end-of-support date at all. Write "no published date" and record how you judged support (recent releases, open security advisories handled, a published security policy) rather than inventing a date. For components with a known end of support before your device's own end of support, record the plan the FDA asks for: how the component will be updated or replaced.

Step 5: assess known vulnerabilities, including KEV entries

Match the SBOM against vulnerability data before every release and record a decision for each match. The FDA guidance asks manufacturers to identify all known vulnerabilities associated with the device and its components, including those in CISA's Known Exploited Vulnerabilities catalog, and for each one to give a safety and security risk assessment and the risk controls applied.

Run the scanner against the SBOM you just produced:

safeguard scan --sbom sbom/product-4.2.0.cdx.json

Then cross check the CVE identifiers your scan reports against the KEV catalog, which CISA publishes as a JSON feed:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' | sort -u > kev.txt

# cves.txt: one CVE ID per line, exported from your scan results
sort -u cves.txt | comm -12 - kev.txt > kev-hits.txt
wc -l kev-hits.txt

For each finding, record whether the vulnerable code is present and reachable in your product, the exploitability given your architecture, the potential harm, and the decision: fix now, fix in the next regular cycle, mitigate with a compensating control, or accept with justification. Reachability analysis helps here because a vulnerability in a function your product never calls is a different risk from one sitting on an exposed network interface, but write down the reasoning either way. Where you conclude a product is not affected, a VEX statement is the machine readable way to say so to customers, as IMDRF N73 describes.

Step 6: set up vulnerability intake and coordinated disclosure

Clause 9 and section 524B(b)(1) both need a way for outsiders to report vulnerabilities and a procedure for handling them. A minimal setup:

1. Publish a vulnerability disclosure policy on your website: scope, how to report, what reporters can expect, and safe harbour language agreed with legal.
2. Publish a security.txt file at /.well-known/security.txt with a monitored contact, following RFC 9116 (Contact and Expires are the required fields).
3. Create an intake queue separate from general complaints, with a named owner and a backup.
4. Define triage timelines (for example acknowledge within a few business days, initial assessment within a set period) and track them.
5. Subscribe to supplier security notices for every commercial component in the SBOM, and to advisory feeds for the open source ecosystems you use.
6. Route every confirmed product vulnerability into the problem resolution process, and link it to the CAPA process in your QMS where it meets your criteria.
7. Decide in advance how you will notify customers: advisories, VEX documents, direct notices to hospital biomedical and IT teams.

A minimal security.txt:

Contact: mailto:product-security@example-health.com
Expires: 2027-10-31T00:00:00.000Z
Policy: https://example-health.com/security/disclosure-policy
Preferred-Languages: en
Canonical: https://example-health.com/.well-known/security.txt

Step 7: gate releases in CI

Turn the steps above into a release gate so they happen every time, not when someone remembers. A minimal GitHub Actions job for a Node.js service:

name: release-security-gate
on:
  push:
    tags: ["v*"]
jobs:
  sbom-and-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: npm ci
      - name: Generate CycloneDX SBOM
        run: |
          mkdir -p sbom
          npm sbom --sbom-format cyclonedx --omit dev > sbom/app.cdx.json
      - name: Enrich with support register
        run: |
          jq --slurpfile s support-register.json '
            .components |= map(. as $c
              | ($s[0][$c.purl] // {level: "unassessed", eos: "unassessed"}) as $x
              | .properties = ((.properties // []) + [
                  {name: "internal:support:level", value: $x.level},
                  {name: "internal:support:end-of-support", value: $x.eos}]))' \
            sbom/app.cdx.json > sbom/app.enriched.cdx.json
      - name: Fail if any component is unassessed
        run: |
          n=$(jq '[.components[] | select(any(.properties[]?;
                .name == "internal:support:level" and .value == "unassessed"))] | length' \
                sbom/app.enriched.cdx.json)
          echo "Unassessed components: $n"
          test "$n" -eq 0
      - uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.ref_name }}
          path: sbom/

Add your vulnerability scan and policy evaluation as further steps. The gate does not make decisions for you; it makes sure the inputs to the decision exist.

Step 8: monitor what is already in the field

After release, re-check every supported version's SBOM against new vulnerability data on a fixed schedule, and immediately when a high profile vulnerability lands. This is where most teams fall down, because the work does not belong to any feature team. Assign it, schedule it, and record each run, including the runs that found nothing. Under 524B(b)(2) you also need a justified regular patch cycle and an out of cycle path for critical vulnerabilities, so tie the monitoring output directly to the release plan.

What about software already in the field?

IEC 81001-5-1 includes an informative annex for transitional health software: software released before the organization adopted the standard. It is a realistic acknowledgement that nobody can retrofit a full secure development history onto a product designed years ago. The practical approach is to do what can still be done: build an SBOM from the shipped binaries, assess known vulnerabilities, write a threat model of the product as it is deployed, define compensating controls for weaknesses that cannot be fixed, and put the product under the post-market monitoring and problem resolution processes from now on. Record the gaps rather than hiding them, and give customers the information they need to protect the product with network controls.

Common mistakes

• Running a second life cycle. Teams write a separate "security SDLC" that nobody follows. IEC 81001-5-1 is designed to extend the 62304 process. Put the security tasks into the procedures people already use.
• Treating the SBOM as a submission artifact. An SBOM generated once for a premarket submission and never updated is not what the FDA guidance describes. It asks for an SBOM maintained as part of configuration management and updated with each change.
• Missing components outside the package manager. Operating systems, vendored code, statically linked libraries and radio firmware are often absent from source SBOMs. Binary software composition analysis and supplier SBOMs fill that gap.
• Inventing end-of-support dates. If a project has not published one, say so and record how you judged support. A made up date is worse than an honest "no published date".
• Equating "vulnerable component present" with "device vulnerable". Record reachability and exploitability reasoning for each finding. Equally, do not dismiss a finding without written reasoning.
• No public reporting channel. Without a monitored contact and a disclosure policy, the clause 9 and 524B(b)(1) obligations cannot be met, however good the internal process is.
• Claiming presumption of conformity without checking the Official Journal. Being the state of the art and being a harmonised standard are different things. Check the current list before you write it in a technical file.
• Ignoring the build pipeline. The standard's goal includes making the life cycle processes themselves more secure. Uncontrolled access to build servers and signing keys undermines everything else.

FAQ

Is IEC 81001-5-1 mandatory?

No standard is mandatory by name in the EU MDR or under FDA rules. The legal requirements are in the regulations and, for US cyber devices, section 524B. IEC 81001-5-1 is a recognised way to show you meet them. In the EU it represents the state of the art for secure health software development; in the US the FDA names it as a possible Secure Product Development Framework.

When was IEC 81001-5-1 published?

The IEC published edition 1.0 on 16 December 2021. The European adoption is EN IEC 81001-5-1:2022. A corrected version including Interpretation Sheet 1 (December 2025) is now sold by the IEC.

Does IEC 81001-5-1 apply to software that is not a medical device?

Yes. Its scope is health software, which includes regulated medical device software and health software that is not regulated as a device, such as many health IT systems. Unregulated vendors often adopt it to answer hospital security questionnaires.

What is the difference between IEC 62304 and IEC 81001-5-1?

IEC 62304 defines the software life cycle for medical device software with a focus on safety. IEC 81001-5-1 adds security activities to each of the same processes and widens the scope to all health software. Most teams run both, with 81001-5-1 layered on top of 62304.

Does IEC 81001-5-1 require an SBOM?

It requires you to identify, assess and monitor third-party software components, which in practice means a machine readable SBOM. The FDA requires an SBOM for cyber devices under section 524B(b)(3), and its guidance asks for each component's support level and end-of-support date.

Is IEC 81001-5-1 an FDA recognized consensus standard?

The FDA guidance names it as a possible framework for an SPDF. Recognition status and the recognition number are recorded in the FDA Recognized Consensus Standards database, which you should check directly before declaring conformity in a submission.

Is EN IEC 81001-5-1 a harmonised standard under the MDR?

Check the Official Journal. The Commission's harmonised standards page lists the implementing decisions that publish MDR and IVDR references, most recently Implementing Decision (EU) 2026/1231 for the MDR. Only a reference published there gives a presumption of conformity.

How does IEC 81001-5-1 relate to IEC 62443-4-1?

IEC 81001-5-1 is designed to support conformance to IEC 62443-4-1 while addressing health software needs, and it maps its activities to the 62443-4-1 practices in an annex. Both use the same four security test categories.

What SBOM format should a medical device manufacturer use?

The FDA asks for a machine readable SBOM and encourages industry-accepted formats. IMDRF N73 names CycloneDX, SPDX and SWID. CycloneDX and SPDX JSON are the most common choices, and conversion between them is possible with the CycloneDX CLI.

How often should we update the SBOM?

With every change to the software that ships, as part of configuration management. The FDA guidance says the SBOM should be regularly updated to reflect changes to software in marketed devices.

Where Safeguard fits

Safeguard does not certify conformance to IEC 81001-5-1, write threat models, run penetration tests or prepare FDA submissions. What it does cover is the third-party component work that sits at the centre of the standard: scanning repositories, container images and SBOM files for dependencies and known vulnerabilities, showing which projects contain a given component and version when a new vulnerability lands, ranking findings with reachability analysis, evaluating policies and gates before release, and opening fix pull requests through autonomous remediation, which ships switched off so your team decides how much runs on its own. The Safeguard CLI's assistant can also edit code and run commands with your approval, which suits the controlled change process a medical software team needs. Support levels, end-of-support dates and the clinical risk decisions remain your records to keep.

The dependency work above is where health software teams spend most of their post-market effort, because every release pulls in open source components that keep receiving advisories long after the device ships. These are the options for closing that gap without waiting on a maintainer's release schedule.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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. You ask it to fix a lodash CVE; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and prints a summary without pushing anything. For a health software team that is a controlled dependency change under clause 6 maintenance: a human approves each step, and the summary becomes part of the change record.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and scans from the terminal. That is the shape of the post-market monitoring job in step 8: scans of every supported release, run on infrastructure you control, which matters when source code and builds must stay inside your quality system boundary.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. When a vulnerability notice arrives through your clause 9 intake, a product security lead can ask in plain language which projects contain the affected component version, then check that answer against the release SBOMs before deciding what to tell customers.

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

To try it on your own code, download Safeguard and follow the CLI documentation.

Quick check

Sources

• IEC webstore: IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security, Part 5-1
• IEC webstore: IEC 62304:2006+AMD1:2015 consolidated version
• IEC webstore: IEC 62443-4-1:2018
• FDA: Cybersecurity in Medical Devices, Quality Management System Considerations and Content of Premarket Submissions (guidance page)
• FDA: Cybersecurity in Medical Devices guidance, full text (PDF, issued 3 February 2026)
• 21 U.S.C. 360n-2, Ensuring cybersecurity of devices (section 524B of the FD&C Act)
• IMDRF/CYBER WG/N73FINAL:2023, Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity (PDF hosted by PMDA)
• MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices
• European Commission: Harmonised standards for medical devices and IVDs
• NTIA: The Minimum Elements for a Software Bill of Materials (July 2021)
• CISA: Known Exploited Vulnerabilities Catalog
• npm Docs: npm sbom
• CycloneDX: cyclonedx-node-npm
• CycloneDX: cyclonedx-python
• CycloneDX: cyclonedx-maven-plugin
• CycloneDX: cyclonedx-cli
• CycloneDX 1.6 JSON reference
• SPDX specifications
• CycloneDX Python tool usage documentation
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure

Last reviewed: 24 October 2026. Harmonised standard listings and FDA recognition records change; check the Official Journal and the FDA Recognized Consensus Standards database for the current status.