Global Certification Schemes for Medical Device Software

Certifying medical device software is no longer optional - it’s a critical step for ensuring safety, meeting regulatory requirements, and accessing global markets. Here's what you need to know:

• Why It Matters: Medical device software manages critical functions like insulin delivery and cardiac monitoring. Failures can directly impact patient safety.
• Key Standards: Three main standards - IEC 62304 (software lifecycle), ISO 13485 (quality systems), and IEC 82304-1 (standalone software) - form the backbone of compliance.
• Major Schemes: The FDA, EU MDR, and MDSAP dominate the regulatory landscape, each with unique requirements for certification.
• Cybersecurity Focus: Since March 2023, medical device security risks and mitigation measures like SBOMs are mandatory for FDA submissions. EU MDR also integrates security into its quality frameworks.
• Upcoming Changes: By August 2026, IEC 62304 Edition 2 will introduce new rigor levels and address AI/ML and cybersecurity in software design.

Takeaway: Certification ensures compliance, boosts patient safety, and simplifies global market entry. But it’s not a one-time task - it requires continuous updates and alignment with evolving regulations.

How to Certify a Software as Medical Device with Dr. Abtin Rad? (TÜV SÜD)

sbb-itb-535baee

Core International Standards for Medical Device Software Certification

When it comes to certifying medical device software, three standards consistently serve as the foundation: IEC 62304, ISO 13485, and IEC 82304-1. Together, they form a comprehensive framework that addresses organizational structures, development processes, and product-specific requirements. This approach helps streamline compliance efforts across different regions while minimizing duplication.

IEC 62304: Software Development Lifecycle Processes

IEC 62304 doesn’t dictate specific coding practices. Instead, it lays out a flexible framework for managing the software lifecycle, including planning, requirements analysis, architectural design, implementation, verification, and maintenance. The level of rigor required depends on the potential harm the software could cause if it fails ^[13].

The current version (Edition 1) uses three safety classes:

• Class A: No injury possible
• Class B: Non-serious injury possible
• Class C: Death or serious injury possible

Your software’s classification determines the level of documentation, testing, and resources needed. For example, Class C software typically requires at least 80% branch coverage during unit testing ^[13]. A key takeaway: assign safety classes early in the project. Reclassifying midway can lead to costly delays and disruptions ^[5].

Looking ahead, Edition 2 (expected in August 2026) will introduce two Software Process Rigor Levels instead of the current three safety classes. It will also address AI/ML lifecycle management and incorporate medical device cyber risk management as a core design consideration ^[14].

ISO 13485: Quality Management Systems for Medical Devices

ISO 13485 sets the groundwork for everything else. It establishes the Quality Management System (QMS) that governs the design, development, and maintenance of medical devices, including software ^[10].

"ISO 13485 is not simply a best practice. It is the foundational framework that underpins market access in virtually every major regulatory jurisdiction." - Alessandro Stella, Medical Device Regulatory Consultant ^[16]

However, it’s worth noting that ISO 13485:2016 certification alone doesn’t fully meet the FDA’s Quality Management System Regulation (QMSR) requirements. The FDA has added U.S.-specific elements, so teams transitioning to QMSR need to update terminology and processes. For instance, the Design History File (DHF) is now referred to as the Design and Development File (DDF) ^[15].

For software certification under IEC 62304, having a valid ISO 13485 certificate is usually a must. That’s because the software lifecycle documentation is built upon a compliant QMS ^[11].

IEC 82304-1: Health Software Safety and Security

While IEC 62304 focuses on software embedded in or used alongside hardware devices, IEC 82304-1 is specifically designed for standalone health software. This includes mobile apps, server-based clinical tools, and SaaS platforms that operate on general-purpose hardware ^[9][12].

The standard addresses the entire product lifecycle, covering safety, effectiveness, and security. It is especially critical for Software as a Medical Device (SaMD) products, which are under increasing regulatory scrutiny. While ISO 13485 provides the organizational framework, IEC 82304-1 ensures software-specific safety and security requirements are met - filling a gap left by hardware-focused standards ^[5][13].

