Software as a Medical Device (SaMD) Regulation Compared: SFDA, ANVISA, NAFDAC, PPB

Four Countries Now Regulate Standalone Medical Software — But Not Identically

Software as a Medical Device (SaMD) is software that performs one or more medical purposes without being part of a hardware medical device — a diagnostic app on a smartphone, a cloud-based triage algorithm, or a clinical decision-support module. As of 2026, a growing band of regulators outside the EU and US have moved from "watch and wait" to binding legal texts: Saudi Arabia (SFDA MDS-G23), Brazil (ANVISA RDC 657/2022), Nigeria (NAFDAC SaMD guideline, effective 1 July 2024), and Kenya (PPB MDSW 2026 guideline).

All four build on the same IMDRF SaMD framework — the Key Definitions (IMDRF/SaMD WG/N10), the Risk Categorization (N12), the Quality Management System (N23), and the Clinical Evaluation (N41). That common ancestry makes the high-level concepts look identical. The legal traps are in the differences: what each country excludes, how it maps IMDRF categories to local risk classes, what the filing object is called, and which language/local-representative rules attach.

This is a regulatory-research comparison for compliance planning — not legal advice for a specific product. For every obligation below, confirm the operative text in the official source listed in the final section.

The Common Backbone: The IMDRF SaMD Categorization

Before the country differences matter, you need the categorization that all four jurisdictions (and the FDA, a founding IMDRF member) share. IMDRF/SaMD WG/N12 sorts SaMD into four categories using two axes:

Category IV is a SaMD that treats or diagnoses a condition in a critical or serious situation — for example, software that flags an imminent cardiac event and triggers an intervention. Category I merely informs clinical management of a non-serious condition. Each country below transposes these four categories into its own risk-class system, and the naming is where exporters get tripped up.

Side-by-Side: The Four Legal Texts

Saudi Arabia: MDS-G23 and the Definition Test

Saudi Arabia was an early mover. The SFDA adopted the IMDRF SaMD principles in 2018 and codified them in MDS-G23, later expanded by MDS-G027 (Guidance on Digital Health Products, 2025), which now distinguishes SaMD from Software in a Medical Device (SiMD) and from medical-device accessories.

Definition test (verify in MDS-G23 §5): software is SaMD if it (1) is intended for a medical purpose, (2) performs that purpose without being part of a hardware device, and (3) is not solely intended to drive a hardware device. Software that drives or influences a hardware device and has its own medical purpose still qualifies as SaMD; software that only operates the hardware does not. Mobile apps meeting the definition are SaMD.

Categorization: the SFDA applies the IMDRF N12 four-category matrix directly (Categories I–IV). Higher categories require the full Medical Device Marketing Authorization (MDMA) under MDS-REQ 1; the risk classification rules mirror the EU MDR's 22 rules.

Cross-market trap: a SaMD that also qualifies as an IVD SaMD falls under MDS-REQ 1's IVD framework, not the general device path — the same split exists in the EU (MDR vs IVDR). Get the qualification right before filing, because the dossier tables of contents differ.

Brazil: RDC 657/2022 and the Notification/Registration Split

Brazil is the only one of the four with a hard legal-text instrument (a resolution rather than guidance). ANVISA RDC 657/2022 entered into force on 1 July 2022 and is read together with RDC 751/2022 (classification, where SaMD sits under Rule 11) and the labeling rules RDC 185/2001 and RDC 431/2020.

The critical filing split (Articles 10–12):

• Class I and II SaMD → Notification (Notificação): the company files a notification petition form, and the technical dossier is retained by the holder (not submitted upfront). This is a lighter, self-declared route.
• Class III and IV SaMD → Registration (Registro): ANVISA performs a substantive technical analysis, including clinical evaluation, technical validation, and cybersecurity review.

Explicit exclusions (Article 1(2)) — verify these before assuming your software is in scope: software intended for well-being, software listed by ANVISA as non-regulated, software used exclusively for administrative and financial management, and software that processes demographic/epidemiological data without any diagnostic or therapeutic function. A scheduling app with no diagnostic purpose is out; the same app with a diagnostic claim is in.

