IEC 81001-5-1 vs IEC 62304 for Medical Devices

Part of our medtech cybersecurity framework choice series (SPDF, JSP2, IEC 81001-5-1). For the full overview, start with JSP2 vs SPDF vs IEC 81001-5-1: Framework Pick.

The two standards get confused because they use overlapping vocabulary (lifecycle, activities, verification, maintenance) and because a healthy chunk of IEC 81001-5-1 is written to slot directly onto IEC 62304's structure. Companies that already run IEC 62304 sometimes assume it covers security. It does not. Companies adopting IEC 81001-5-1 sometimes assume it replaces IEC 62304. It does not do that either.

This post lays the two standards side by side so the division of labor is unambiguous.

Key Takeaways

• IEC 62304 governs the safety-focused software lifecycle; IEC 81001-5-1 governs the security-focused lifecycle that runs alongside it.
• IEC 81001-5-1 was written to plug into IEC 62304 structurally, not to replace it.
• The FDA accepts either as inputs to a submission; the EU expects both under the MDR and IVDR.
• IEC 62304 alone does not satisfy 524B or the 2026 FDA final guidance's security expectations.
• IEC 81001-5-1 alone does not satisfy IEC 62304's software safety obligations.
• The pairing is what most notified bodies and 510(k) reviewers actually want to see.

Table of Contents

• Key Takeaways
• Why This Matters
• What IEC 62304 covers
• What IEC 81001-5-1 covers
• Side-by-side coverage map
• Where the two standards overlap
• How the pair maps to the FDA and EU expectations
• How to adopt them together without duplicating work
• How Blue Goat Cyber Approaches This
• Frequently Asked Questions
• CTA

Why This Matters

Getting the boundary wrong costs real money. Teams that treat IEC 62304 as sufficient for cybersecurity end up rebuilding threat models, vulnerability handling, and postmarket security plans the first time an FDA deficiency letter or an EU notified-body finding lands. Teams that adopt IEC 81001-5-1 without a working IEC 62304 program end up with security artifacts floating above a software lifecycle they cannot audit.

The 2026 FDA final premarket cybersecurity guidance names IEC 81001-5-1 explicitly as an acceptable secure-development framework, and the EU MDR and IVDR treat both standards as harmonized expectations. Neither regulator is asking you to pick between them.[^fda2026] They expect both, in the roles each was designed for.

What IEC 62304 covers

IEC 62304:2006+A1:2015, Medical device software — Software life cycle processes, is the international standard for the safety-focused software lifecycle. It applies to any software that is itself a medical device or is embedded in one. IEC 62304 defines:[^iec62304]

• Software safety classification (Class A, B, C) based on the potential harm from failure.
• Software development planning and the software development plan artifact.
• Software requirements analysis with traceability to system requirements.
• Software architectural design, including the identification of SOUP (software of unknown provenance).
• Software detailed design, implementation, and unit verification (obligations scale with safety class).
• Software integration, integration testing, and system testing.
• Software release, including known-anomalies documentation and archived configuration.
• Software maintenance process, including change control and problem resolution.
• Software risk management process, integrated with ISO 14971.
• Software configuration management and software problem resolution.

IEC 62304 mentions security only in passing. It is not a security standard. It is a software safety and quality standard.

What IEC 81001-5-1 covers

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, is the international standard for security activities in the health-software lifecycle. It was authored specifically to slot on top of IEC 62304 and to align with ISA/IEC 62443-4-1 on secure-development practice. IEC 81001-5-1 defines:[^iec81001]

• Secure development process establishment, including roles, training, and process definition.
• Security requirements, including secure-by-design and secure-by-default expectations.
• Threat modeling as a required activity, with harm-oriented outputs feeding risk management.
• Secure implementation practices, including coding standards and static analysis.
• Security verification and validation, including penetration testing where warranted.
• Third-party component management, including SBOM-adjacent obligations for known vulnerabilities.
• Security release criteria, including residual-risk acceptance.
• Postmarket vulnerability management, including coordinated vulnerability disclosure (CVD) and patching.
• Security incident response and communication with health-delivery organizations.
• Security maintenance across the supported lifespan of the device.

