How to Use an ISO 13485 Certificate for Overseas Registration of Software Medical Devices

ISO 13485 certification demonstrates that a manufacturer's quality management system conforms to international standards, but it is not a substitute for product registration. To use it correctly for overseas registration of software medical devices, manufacturers must first determine whether the software is regulated as a medical device in the target country, then establish the risk class and registration pathway. The ISO 13485 certificate serves as evidence of quality system compliance, but you must also prepare technical documentation, performance validation, risk management, clinical evaluation or usability evidence, and localized labeling.

Key Summary

For overseas registration of software medical devices, an ISO 13485 certificate is a significant quality system document, but it cannot replace the product registration certificate. Companies should first determine whether the target country includes the software as a medical device, then define the risk class and registration path. The ISO 13485 certificate proves that the quality management system meets regulatory requirements, but additional technical files, performance verification, risk management, clinical evaluation or usability evidence, and labels/instructions are required. In GHWP member states, Southeast Asia, the Middle East, and Latin America, most countries require a local agent or authorized representative and accept reuse of core technical files, but localization adaptation is mandatory. Common risks include mistaking the ISO 13485 certificate as a registration proof, failing to appoint a local agent, and neglecting post-market surveillance and adverse event reporting. Companies should proactively assess the applicability of existing NMPA, CE, FDA, or MDSAP documentation, prioritize reusable risk management, software lifecycle, and usability engineering evidence, and supplement local testing and language versions as required. Post-market systems must include complaint handling, update and change management, and renewal mechanisms to avoid registration failure due to unclear certificate control or missing change control.

Applicable Scenarios and Core Issues

Software medical devices—including software embedded in medical equipment, standalone software, and mobile medical applications—often face a common question during overseas registration: if the company already holds ISO 13485 certification, can it be used directly for registration? Many companies treat ISO 13485 as a "global passport," assuming that it alone grants access to target markets. In reality, an ISO 13485 certificate only proves that the quality management system conforms to international standards; it does not mean the product is approved for commercial distribution.

In international medical device registration, an ISO 13485 certificate is typically used as evidence of quality system compliance to demonstrate that the manufacturer has stable capabilities in production, design, and delivery. However, the registration application is product-specific and requires technical documentation, performance verification, risk management, clinical evaluation, or usability evidence for that particular product. For software medical devices specifically, you must also provide software lifecycle processes, cybersecurity, data interfaces, and post-market surveillance plans. Therefore, the first step in correctly using an ISO 13485 certificate is understanding its place in the overall registration chain—not treating it as a guarantee of approval.

Different countries and regions have varying levels of recognition for ISO 13485 certificates. GHWP member states generally accept ISO 13485 as the quality system foundation, but specific requirements differ. For example, some Southeast Asian countries allow manufacturers holding ISO 13485 certification to waive on-site system audits, provided the certification scope covers the listed products. Middle Eastern and Latin American countries may require confirmation by local representatives or authorized bodies. The core issue is not whether the certificate is valid, but whether the gap between the certificate and the target country's regulatory requirements can be closed with other documentation.

Registration Decision Logic

Overseas registration of software medical devices should follow a three-step decision logic. First, determine whether the product falls within the target country's medical device regulatory scope. The software's function determines its classification. For example, software used for diagnosis, treatment, monitoring, or vital sign calculation is typically a medical device, while simple health management or fitness tracking software may not be. Companies should consult classification guidelines published by the target country's regulatory authority or use official decision tools.

Second, determine the risk class and registration pathway. Under the EU MDR, software is classified as Class I, IIa, IIb, or III. The US FDA follows SaMD classification standards, while many Southeast Asian countries refer to the IMDRF's SaMD risk framework. The risk class directly affects the registration pathway, review depth, and clinical evidence requirements. Manufacturers must first identify the risk category, then select the appropriate registration channel.

Third, assess whether existing documentation can be reused. Manufacturers should inventory existing NMPA registration files, CE technical documentation, FDA 510(k) or De Novo submissions, MDSAP audit reports, and post-market surveillance data. Among these, risk management reports, software requirement specifications, verification and validation records, and cybersecurity documentation are often reusable, but they must be adapted for language, format, and regulatory differences.

Documentation and Evidence

An ISO 13485 certificate itself cannot serve as technical documentation. In overseas registration, what matters is a complete product evidence package. First, the quality management system documentation should cover the entire software lifecycle, including requirements management, design and development, coding, testing, release, deployment, and decommissioning. Ensure that the ISO 13485 certificate's scope includes the software product; otherwise, regulators may question the connection between the system and the product.

Second, technical files must contain a software description, intended purpose, operating environment, algorithm principles, and performance metrics. For software using machine learning or adaptive algorithms, additional evidence of training data, model validation, and bias control is required. Performance validation should reflect real clinical scenarios—accuracy and reliability—not just laboratory data.

Third, risk management documentation must comply with ISO 14971 or target country requirements. For software, risk analysis should identify patient harm, cybersecurity vulnerabilities, and data transmission errors. Usability engineering data is also vital, especially when intended users include non-professionals. You must provide evidence of user validation and that labels are easy to understand.

Finally, labels and instructions must be localized. For overseas registration, instructions are typically required in the target country's official language and must include local emergency contact numbers. For software medical applications, interface language and prompts fall under review. Companies should prepare multilingual versions of labels and instructions in advance.