Together, these three standards create a robust compliance structure:

• ISO 13485 governs the organization.
• IEC 62304 governs the development process.
• IEC 82304-1 governs standalone software products.

This layered framework sets the stage for the certification processes that follow, covering everything from scope and documentation to ongoing maintenance.

Major Certification and Conformity Schemes at a Glance

Once foundational standards are in place, the next step is understanding the certification schemes that govern market access. The U.S., EU, and other major markets each have their own unique requirements, and approvals from one region don’t automatically apply to another. These differences mean companies need tailored strategies for each market. Here’s a breakdown of the three most relevant certification schemes.

FDA Digital Health Software Pre-Cert Program

In 2017, the FDA introduced its Software Pre-Cert Pilot Program with an innovative approach: instead of reviewing individual products, it evaluated the developer's organizational excellence, including their quality culture, processes, and track record. Companies like Apple, Fitbit, Samsung, and Roche were among the nine participants ^[7].

By September 2022, the FDA concluded that while this approach was promising, current laws still required risk-based product reviews, making legislative changes necessary for a permanent shift ^[18]. However, the program’s core principles influenced the Pre-determined Change Control Plan (PCCP) framework, which allows pre-specified software updates without requiring new submissions ^[7]. Recently, the FDA and CMS launched the TEMPO pilot in December 2025. This initiative focuses on up to 10 U.S. manufacturers of digital health devices in cardio-kidney-metabolic and behavioral health, enabling Medicare/Medicaid patient access before full premarket authorization starting July 1, 2026 ^[7].

For U.S. market access, companies must navigate pathways like 510(k) (substantial equivalence), De Novo (novel, low-to-moderate risk), or PMA (high-risk devices). Timelines vary: 510(k) reviews take about 3–5 months, De Novo averages 150–290 days, and PMA can take over 18 months ^[7]. As of October 1, 2023, all 510(k) submissions must use the electronic eSTAR template ^[19].

Cybersecurity is now a critical requirement. Since March 2023, the FDA mandates that "cyber devices" - software with internet connectivity vulnerable to threats - submit a Software Bill of Materials (SBOM) and a postmarket vulnerability monitoring plan under Section 524B of the FD&C Act ^[19].

MDR and CE Mark Certification for Software in the EU

In the EU, medical device software is regulated under Regulation (EU) 2017/745 (MDR), with Rule 11 of Annex VIII as the key classification framework. This rule has significantly impacted the industry.

"Software that was Class I under the MDD is now Class IIa or higher under the MDR. This means many software manufacturers that previously self-certified their products now require Notified Body involvement." - Ran Chen, Global MedTech Expert ^[7]

Under Rule 11, software with the potential to cause death or irreversible harm is classified as Class III. Software that could lead to serious health deterioration or require surgical intervention falls under Class IIb, while most clinical decision-support software is Class IIa - all of which require a Notified Body assessment ^[7]. This reclassification has created bottlenecks, as Notified Body capacity struggles to meet demand.

Before entering the EU market, software developers should consult MDCG 2019-11 decision trees to determine if their software qualifies as a medical device and its Rule 11 classification ^[7]. Skipping this step can lead to costly reclassification issues. It’s also important to note that the FDA does not recognize the CE mark, meaning EU approval has no standing in the U.S. regulatory system ^[17].

For companies targeting multiple regions, the Medical Device Single Audit Program offers an efficient alternative.

MDSAP: Medical Device Single Audit Program

MDSAP simplifies compliance for manufacturers aiming to enter multiple markets. A single audit of the quality management system - conducted by an authorized Auditing Organization - satisfies regulatory requirements across five regions: the U.S., Canada, Brazil, Japan, and Australia ^[17].

Startups and mid-sized companies can benefit by adopting the MDSAP framework early. It aligns with both ISO 13485 and 21 CFR Part 820, eliminating the need for extensive gap analyses when expanding into new markets ^[17].

Here’s a summary of how these three schemes compare:

The Certification Process: Key Steps and Requirements

Certification follows a structured series of steps, with each phase building on the last. Knowing what’s expected at every stage helps teams avoid delays and unexpected expenses.