IEC 81001-5-1 says almost nothing about software safety classification, unit verification, or SOUP. That is IEC 62304's job.

Side-by-side coverage map

Activity area	IEC 62304	IEC 81001-5-1
Software safety classification (Class A/B/C)	Owns	Not covered
Software development planning	Owns	Adds security plan alongside
Software requirements	Owns (functional / safety)	Adds security requirements
Architectural design	Owns	Adds threat modeling on the same architecture
Implementation and unit verification	Owns	Adds secure-coding and static analysis
Integration and system testing	Owns	Adds security verification / pen testing
SOUP identification and evaluation	Owns	Extends into SBOM-style component monitoring
Release	Owns (safety readiness)	Adds security release criteria
Software risk management	Owns, integrated with ISO 14971	Adds security risk to the same risk file
Change and configuration management	Owns	Adds security-impact review of changes
Problem resolution	Owns (safety anomalies)	Adds vulnerability handling and CVD
Postmarket maintenance	Owns (safety patches)	Adds security patching and incident response
Threat modeling	Not covered	Owns
Coordinated vulnerability disclosure	Not covered	Owns
Postmarket security monitoring	Not covered	Owns

The pattern is consistent: IEC 62304 owns the software lifecycle and safety mechanics; IEC 81001-5-1 layers security expectations onto every phase where security materially matters, and adds the security-only activities (threat modeling, CVD, postmarket vulnerability response) that IEC 62304 was never intended to cover.

Aligning IEC 62304 and 81001-5-1 evidence?

Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. → Secure MedTech product design consulting

Where the two standards overlap

The overlap is deliberate and useful, not redundant.

• Risk management. IEC 62304 requires software risk management integrated with ISO 14971. IEC 81001-5-1 requires security risk to be integrated into the same risk file, so a single ISO 14971-shaped record covers safety and security together. AAMI TIR57 and, more recently, AAMI SW96 formalize this integration.
• Requirements traceability. Both standards demand that requirements trace to design, verification, and release evidence. IEC 81001-5-1 assumes the traceability spine that IEC 62304 already sets up.
• Configuration and change management. IEC 62304 requires it for the software baseline; IEC 81001-5-1 requires a security-impact assessment on every change to that baseline.
• Problem resolution. IEC 62304's problem resolution process is the vehicle IEC 81001-5-1 uses to route vulnerability reports and CVD findings.

The overlap is where the two standards are most efficient. Every artifact IEC 81001-5-1 needs already has a home in the IEC 62304 process, if the team is already running one.

Talk to a MedTech cybersecurity expert about IEC 81001-5-1 adoption

How the pair maps to the FDA and EU expectations

See also: IEC 81001-5-1 vs AAMI SW96, AAMI TIR57 vs TIR97 vs SW96, and MedTech Cyber Standards Every Device.

For the FDA (2026 final premarket guidance):¹

• IEC 62304 satisfies the software-lifecycle expectations that show up in the software documentation section of a 510(k), De Novo, or PMA submission.
• IEC 81001-5-1 satisfies the secure-development framework requirement (one of the four the FDA lists), plus the threat model, SBOM handling, security testing, and postmarket cybersecurity management plan requirements.
• Together the pair covers the software half of a submission cleanly. The remaining artifacts (labeling, interoperability considerations, cybersecurity management plan) sit on top of that pair.

For the EU (MDR and IVDR):

• IEC 62304 is a harmonized standard for medical-device software lifecycle. Notified bodies expect it.
• IEC 81001-5-1 is the security lifecycle standard notified bodies point to when reviewing MDR Annex I Section 17 (electronic programmable systems) and IVDR equivalents.
• The pairing is the least-friction path through most European notified-body reviews.

For a submission with dual scope: IEC 62304 + IEC 81001-5-1 is the standard combination the industry has settled on. See our JSP2 vs SPDF vs IEC 81001-5-1 framework choice post for how this pair compares against the alternatives.