Additionally, many countries require the appointment of a local agent or authorized representative. The local agent is responsible for communicating with the regulatory authority, receiving adverse event reports, and carrying certain legal responsibilities. An ISO 13485 certificate cannot replace the agent's role. The manufacturer's name and address on the certificate must match the registration application to avoid deficiencies or delays caused by information discrepancies.

Common Mistakes

• Submitting an ISO 13485 certificate as a "product registration certificate" directly to the target country's regulatory authority, resulting in rejection.
• Ignoring the special classification rules for software in the target country, over-classifying low-risk software as high-risk, and imposing unnecessary clinical requirements.
• Submitting technical files with a software version that does not match the registration application, requiring a gap analysis.
• Failing to designate a local agent, or having an agent whose qualifications do not meet the target country's requirements, making the application unacceptable.
• Preparing materials only in English and neglecting language requirements, causing label/instructions to fail language review.
• Having an ISO 13485 certificate whose scope does not cover the current software version or production address, leading to questions about system effectiveness.
• Lacking a post-market surveillance plan for software updates, security patches, and adverse event reporting.
• Copying the same documentation for multi-country registration without addressing each country's specific data protection, cybersecurity, and interoperability requirements.

Preparation Checklist

• Confirm the software product's regulatory classification in each target country and retain official classification basis.
• Verify the validity and coverage of the ISO 13485 certificate; if necessary, apply for a scope extension.
• Establish software lifecycle quality management documentation to ensure traceability of requirements, design, testing, and changes.
• Compile a risk management report listing software-specific hazards, foreseeable misuse, and cybersecurity risks.
• Prepare performance validation, clinical evaluation, or usability evidence, and translate into the target country's language.
• Localize labels and instructions, ensuring version numbers match the submitted documentation.
• Select a local agent or authorized representative in the target country, sign a formal agreement, and clearly define responsibilities.
• Develop a post-market surveillance plan, including complaint handling, software updates, and adverse event reporting processes.
• Plan the registration routes for multiple countries in advance, identifying reusable and newly generated documents.
• Establish a certificate control file to track audit dates, changes, and renewal deadlines for the ISO 13485 certificate.

AIMEILI Perspective

Manufacturers often mistake ISO 13485 as "registration insurance." In fact, the certificate only proves system compliance and cannot compensate for missing product technical evidence. We frequently see companies spend considerable effort maintaining system files while overlooking the software's performance data and clinical evidence, causing registration applications to stall during technical review.

Early in a project, perform a gap analysis rather than immediately jumping to document translation. List the registration requirements for each target country and compare existing documents to determine which can be used directly, which need supplements, and which must be recreated. For GHWP member states, many countries accept MDSAP or ISO 13485 audit results, but document formats and languages still require localization.

Reusable documentation includes risk management, software requirement specifications, verification and validation records, and cybersecurity frameworks. Documentation that must be localized includes labels, instructions, clinical evaluation summaries, and registration application forms. Local agent and control issues are equally critical. If the distributor acts as the agent, the registration certificate may become invalid if the distributor changes. Companies should maintain control of the certificate, preferably by appointing an independent registration agent and including change and renewal terms in the agreement.

For multi-country registration, we recommend using a "core documentation package plus country-specific difference package" structure. This reduces duplicate work and allows quick responses to different regulators' deficiency requests. Also, regularly verify the audit scope and validity of the ISO 13485 certificate to ensure its status does not affect registration applications.

Common Follow-up Questions

Is there an internationally unified certification for ISO 13485?

ISO 13485 certificates are issued by certification bodies, but the recognition of certificates from different organizations may vary. Target country regulators typically accept certifications with IAF accreditation marks, though some countries require certificates from locally recognized bodies. Companies should confirm with the target country's regulatory authority in advance regarding their requirements for certification bodies and certificate format.

Does a software version update require re-registration?

Whether a software update triggers re-registration depends on the update's impact on intended purpose, performance, and safety. Major updates, such as changing the core algorithm or adding a new indication, generally require a change application or new registration. Minor updates, such as bug fixes or user interface adjustments, must be reported through the post-market surveillance process. Manufacturers should establish an internal assessment process and consult the target country's regulatory authority.

What should be done if the ISO 13485 certificate scope does not include the software product?

Manufacturers should contact their certification body to apply for a scope extension, ensuring the software product and its development process are covered. Until the scope is extended, the certificate cannot be used as system evidence for that product. Also, evaluate the additional audit time required for the scope extension to avoid impacting the registration timeline.

Further Reading

• How to Prepare Clinical Evaluation Documents for Overseas Registration of Software Medical Devices
• How to Conduct Post-Market Surveillance for Overseas Registration of Software Medical Devices
• When Should a Change Application Be Submitted for Home Medical Device Overseas Registration?
• What to Prepare for Renewal of Home Medical Device Overseas Registration?
• How to Handle Inconsistency in Quality System Certification for Overseas Registration of Software Medical Devices

Content reviewed by the AIMEILI Regulatory Editorial Team and the AIMEILI Medical Device International Registration Project Group. Sources are based on official regulatory authorities, international organizations, standard bodies, and public regulatory information. This article is intended for preliminary understanding, documentation preparation, and project planning, and does not replace official requirements, test conclusions, or legal advice from target country regulators.