Defining Certification Scope and Objectives

The first step is to clearly define the scope and rules for certification. Teams must decide whether their software falls under Software as a Medical Device (SaMD) or Software in a Medical Device (SiMD) and determine its risk classification. This classification dictates applicable standards, whether a Notified Body is involved, and the level of required documentation and testing. It's not just a label - it shapes the entire compliance process ^[7][21].

For products targeting the EU market, appointing a Person Responsible for Regulatory Compliance (PRRC) early on is critical. This individual ensures the technical documentation is accurate and complete. Delaying their involvement can lead to unnecessary risks ^[21]. Conducting a structured gap analysis against IEC 62304 and IEC 81001-5-1 at this stage helps identify process weaknesses before they become audit issues ^[4]. These early decisions set the foundation for the documentation and testing required in later phases.

Documentation and Testing Requirements

Key documentation includes a threat model (using methods like STRIDE or PASTA to identify attack vectors), a Software Bill of Materials (SBOM), a security architecture document, and a risk management file that integrates clinical and cybersecurity risks under ISO 14971 ^[8][20][22].

"Cybersecurity is not a separate document under MDR. It lives inside the EN ISO 14971 risk file, anchored to EN IEC 81001-5-1:2022 and interpreted through MDCG 2019-16 Rev.1." - Tibor Zechmeister and Felix Lenhard ^[20]

Incomplete security documentation is one of the most common reasons Notified Bodies flag major non-conformities for SaMD submissions ^[22]. On the testing front, regulators expect a multi-layered approach:

• SAST during development
• DAST for testing live interfaces
• Fuzz testing to check input resilience
• Penetration testing on the release candidate

"The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing." - MDCG 2019-16 Guidance ^[2]

Timing is also critical. The FDA has expressed concerns about penetration tests conducted more than a year before submission. To avoid issues, perform final penetration tests on the release candidate as close to submission as possible ^[2]. These documentation and testing efforts support both initial certification and ongoing compliance, forming the foundation for lifecycle management across global markets.

Issuance and Post-Certification Maintenance

Once all documentation and testing requirements are met, certification authorities review the submission to confirm compliance. This process results in FDA clearance or approval, or an EU Certificate of Conformity. However, as Ran Chen points out, CE marking ultimately remains the manufacturer’s responsibility - even when a Notified Body issues a certificate, the manufacturer is responsible for drafting the EU Declaration of Conformity ^[21].

Certification doesn’t end with approval. Postmarket obligations require continuous attention. Under EU MDR, manufacturers must submit Periodic Safety Update Reports (PSURs) and maintain ongoing post-market surveillance. In the U.S., the FDA’s QMSR (effective February 2, 2026) integrates cybersecurity maintenance into the quality system ^[23]. Teams must update the SBOM with each software release and monitor CVE feeds daily - ideally through automation to ensure alerts are received within 24 hours of a relevant disclosure ^[20]. For software with frequent updates, a Predetermined Change Control Plan (PCCP) allows pre-approved changes without requiring a full resubmission ^[6]. These ongoing requirements emphasize that certification is an ongoing responsibility, not a one-time achievement.

Global Market Access and Regulatory Alignment

Meeting global compliance standards for medical device software can be challenging, especially when navigating the distinct requirements of various regulators and third-party risk management expectations. However, international standards like IEC 62304 and IEC 81001-5-1 are helping create a shared framework that satisfies both FDA and EU MDR expectations. This alignment makes it possible to craft a single compliance strategy instead of managing separate regional approaches, significantly simplifying global market entry.

Aligning Certifications Across the U.S., EU, and Other Markets

One effective way to streamline the process is by treating a primary market approval - such as FDA clearance or a CE mark - as a "Tier 1" reference for faster access to other markets. For instance, regulatory bodies in Vietnam and Singapore offer expedited pathways for devices already cleared by the FDA or holding a CE mark ^[26]. The IMDRF’s February 2026 Playbook for Medical Device Regulatory Reliance Programs formalizes this concept, encouraging reliance on assessments conducted by other authorities.

