--- title: "IEC 62304 Edition 2 for Medical Device Firmware | Compen Embedded" description: "Where the IEC 62304 revision stands, what the draft changes (health software scope, process rigour levels instead of safety classes A/B/C, security, AI) and what embedded teams should do now." image: "https://compen.net/og-image.jpg" --- # IEC 62304 Edition 2: what the revision means for medical device firmware IEC 62304 is getting its first major revision since 2006\. The draft second edition replaces the familiar software safety classes A, B and C, widens the scope from medical device software to all health software, and puts security inside the software lifecycle. Here's where the revision stands, what the draft changes, and what it means for teams building medical device firmware. Compen Embedded · 2 November 2026 · 8 min read ## Key points - Edition 2 is **not published yet**. The second Committee Draft (62A/1761/CD) was circulated on 7 August 2026; comments close on 27 November 2026\. The IEC forecasts publication for October 2028. - Until then, **IEC 62304:2006 + Amendment 1:2015** (often called Edition 1.1) is the version to comply with. - The biggest change: software safety classes A, B and C make way for two **software process rigour levels**, I and II. - The scope widens from medical device software to **health software**, and the title changes with it. - Firmware that is **Class B** today is likely to need noticeably more process work under the new edition. ## Where the revision stands IEC 62304 defines the lifecycle processes for medical device software: planning, requirements, architecture, design, implementation, verification, release, maintenance, risk management, configuration management and problem resolution. The first edition dates from 2006; Amendment 1 followed in 2015\. Together they are the version notified bodies and the FDA work with today. A previous attempt at a second edition was withdrawn around the turn of 2021/2022\. Work restarted, and the first Committee Draft of the new attempt, circulated in 2025, drew close to 1,500 comments. The second Committee Draft, **62A/1761/CD**, was circulated on **7 August 2026**, with comments closing on **27 November 2026**. The IEC currently forecasts publication for **October 2028**; some observers expect 2029\. Publication is not the end of the road either. In the EU, the new edition only becomes the reference for presumption of conformity under the MDR and IVDR once a European version with Z annexes is listed in the Official Journal, and the FDA has its own recognition process. In practice, few expect the new edition to be binding before 2030. About this article Committee drafts aren't publicly available, and their content can still change. This article is based on publicly available information about the drafts as of November 2026\. You may also come across articles claiming the standard is about to be published; the IEC's forecast and the second Committee Draft say otherwise. ## What the draft changes ### 1\. A wider scope: all health software The second edition applies to **health software** in general, with medical device software as a subset, and the title changes accordingly. That brings standalone health apps, clinical software and other health IT under the same lifecycle standard. For embedded developers nothing escapes: firmware in a medical device stays fully in scope. ### 2\. Process rigour levels replace safety classes Edition 1.1 classifies software into safety classes A, B and C, based on the worst harm a software failure could contribute to. The draft replaces them with two **software process rigour levels**: __Software safety classes (Edition 1.1) versus process rigour levels (draft Edition 2)__ | Edition 1.1 (current) | Draft Edition 2 | | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | Class A: a software failure can't contribute to any injury | Level I: a failure would at most lead to negligible harm | | Class B: a failure could contribute to a minor injury | Level II: a failure could lead to more than negligible harm (where most of today's Class B is expected to land) | | Class C: a failure could contribute to serious injury or death | Level II | The effect is that requirements move up. According to reporting on the drafts, Level I picks up requirements that today only apply to Classes B and C, such as software architecture and integration. Level II is closely modelled on today's Class C. The principle that a software failure must be assumed to happen (a probability of failure of 1) stays. The draft also asks the software development plan to describe methods at a rigour that's commensurate with the risk, so it becomes more important to explain _why_ your design reviews, testing and verification are as thorough as they are. ### 3\. ISO 14971 and ISO 13485 are no longer normative references Edition 1.1 requires a quality management system and risk management in line with ISO 13485 and ISO 14971\. The draft drops these as mandatory references, which makes the standard usable for health software outside the medical device world. For medical device manufacturers this changes little in practice: the MDR, IVDR and FDA still expect a quality management system and risk management, and ISO 13485 and ISO 14971 remain the way to show it. ### 4\. Security becomes part of the software lifecycle Software requirements must explicitly address security, including cybersecurity, and the draft introduces security threat management next to safety risk management. Detailed security activities are left to dedicated standards such as IEC 81001-5-1, which already extends the IEC 62304 processes with security activities. If you implement IEC 81001-5-1 today, you're well placed for this change. ### 5\. Guidance for AI-enabled software The drafts include material on software that uses artificial intelligence or machine learning, covering data management, training, validation and monitoring after release. Reports differ on how binding it will be; in recent drafts it appears to sit largely in an informative annex. For most embedded firmware this is a minor point. ### 6\. Smaller changes - Usability gets its own subclause, and IEC 62366 is no longer a normative reference. - The legacy software clause moves from 4.4 to 4.7. - Release (5.8) becomes release for system-level use. - Definitions of harm and hazard follow ISO/IEC Guide 51 again instead of ISO 14971. Much stays the same: the lifecycle processes, the software item and software unit concepts, and traceability from requirements to verification. The draft still doesn't give specific guidance on agile development. ## What it means for medical device firmware - **Class C firmware** (implantable pulse generators, brain-computer interfaces, life-sustaining functions) maps to Level II. The rigour you apply today stays about the same; the differences are mainly in security and documentation. - **Class B firmware** (many wearables, monitors and therapy devices) is affected most. Expect activities that today only apply to Class C, such as detailed design of every software unit and the additional unit acceptance criteria. - **Class A software items** get more architecture and integration work. - **Segregation** of software items into different classes, a common way to limit the effort for low-risk parts, pays off differently with only two levels. Revisit that strategy when you plan a new architecture. ## What to do now 1. **Keep complying with Edition 1.1.** It's the version your notified body and the FDA assess against. Don't restructure your quality system around a draft. 2. **Find your Class B software items.** They're the most likely to move up. Check what it would take to meet today's Class C requirements for them, especially detailed design and unit verification. 3. **Build security into your requirements now.** The MDR and the FDA already expect it, and IEC 81001-5-1 gives you the process: threat modelling, a software bill of materials and vulnerability management. 4. **Write risk-based development plans.** Describe your methods and why their rigour fits the risk. That's good practice today and makes the switch to rigour levels easier. 5. **Make your voice heard.** Comments on the second Committee Draft close on 27 November 2026 and go through your national committee (NEN in the Netherlands). 6. **Plan for new projects.** A device starting development now may still be on the market when Edition 2 is harmonised. Designing it to the stricter requirements from the start is often cheaper than catching up later. ## How Compen Embedded can help We build medical device firmware under IEC 62304 every day, from wearables to implantables. We can [develop your firmware](https://compen.net/services/medical-device-firmware-development), [strengthen your team](https://compen.net/services/iec-62304-insourcing) with engineers who know the standard, or [review your software process](https://compen.net/services/medical-firmware-consultancy) and tell you where the gaps are, against Edition 1.1 today and the new edition tomorrow. [Get in touch](https://compen.net/#contact) to talk it through. This article reflects publicly available information as of 2 November 2026\. It is general information, not regulatory advice for your specific device. ## Preparing for Edition 2? We can review your software process against the current and the upcoming edition. [Get in touch](https://compen.net/#contact) ## Our services ### [Custom Firmware Development](https://compen.net/services/medical-device-firmware-development) With over a decade of experience in custom firmware development across various industries, Compen Embedded specializes in delivering high-quality, reliable software tailored to meet the stringent requirements of highly regulated environments. ### [Insourcing Services](https://compen.net/services/iec-62304-insourcing) Our insourcing service ensures that your company retains full control over its intellectual property. We will establish a compliant and efficient workflow in accordance with IEC 62304 standards, assist with the integration of your (e)QMS, and help you build an exceptional in-house firmware and software development team. ### [Firmware Consultancy](https://compen.net/services/medical-firmware-consultancy) We provide specialized medical firmware consultancy, helping healthcare innovators develop secure, compliant, and high-performance solutions. We ensure your medical devices meet industry standards, from FDA regulations to ISO certifications, while optimizing firmware for precision and reliability. ```json { "@context": "https://schema.org", "@graph": [ { "@type": "ProfessionalService", "@id": "https://compen.net/#organization", "name": "Compen Embedded B.V.", "alternateName": "Compen Embedded", "url": "https://compen.net", "logo": "https://compen.net/icon/96.png", "image": "https://compen.net/og-image.jpg", "email": "info@compen.net", "slogan": "Crafting life-improving medical software", "description": "Compen Embedded provides custom firmware development, IEC 62304-compliant insourcing, and medical device software consultancy for MedTech innovations including wearables, IPG, and BCI.", "address": { "@type": "PostalAddress", "streetAddress": "High Tech Campus 32", "addressLocality": "Eindhoven", "addressCountry": "NL" }, "hasMap": "https://g.page/Compen", "contactPoint": { "@type": "ContactPoint", "contactType": "sales", "email": "info@compen.net", "url": "https://compen.net/#contact", "availableLanguage": [ "English" ] }, "knowsAbout": [ "Medical Device Firmware Development", "Embedded Software", "Embedded C and C++", "Real-Time Operating Systems", "Low-Power Wireless and Bluetooth Low Energy", "Medical Device Software", "IEC 62304", "ISO 14971", "ISO 13485", "EU Medical Device Regulation (MDR)", "FDA Medical Device Regulation", "Medical Device Cybersecurity", "IEC 81001-5-1", "Software Verification and Validation", "Wearable Health Monitors", "Brain-Computer Interfaces", "Implantable Pulse Generators" ], "areaServed": "Worldwide", "hasOfferCatalog": { "@type": "OfferCatalog", "name": "Services", "itemListElement": [ { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Custom Firmware Development", "description": "With over a decade of experience in custom firmware development across various industries, Compen Embedded specializes in delivering high-quality, reliable software tailored to meet the stringent requirements of highly regulated environments.", "url": "https://compen.net/services/medical-device-firmware-development", "provider": { "@id": "https://compen.net/#organization" } } }, { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Insourcing Services", "description": "Our insourcing service ensures that your company retains full control over its intellectual property. We will establish a compliant and efficient workflow in accordance with IEC 62304 standards, assist with the integration of your (e)QMS, and help you build an exceptional in-house firmware and software development team.", "url": "https://compen.net/services/iec-62304-insourcing", "provider": { "@id": "https://compen.net/#organization" } } }, { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Firmware Consultancy", "description": "We provide specialized medical firmware consultancy, helping healthcare innovators develop secure, compliant, and high-performance solutions. We ensure your medical devices meet industry standards, from FDA regulations to ISO certifications, while optimizing firmware for precision and reliability.", "url": "https://compen.net/services/medical-firmware-consultancy", "provider": { "@id": "https://compen.net/#organization" } } } ] } }, { "@type": "Article", "@id": "https://compen.net/articles/iec-62304-edition-2#article", "headline": "IEC 62304 Edition 2: what the revision means for medical device firmware", "description": "Where the IEC 62304 revision stands, what the draft changes (health software scope, process rigour levels instead of safety classes A/B/C, security, AI) and what embedded teams should do now.", "abstract": "IEC 62304 is getting its first major revision since 2006. The draft second edition replaces the familiar software safety classes A, B and C, widens the scope from medical device software to all health software, and puts security inside the software lifecycle. Here's where the revision stands, what the draft changes, and what it means for teams building medical device firmware.", "url": "https://compen.net/articles/iec-62304-edition-2", "mainEntityOfPage": "https://compen.net/articles/iec-62304-edition-2", "image": "https://compen.net/og-image.jpg", "datePublished": "2026-11-02", "dateModified": "2026-11-02", "inLanguage": "en", "author": { "@id": "https://compen.net/#organization" }, "publisher": { "@id": "https://compen.net/#organization" } }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://compen.net/" }, { "@type": "ListItem", "position": 2, "name": "Articles", "item": "https://compen.net/articles" }, { "@type": "ListItem", "position": 3, "name": "IEC 62304 Edition 2", "item": "https://compen.net/articles/iec-62304-edition-2" } ] } ] } ```