In-house health-provider software carve-out: Class I/II SaMD developed solely for a healthcare provider's own internal system does not require regularization — provided it does not interfere with the operation of ANVISA-regulated devices — but it must have approved documentation on file by 2024 and may not be sold or donated.

Labeling (IFU) must include (Article 12 region): software updating procedures, minimum hardware/software requirements, operating principle (including generic descriptions of algorithms), interoperability specifications and compatibilities/incompatibilities, and cybersecurity information. Menus should preferably be in Portuguese; English or Spanish are permitted alternatives only with conditions. Physical labels/IFUs are not required for internet-distributed software, but the information must be available within the software itself.

Changes that force re-submission: creating new functionalities or clinical indications; significantly affecting clinical functionality, safety, or efficacy; or altering the visual identity so the software is no longer recognizable. Minor bug fixes and security patches that do not affect intended use, efficiency, or patient safety do not need post-market authorization (changes follow RDC 340/2020).

Company prerequisites before any SaMD filing: AFE (Company Operation Authorization from ANVISA), LF (Operating License from the state sanitary authority), and BPF (Brazilian GMP certification under RDC 665/2022).

Nigeria: NAFDAC SaMD Guideline and the Notarization Burden

Nigeria's NAFDAC Guidelines for Registration of Software as a Medical Device (SaMD) in Nigeria (reference DR&R-GDL-036-00, effective 1 July 2024, review date 30 June 2029) is the newest of the four and the most document-heavy. NAFDAC became an IMDRF affiliate member, and the guideline explicitly says it must be read alongside IMDRF N10, GHTF/SG1/N70:2011 (labeling), GHTF/SG1/N71:2012 (definitions), IEC 62304, and ISO/IEC/IEEE 14764:2022.

Who files: foreign manufacturers cannot apply directly. They must register through a local representative (a Nigerian entity) in whose name the registration certificate is issued. All applications go through the NAPAMS portal (www.napams.org); a separate application is filed per product.

Documentation that differs from the others: the NAFDAC route requires a Notarized Declaration (Appendix 1) — typed, signed by the declarant, and notarized by a Notary Public in Nigeria — plus notarization in the country of manufacture, an End User License Agreement (EULA), and evidence of trademark registration with the Nigerian Ministry of Industry, Trade and Investment. These notarization and trademark steps are the practical bottleneck and are unique to this jurisdiction among the four.

Language: English only. Classification: Classes A–D, IMDRF-aligned. For moderate/high-risk devices, a Dossier Screening Clearance is a prerequisite before the full application can be submitted.

Kenya: PPB MDSW 2026 and the Maturity-Level Driver

Kenya's Pharmacy and Poisons Board (PPB) issued the Guideline on Regulation of Medical Device Software in Kenya (MDSW), 2026, established under the Pharmacy and Poisons Act, Cap. 244. The guideline exists as PPB works toward WHO Maturity Level 3 status. Standalone software had no binding Kenyan text before it, and a dedicated WHO Global Benchmarking Tool for medical devices and IVDs is still being developed — the MDSW guideline fills that oversight gap.

Filing route mirrors Kenya's general device rules: Class A → listing; Class B–D → full, abridged, expedited, or immediate evaluation routes. A Local Authorized Representative is required for foreign manufacturers. Submissions go through the PPB online portal, and the certificate is valid for five years.

Why Kenya matters for export strategy: PPB accepts reliance on reference-market approvals (EU, US FDA, Canada, Australia, Japan) through abridged routes, so a SaMD already cleared elsewhere can use that evidence to shorten the Kenyan evaluation. This is the fastest of the four markets if your dossier already exists.

The FDA as the Silent Fifth Framework

Although this comparison focuses on the four emerging-market texts, the US FDA is the framework's anchor. The FDA is a founding IMDRF member, hosts a Digital Health Center of Excellence, and applies the same IMDRF SaMD definitions and clinical-evaluation guidance. In the US, SaMD is classified under 21 CFR Part 860 and reaches market through De Novo, 510(k), or PMA pathways depending on risk and predicate availability. The practical consequence: a SaMD dossier built to satisfy the FDA's IMDRF-aligned expectations translates comparatively cleanly into the Saudi, Brazilian, Nigerian, and Kenyan frameworks — the definition and category logic is shared.