"A fragmented or region-specific cybersecurity strategy increases regulatory risk and complicates global submissions." - Wayne Stewart, Vice President, Global – IoT & AI, Intertek ^[1]

Beyond leveraging approvals, consolidated audits also play a big role in global alignment. Programs like MDSAP simplify the audit process by combining quality management system (QMS) audits for multiple countries - including the U.S., Canada, Australia, Brazil, Japan, South Korea, and Malaysia - into a single cycle. For manufacturers already compliant with ISO 13485, this approach integrates seamlessly with the FDA’s QMSR, effective February 2, 2026. Additionally, using formats like the IMDRF Table of Contents (ToC) or STED minimizes rework by creating a reusable technical documentation package adaptable to various jurisdictions.

Using Certification to Support Regulatory Submissions

Certification evidence is not just about market entry - it’s also critical for regulatory submissions. For example, demonstrating compliance with IEC 81001-5-1 offers a presumption of conformity with the EU MDR’s General Safety and Performance Requirements (GSPR), easing the burden during Notified Body reviews ^[8][20]. However, this approach only works if the supporting documentation is comprehensive and well-organized.

For cloud-based quality management tools, the FDA’s Computer Software Assurance (CSA) guidance allows teams to use existing vendor certifications - such as SOC 2 Type II or ISO 27001 from platforms like AWS, Azure, or GCP - as part of their validation evidence. This eliminates the need for full independent re-validation, reducing costs and effort while maintaining compliance ^[25]. The overarching principle is clear: secure approval in your primary market first, then reuse that evidence package to simplify submissions in secondary markets.

Practical Steps for Medical Device Software Teams

Achieving certification means ensuring that development, security, and regulatory teams work together from the very beginning. To make this happen, teams need to put the certification processes into action, focusing on documentation, testing, and strategies for market access as outlined earlier.

Aligning Development, Security, and Regulatory Functions

Integrating security into the process early is critical - not just for compliance but also to reduce risks. Treating cybersecurity as an afterthought can jeopardize certification efforts. Naomi Schwartz, VP of Regulatory Strategy at Medcrypt, emphasizes this shift:

"The landscape now is to design controls in, period. The FDA's cybersecurity authority is no longer based solely on risk assessments. It's based on statute, and statute says you must prove secure by design." ^[3]

In practice, this means security requirements should be addressed alongside functional ones. A practical way to do this is through cross-functional threat modeling workshops. These sessions, involving software engineers, clinical specialists, and cybersecurity experts, can help uncover risks that might otherwise go unnoticed. Using frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), teams can identify potential vulnerabilities, such as how data tampering could impact a dosing algorithm ^[8].

Security should also be embedded into existing processes like risk management, configuration management, and CAPA (Corrective and Preventive Action) to ensure alignment during audits ^[20]. Tibor Zechmeister highlights this integration:

"Cybersecurity is not a separate document under MDR. It lives inside the EN ISO 14971 risk file... A device that is secure at launch can become insecure the moment a SOUP library publishes a CVE." ^[20]

Additionally, assigning a specific person as the vulnerability response owner is essential. Without clear accountability, things can fall apart when a Notified Body begins an audit ^[20].

Using Risk Management Tools for Evidence Collection

Manually collecting evidence can slow down the certification process significantly. With 70–90% of software vulnerabilities stemming from third-party components ^[29], automated tools like SBOM (Software Bill of Materials) management and threat modeling are key. An SBOM that exists only as a static spreadsheet becomes a liability. Instead, it should be dynamic - automatically generated during builds and linked to a real-time CVE feed to alert the team within 24 hours of any exposure ^[20].

For teams managing a portfolio of connected devices, platforms like Censinet RiskOps™ can simplify risk assessments and organize certification evidence. This includes identifying risks in third-party components, managing vulnerabilities, and preparing regulatory documentation. Considering that about 1 in 4 medical devices has at least one known vulnerability ^[24], this level of organization is critical. The FDA's eSTAR system, for instance, will place submissions on hold if all 11 cybersecurity documentation categories are not addressed properly ^[28].

