IEC 62304 Edition 2: The Biggest Change in 20 Years Is Coming in August 2026

There is still a widespread assumption that IEC 62304 Edition 2 is a future concern. It is not.

The Committee Draft for Vote (CDV) has been circulating since 2025, and public comments are already closed. Comment resolution began on 20 March 2026. The Final Draft International Standard (FDIS) phase started on 22 May 2026.

Final publication is scheduled for 12 August 2026, roughly three months away. Despite that, industry messaging still repeats a now-incorrect framing: "before the 2026 draft arrives."

The draft has already arrived. What ships in August is the final standard. And critically, the text is not expected to change in any meaningful way between FDIS and publication. That means the version available today is effectively the version organisations must plan against.

For hospital IT teams, digital health vendors, and connected-care platforms, this creates a short and very real runway before procurement teams, auditors, and notified bodies begin aligning expectations in late 2026.

IEC 62304 Edition 1 was narrowly focused: software embedded in a medical device or sold as one.

Edition 2 expands that definition significantly under the term "health software." In practice, this pulls in categories that have historically operated outside the standard's boundary.

This includes:

• Hospital information systems and EHR modules that influence clinical decision-making

• Wellness, lifestyle, and chronic disease management applications handling health data

• Connected-care platforms, remote monitoring backends, patient portals, and clinician dashboards

• Integration layers such as HL7 and FHIR brokers, middleware, and analytics pipelines supporting clinical workflows or AI systems

The implication is simple but consequential: if your software touches clinical workflow or patient data, and you have never aligned to IEC 62304 lifecycle expectations, that gap is now visible — not just to regulators, but to procurement teams, integration partners, and auditors evaluating vendor risk.

Scope. The headline change. "Medical device software" becomes "health software." Same lifecycle discipline, much wider scope. The standard now sits next to your product whether or not you have a CE mark or 510(k).

Mandatory references to ISO 13485 and ISO 14971 are removed. Edition 1 embedded a quality management system (ISO 13485) and the medical device risk management standard (ISO 14971). Edition 2 stands on its own because non-regulated health software is not bound by either. Regulated MedTech will still apply both in practice, but the standard no longer enforces the link. That removes a common excuse from non-regulated vendors who used to say, "ISO 13485 doesn't apply to us, so IEC 62304 doesn't either."

Safety classification is simplified from three levels to two. The A, B, C model collapses. Less time spent arguing about whether a minor injury counts as B or C, more focus on the controls you actually put in place. For teams new to the standard, this is the most user-friendly change. The decision tree is shorter.

AI and machine learning get an explicit lifecycle. Data management, model training, change control, and post-deployment monitoring are addressed directly. The old approach — bolting AI onto a process designed for deterministic code — no longer holds. If you ship anything with a model in the loop, your development plan now needs sections that did not exist in Edition 1.

Cybersecurity moves into design control. It is no longer a separate workstream you only think about during verification. Threat modelling, secure-by-design decisions, vulnerability management, and patch strategy are now part of the software lifecycle, aligning Edition 2 with what the FDA and MDR have already been requiring separately.

The action list is short. Map your products against the new health software definition and flag anything that moves into scope. Run a gap assessment against the CDV now, because the final text will not change significantly, and waiting until August costs you 12 weeks. Re-baseline your safety classification under the two-level model and document the rationale. If you use AI or ML, create a lifecycle plan covering data provenance, training control, monitoring triggers, and retraining decisions. Integrate cybersecurity into the software development plan rather than managing it as a parallel workstream.

The harder part is cultural. IEC 62304 introduces traceability, configuration management, and verification rigour that hospital IT teams and digital health startups have rarely implemented at scale. Code review, document control, and verification evidence become part of daily engineering practice, not a yearly audit scramble. The teams that handle this well start small, with one product and one cross-functional group. The teams that struggle try to retrofit the entire portfolio at once, fail, and then treat it as a compliance project. It is not a compliance project. It is a product development discipline.

The window before August is short, and specialist capacity won't stay open once industry attention spikes in Q4.

Our Medical Devices business unit has worked across the full IEC 62304 lifecycle for over a decade, on SaMD, SiMD, and increasingly across the health software landscape that Edition 2 will bring into scope. We know where teams new to the standard tend to get stuck, and we understand which gaps actually need to be addressed before August versus those that can wait.

Book a 30-minute readiness assessment with our team before Q4 2026, when industry attention will spike and specialist capacity across the market will tighten. We will tell you directly where you stand. Contact Critical Software Medical Devices team.