Cross-Market Traps Exporters Miss

• "Category IV" (Saudi) ≠ "Class IV" (Brazil) ≠ "Class D" (Nigeria/Kenya)." They sit at the same relative risk tier (highest), but the filing object and name differ. Map each jurisdiction's tier to your IMDRF category first, then translate to the local class — never assume the numbers align.
• SiMD vs SaMD. Software embedded in or driving a hardware device is SiMD in Saudi MDS-G027 and is regulated with the device, not as standalone SaMD. Brazil and Nigeria reach the same result through their definition tests. Misclassifying embedded software as SaMD (or vice versa) sends you down the wrong dossier.
• SaaS counts. Brazil's RDC 657/2022 explicitly captures subscription-based, centrally hosted software. A cloud-only product is in scope in all four jurisdictions.
• Language and notarization are gates, not formalities. Portuguese IFU content (Brazil) and the Nigerian notarized declaration + trademark evidence can delay an otherwise-ready dossier by weeks.
• Local representative lock-in. In Nigeria and Kenya the local representative holds the registration; changing representatives requires formal transfer. Choose the entity with the same care you would for an EU Authorized Representative.

What to Verify in the Original Text

Before filing in any of these markets, confirm the operative provisions directly:

• Saudi MDS-G23 §5 (definition and the "not part of a hardware device" test) and MDS-G027 (SaMD vs SiMD vs accessory decision tree) — verify your qualification before choosing an MDMA path.
• Brazil RDC 657/2022 Articles 1, 10, 11, and 12 — confirm the exclusions in Article 1(2), the Notification vs Registration split, and the IFU content list. Cross-check your class against RDC 751/2022 Rule 11.
• NAFDAC SaMD guideline §2 (Application) and §3 (Documentation) — confirm the NAPAMS submission steps, the Notarized Declaration (Appendix 1), and the trademark requirement.
• Kenya PPB MDSW 2026 — confirm the class-to-route mapping and which reference-country evidence your abridged route accepts.
• IMDRF/SaMD WG/N12 — re-derive your category from the matrix above so your tier mapping is defensible if a regulator challenges it.

Sources

• Saudi Food and Drug Authority, MDS-G23: Guidance on Software as a Medical Device (2018, v1.0): https://www.sfda.gov.sa/sites/default/files/2020-03/MDS_G23.pdf
• Saudi Food and Drug Authority, MDS-G027: Guidance on Digital Health Products (2025): https://www.sfda.gov.sa/sites/default/files/2025-08/MDS-G027.pdf
• ANVISA (Brazil), RDC No. 657, 24 March 2022 — Software as a Medical Device (official gazette): https://www.in.gov.br/en/web/dou/-/resolucao-de-diretoria-colegiada-rdc-n-657-de-24-de-marco-de-2022-389603457 ; English text: https://www.gov.br/anvisa/en/rules-and-regulations/arquivos/rdc_657_2022-e.pdf
• NAFDAC (Nigeria), Guidelines for Registration of Software as a Medical Device (SaMD) in Nigeria (eff. 1 July 2024): https://nafdac.gov.ng/wp-content/uploads/Files/Resources/Guidelines/DR_And_R_Guidelines/Guidelines-for-Registration-of-Software-as-a-Medical-Device-SaMD-in-Nigeria.pdf
• Pharmacy and Poisons Board (Kenya), Guideline on Regulation of Medical Device Software in Kenya (MDSW), 2026.
• US FDA, Software as a Medical Device (SaMD) — Digital Health Center of Excellence: https://www.fda.gov/medical-devices/digital-health-center-excellence/software-medical-device-samd ; FDA, Global Approach to Software as a Medical Device: https://www.fda.gov/medical-devices/software-medical-device-samd/global-approach-software-medical-device
• IMDRF, Software as a Medical Device (SaMD): Key Definitions (N10), Risk Categorization (N12), Application of QMS (N23), Clinical Evaluation (N41): https://www.imdrf.org/working-groups/software-medical-device-samd