Here’s a quick breakdown of key evidence categories, what regulators expect, and how teams can generate them efficiently:

Automating documentation during development helps create a solid evidence package. When traceability between security requirements, threat models, and test results is built into your ALM (Application Lifecycle Management) platform, the package is more likely to withstand regulatory scrutiny ^[8][27]. These automated workflows not only make evidence collection more efficient but also strengthen the overall compliance process.

Conclusion: The Path to Certified Medical Device Software

Certifying medical device software isn't just about meeting regulatory requirements - it's about creating safer, more reliable products. Cybersecurity must be part of the quality management system from the very beginning, not an afterthought.

The FDA emphasizes this point clearly: "Cybersecurity is not separate from quality - it is part of it." ^[23] By February 2026, the transition to the Quality Management System Regulation (QMSR) will formally incorporate these principles, aligning with ISO 13485-based clauses. This shift means manufacturers must embed cybersecurity documentation into their controlled processes, ensuring compliance for premarket submissions ^[23].

The standards discussed - IEC 62304, ISO 13485, and IEC 82304-1 - work together to create a robust framework. This framework emphasizes software safety classification, unified risk management, and ongoing post-market surveillance to maintain device safety well beyond launch. Wayne Stewart, Vice President, Global – IoT & AI at Intertek, highlights a critical point:

"In 2026, medical device software cybersecurity submissions rarely fail because security controls are missing. They fail because cybersecurity is treated as documentation, not as a safety system." ^[1]

This integrated approach ensures that safety and risk management are continuously prioritized throughout the product lifecycle.

Certification doesn't just enhance patient safety - it also streamlines processes across global markets, speeds up regulatory submissions, and builds the trust needed for long-term success. As Corena Pharmaceutical Wholesaler notes, "Certification frameworks serve as both a barrier to entry and a pathway to sustainable global growth." ^[30]

Beyond compliance, certification offers operational benefits. Tools like Censinet RiskOps™ help healthcare organizations integrate cybersecurity risk management into their quality systems, simplifying certification efforts and improving efficiency.

Teams that treat certification as a strategic investment gain a competitive edge. They work smarter, avoid costly rework, and thrive in a market with increasingly complex regulatory demands - unlocking the global opportunities discussed throughout this guide.

FAQs

Which standard should I start with: ISO 13485, IEC 62304, or IEC 82304-1?

Start with ISO 13485, the standard that outlines the quality management system required for designing and manufacturing medical devices. Then, apply IEC 62304, which focuses specifically on the software lifecycle processes essential for medical device software. Finally, incorporate IEC 82304-1, tailored for health software operating on general computing platforms. To streamline compliance and ensure strong cybersecurity measures, tools like the Censinet RiskOps™ platform can provide valuable oversight.

How do I know if my software is a “cyber device” and needs an SBOM for the FDA?

Your software qualifies as a cyber device under section 524B of the FD&C Act if it meets the following conditions:

• It includes software that has been validated, installed, or authorized by the sponsor.
• It has the capability to connect to the internet.
• It possesses technological characteristics that make it susceptible to cybersecurity threats.

If your product fits these criteria, you are required to provide a Software Bill of Materials (SBOM) as part of your premarket submission. For additional guidance, reach out to the FDA directly.

What should I do now to prepare for IEC 62304 Edition 2 in August 2026?

Start reviewing your development files to spot any gaps in threat modeling and penetration test traceability. With Amendment 2, formal reports are now mandatory for all network-connected devices, and there’s no grace period for compliance.

Make sure to integrate cybersecurity documentation into your Quality Management System (QMS). Update your processes to align with the two-level Software Process Rigor framework, document the required competencies for cybersecurity roles, and secure updated assurance letters for any off-the-shelf software components. These steps are essential to meet the new compliance standards.

Related Blog Posts

• Ultimate Guide to Medical Device Compliance Mapping
• ISO 27001 for Medical Device Manufacturers
• FDA Cybersecurity Design Controls: Key Requirements
• Regulatory Frameworks for IoT in Healthcare