How to adopt them together without duplicating work

Three rules keep the adoption clean:

1. Extend, do not duplicate. Every IEC 81001-5-1 activity should attach to an existing IEC 62304 process step, not create a parallel one. Add a security-requirements section to the same requirements document; add a threat-modeling step to the same architecture review; add security release criteria to the same release checklist.
2. Merge the risk file. Do not maintain a separate safety risk file and security risk file. Use ISO 14971 as the container and follow AAMI SW96 or AAMI TIR57 for the integration pattern. A single risk file also survives audits better because reviewers can trace one thread instead of two.
3. Reuse the SDLC's problem-resolution process for CVD. IEC 62304 already requires a documented problem-resolution process. Route vulnerability disclosures through it, with a security-impact tag on the ticket, rather than standing up a parallel security ticketing system.

How Blue Goat Cyber Approaches This

Blue Goat Cyber's IEC 81001-5-1 adoption engagement starts with an audit of the client's existing IEC 62304 processes. The output is a delta plan: exactly which IEC 62304 documents need security additions, which activities need to be inserted, and which artifacts need to be produced for the first time. For teams running IEC 62304 well, the delta is usually shorter than expected. For teams that are not, we scope IEC 62304 remediation into the same engagement so the security layer has something to attach to.

Christian Espinosa, our founder, has led IEC 81001-5-1 adoption on more than 40 devices, spanning US 510(k), De Novo, and EU MDR submissions. Every engagement carries the same commitment: if the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

Frequently Asked Questions

Does IEC 81001-5-1 replace IEC 62304?

No. IEC 81001-5-1 was designed to sit on top of IEC 62304, not replace it. The two standards cover different scopes: IEC 62304 is the software lifecycle, IEC 81001-5-1 is the security lifecycle. Teams need both.

Is IEC 62304 enough for the FDA's cybersecurity expectations?

No. IEC 62304 barely mentions security. The 2026 FDA final premarket cybersecurity guidance requires a secure-development framework (SPDF, JSP2, IEC 81001-5-1, or ISA/IEC 62443-4-1), a threat model, an SBOM with VEX, and a postmarket cybersecurity management plan. None of those come from IEC 62304.

If I run IEC 81001-5-1, do I still need SPDF?

No, they are alternatives. The FDA lists SPDF, JSP2, IEC 81001-5-1, and ISA/IEC 62443-4-1 as four acceptable frameworks; you pick one as the spine. See the framework choice post for how to choose.

What about IEC 82304-1?

IEC 82304-1 is the health-software product-level safety standard. It sits above IEC 62304 (which covers the lifecycle) and is complementary to both IEC 62304 and IEC 81001-5-1. Standalone health software (some SaMD) needs 82304-1 as well.

How does AAMI SW96 relate to this pair?

AAMI SW96:2023 is the security risk management standard. It formalizes the integration of security risk into ISO 14971 that IEC 81001-5-1 assumes. Most teams adopting IEC 81001-5-1 also implement SW96 to keep the risk file coherent.

Are IEC 62304 and IEC 81001-5-1 harmonized in the EU?

IEC 62304 is a harmonized standard under the MDR. IEC 81001-5-1 is widely treated by notified bodies as the expected security lifecycle standard even though harmonization status has evolved. The safe operating assumption is that both are expected for MDR and IVDR software submissions.

CTA

Adopt the pair once, correctly. Blue Goat Cyber runs a four-week IEC 81001-5-1 on-boarding engagement that plugs into an existing IEC 62304 QMS, produces a delta document set, and readies the security artifacts an FDA or notified-body reviewer expects. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Book a discovery session.

Christian Espinosa, Founder, Blue Goat Cyber. CISSP, CCISO, ex-military red team. Has led IEC 81001-5-1 and IEC 62304 alignment on 40+ FDA- and EU-cleared devices. More on the author.

References

Footnotes

1. U.S. Food and Drug Administration. Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions — Guidance for Industry and Food and Drug Administration Staff. Final guidance, issued February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions ↩