ISO 14971 for software and IEC 81001-5-1 in 2026: a team guide
TL;DR
ISO 14971 for software means the development team feeds a safety risk file: hazards traced to software items, risk controls written as requirements, and tests that prove each control works. IEC 81001-5-1, recognized by the FDA since December 19, 2022, adds a parallel security lifecycle with threat modeling, secure coding, security testing and patch delivery. Section 524B of the FD&C Act turns part of that lifecycle into law for cyber devices.
- The FDA's February 3, 2026 cybersecurity guidance names IEC 81001-5-1 as a possible secure product development framework.
- The same guidance says security risk management is distinct from ISO 14971 safety risk management.
- Section 524B(b)(3) requires an SBOM for cyber devices, and the FDA counts Bluetooth as a way to connect.
- In a sprint the evidence is ordinary work: a risk-tagged story, an updated threat model, a regenerated SBOM, a traced test.
Two standards, two risk files, one codebase
ISO 14971:2019 is the risk management standard for medical devices, software included. ISO lists it as the third edition, published in December 2019 and last reviewed and confirmed in 2025. It makes the manufacturer set objective risk acceptability criteria and does not set acceptable risk levels itself.
IEC 81001-5-1:2021 covers the other side: can someone attack this software? It defines life cycle requirements for developing and maintaining health software and supports conformance with IEC 62443-4-1. The Johner Institute describes it as IEC 62443-4-1 tailored to health software, layered on a lifecycle already defined by IEC 62304.
The FDA recognizes both. Its Recognized Consensus Standards database lists ISO 14971:2019 as recognition number 5-125, entered December 23, 2019, and IEC 81001-5-1 as 13-122, entered December 19, 2022. Both carry complete recognition, so a submission can declare conformity instead of defending its method.
The two files meet in your code: a tampered dosing schedule is a security event and a patient hazard at once.
How these two standards sit next to HIPAA and ISO 27001 is shown in our comparison of healthcare compliance standards.
What changed in the eight months to July 2026
In December 2025 the IEC published a corrected version of IEC 81001-5-1 that includes Interpretation Sheet 1, according to its webstore listing. An IntuitionLabs crosswalk summarizes what the sheet settles: clauses 6.3.2 and 6.3.3, security update delivery and integrity, apply only to maintained software. A full revision has also started. iTeh Standards lists a new project to revise the 2021 edition, opened on September 22, 2025.
On February 3, 2026 the FDA issued Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, replacing the June 27, 2025 version. It ties security to the Quality Management System Regulation, which incorporates ISO 13485:2016 by reference. It also lists IEC 81001-5-1 as a framework you may use for a secure product development framework, or SPDF.
On July 29, 2026 CISA and the NSA published the 2026 Minimum Elements for a Software Bill of Materials. It builds on the 2021 NTIA elements and adds fields such as SBOM Author Signature, SBOM Version and Component Hash Value. The FDA guidance predates it and still points to the older baseline attributes. If your SBOM tool already computes hashes, emit the new fields now.
How we built this guide
We read the instruments rather than summaries of them: the statutory text of Section 524B, the FDA's February 2026 cybersecurity guidance and June 2023 software submissions guidance, the FDA standards database, and the ISO and IEC catalog pages. Clause numbers come from the published table of contents of IEC 81001-5-1. The case study review covers every page Mercury Development publishes in its portfolio, and any group with fewer than three data points is not published.
ISO 14971 and IEC 81001-5-1 at a glance
| Question | ISO 14971:2019 | IEC 81001-5-1:2021 |
|---|---|---|
| What it manages | Safety risk: harm to people, property or the environment | Security risk: threats, vulnerabilities and their impact |
| How risk is estimated | Severity and probability | Exploitability, per FDA guidance |
| Scope | Medical devices, software included | Health software, device or not |
| Lifecycle it plugs into | The whole device, through post-production | IEC 62304 processes, clauses 5 to 9 |
| FDA recognition | 5-125, December 23, 2019 | 13-122, December 19, 2022 |
| Typical artifacts | Risk management plan, hazard analysis, risk management report | Threat model, security requirements, security test reports, SBOM, maintenance plan |
| FDA-recognized companions | IEC TR 80002-1 (13-34) | AAMI TIR57 (13-83), ANSI/AAMI SW96 (13-131) |
What the development team does under ISO 14971
A quality lead usually owns the risk management file. Engineers produce most of what goes into it.
- Hazard analysis input. Engineers know where software fails: a wrong value displayed, stale data shown as current, a sync that drops a reading without telling anyone.
- Severity first. IEC 62304 treats software defects as occurring with 100% probability, as the Johner Institute explains, so software risk is argued on severity and on controls. A control that cuts the fault tree higher up, ideally outside the same software system, beats one more check in the same module.
- Controls as requirements. A risk control implemented in software becomes a requirement with an ID, a design element and a test. Untraced, it does not count.
- Proof that controls work. The FDA's June 2023 guidance on device software functions asks for a risk management file with a plan, a risk assessment "demonstrating that risks have been appropriately mitigated" and a risk management report.
- Change impact. Every change request gets one question: does this create a hazard or weaken a control? ISO 14971:2019 puts more weight on production and post-production information, so field defects come back to the same file.
What IEC 81001-5-1 adds to an IEC 62304 lifecycle
IEC 81001-5-1 does not replace your lifecycle. Its clauses 5 to 9 follow the IEC 62304 process names, and the new work sits inside them.
- 5.1.2 and 5.1.3: development environment security and secure coding standards, settled at planning.
- 5.2.1 to 5.2.3: security requirements, a review of them, and security risks for required software.
- 5.3.1 to 5.3.3: defense-in-depth architecture and a security architecture review.
- 5.7.1 to 5.7.4: security requirements testing, threat mitigation testing, vulnerability testing and penetration testing.
- 5.7.5: managing conflicts of interest between testers and developers.
- 5.8.3 and 5.8.4: file integrity and controls for private keys at release.
- 6.1.1 and 6.2.1: timely security updates and monitoring of public incident reports.
- 9.2 to 9.5: receiving, reviewing, analysing and addressing vulnerability reports.
Clause 4.3 classifies software items by who carries the risk after release: maintained, supported or required software. Classify a BLE stack that you vendor into the app and patch yourself as maintained, and clauses 6.3.2 and 6.3.3 apply to every fix you ship for it.
How Section 524B and the SBOM tie the two together
Section 524B, codified at 21 U.S.C. 360n-2, applies to a cyber device: one that includes the sponsor's software, "has the ability to connect to the internet" and could be vulnerable to cybersecurity threats. It took effect for premarket submissions on March 29, 2023. The FDA reads the connection test broadly. Its guidance names Wi-Fi, cellular, Bluetooth and Bluetooth Low Energy, plus USB, ethernet and serial connectors.
For a cyber device the sponsor must:
- submit a plan to monitor and address postmarket vulnerabilities "in a reasonable time," including coordinated vulnerability disclosure;
- keep processes that give reasonable assurance the device is cybersecure, with patches on a regular cycle and critical fixes out of cycle;
- provide an SBOM "including commercial, open-source, and off-the-shelf software components."
The FDA guidance fills in the engineering. It wants a machine-readable SBOM with each component's level of support and end-of-support date. It wants four kinds of architecture view: global system, multi-patient harm, updateability and patchability, and security use cases. And it wants "traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation."
This is where the two standards meet. The FDA says security risk management "is distinct from performing safety risk management as described in ISO 14971," because it rests on exploitability rather than probability. AAMI TIR57 and ANSI/AAMI SW96, both FDA-recognized, describe the interface. A security risk that can reach a patient becomes a hazard in the ISO 14971 file, with a pointer back to the threat that causes it.
Which artifacts appear in a sprint
Neither standard mentions sprints. AAMI TIR45:2023, FDA-recognized since May 26, 2025, covers agile practice for medical device software. The working rule: evidence is a side effect of normal work, never a phase at the end.
| When | Team activity | Artifact | Where the duty comes from |
|---|---|---|---|
| Backlog refinement | Hazard and threat check on each story | Entries in the risk file and the threat model | ISO 14971 risk analysis; IEC 81001-5-1 7.2 |
| Story with a control | Control written as a requirement | Requirement ID traced to design and test | ISO 14971 risk control; IEC 81001-5-1 5.2.1 |
| Design change | Threat model and architecture views updated | Reviewed diagram and review record | FDA architecture views; IEC 81001-5-1 5.3.3 |
| Coding | Secure coding standard, peer review | Review record, static analysis findings closed or justified | IEC 81001-5-1 5.1.3 and 5.5.2 |
| Every CI build | SBOM regenerated from lockfiles | Machine-readable SBOM with support level and end-of-support date | Section 524B(b)(3); FDA guidance |
| New dependency | Support status and known vulnerabilities checked | SBOM entry and SOUP record | IEC 81001-5-1 4.1.5; IEC 62304 SOUP |
| Sprint testing | Security requirement and threat mitigation tests | Traced test results | IEC 81001-5-1 5.7.1 and 5.7.2 |
| Release candidate | Vulnerability and penetration testing by people who did not write the code | Test reports that name who tested | IEC 81001-5-1 5.7.3 to 5.7.5; FDA guidance |
| Release | Findings resolved or justified, build signed | Unresolved anomalies list, signed artifacts, updated risk management report | IEC 81001-5-1 5.8.1 and 5.8.3; FDA June 2023 guidance |
| After release | Incident reports and the CISA KEV catalog watched, patches shipped | Vulnerability log and patch records | IEC 81001-5-1 6.2.1; Section 524B(b)(2) |
Most of this fits in a pull request template with three checkboxes: new hazard, new threat, new dependency. The SBOM job runs in CI whether anyone remembers it or not.
Which setup fits your product
- Wellness app with no device claims: neither standard is mandatory. IEC 81001-5-1 still fits, because its scope is health software in general.
- Cloud software as a medical device: ISO 14971 and IEC 62304 from day one. It connects to the internet, so Section 524B applies, and the SBOM should cover server components too.
- Companion app for a Bluetooth device: a cyber device under the FDA's reading. The SBOM spans firmware, the phone app and the cloud, and phone OS updates belong in the maintenance plan.
- Device maker hiring a software vendor: the vendor works inside your quality system. Clause 4.1.5 covers software items from third-party suppliers, so agree up front who delivers the threat model, the SBOM and the test reports.
- Machine learning inside a device: ISO 14971 still governs, and AAMI CR34971:2022, FDA recognition 13-124, applies it to AI.
Our medical device software development guide covers IEC 62304 safety classes and FDA pathways. The IEC 62304 compliance cost article prices the documentation line by line.
What our Bluetooth case studies show about third-party code
None of the cases below is a medical device. The cleared product in our portfolio, EyeIC's MatchedFlicker, a 510(k) FDA-cleared application, moved to the web in 2011, a decade before IEC 81001-5-1 existed. So we looked at the boundary both standards care about: your code against code you do not control.
Around 20% of the case studies Mercury Development publishes involve Bluetooth hardware. In most of them, the hard part sat in a third-party component:
- Kensington Proximo: Android had no built-in BLE support at the time, so the team relied on a Samsung SDK "provided as a pre-release beta version, which was partially unstable."
- ORIGO: "The manufacturer's driver was unstable, so we wrote our own."
- Fitbit: early Android lacked Bluetooth 4.0, and the team spent two months deciphering Samsung's proprietary technology to sync trackers.
Read those through the FDA's SBOM fields. A pre-release vendor SDK has a level of support nobody can state and an end-of-support date nobody has published. A replaced driver moves from the third-party column into code you maintain, so the SBOM, the threat model and the clause 4.3 classification change in the same pull request. Dependency decisions are risk decisions, and they get made in sprints.
Where BLE testing fits in a submission is covered in our guide to medical device companion app development.
Our view: one backlog, two registers
Keep two registers and one backlog. Merging security risks into the ISO 14971 table looks tidy and breaks on the first review question, because the FDA wants a security assessment built on exploitability, and a probability column has nowhere to put it. Splitting the backlog is worse. Security work drifts into a hardening sprint before release, and the threat model ends up describing a product that no longer exists.
Link them instead. Every security risk that can reach a patient points to a hazard in the safety file, and every story carries both checks. If a reviewer can follow one story from hazard to threat to requirement to test to SBOM entry, both standards have done their job.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The review of Bluetooth integrations in Mercury's published case studies belongs to the integration and architecture decisions his practice is responsible for.
Send your architecture and get both registers started
Send a diagram of your device, app and cloud, plus your dependency list. We will mark what makes the product a cyber device, draft the first hazard and threat entries, and list the SBOM gaps your team should close before the next release.