Brazil SaMD Rules: RDC 657/2022 and RDC 848/2024 Requirements

1. Key takeaways

RDC 657/2022 has been effective since July 1, 2022: Brazil legislates separately for software as a medical device (SaMD). But what really determines the depth of a SaMD dossier is RDC 848/2024 — effective 180 days after publication — in its Articles 50, 51, and 53, which write accuracy, reliability, and cybersecurity into hard, verifiable requirements. GRZAN’s judgment: reading RDC 657/2022 as an independent registration channel for software products is a misreading. It runs in parallel with the classification-and-registration master regulation, and software products must still be classified first under Article 5 of RDC 751/2022 before deciding between notification and registration.

2. Legal basis

• Provisions on software as a medical device — RDC nº 657/2022, effective July 1, 2022 (publication date to be verified against the DOU or the ANVISA legislative database — a practical estimate; defer to ANVISA publications)
• Essential safety and performance requirements — RDC nº 848/2024, published in the DOU on March 8, 2024, effective 180 days after publication (Article 88); ANVISA announced its taking effect on September 10, 2024: Article 50, Article 51, Article 53
• Requirements for the classification, notification and registration of medical devices and for labeling and instructions for use — RDC nº 751/2022, resolution of September 15, 2022: Article 5, Article 6, Article 7, Article 10(9)

3. Expert insights

Why did Brazil legislate separately for SaMD? GRZAN’s reading: the traditional registration logic is built on a physical device plus a manufacturing site, and neither the version iteration of software, nor its deployment modes, nor its failure modes can be described within that logic. Separate legislation exists to settle the prior question of what exactly the registered object is. RDC 657/2022 took effect on July 1, 2022, ahead of the master regulation RDC 751/2022, which took effect on March 1, 2023 — a sequencing that shows it landed first as a subject-specific rule.

Companies commonly fall into three traps. The first is assuming that a dedicated software regulation means a dedicated pathway, forgetting that classification is still step 1: software products must still be classified under Article 5 of RDC 751/2022, with Classes I/II going through notification and Classes III/IV through registration.

The second is underestimating the substantive increment brought by RDC 848/2024. Articles 50, 51, and 53 require devices containing software (including SaMD) to ensure accuracy, reliability, and cybersecurity; development must be verified, and IT requirements must be specified, with mobile computing platforms expressly covered. GRZAN’s judgment: these three provisions turn software lifecycle documentation from a bonus item into a mandatory item — a functional description alone no longer passes review.

The third is deferring the language problem. The application form, the instructions for use (IFU), and the label mock-ups must be in Portuguese, and for SaMD the interface text, error messages, and online help face the same localization; this workload is routinely left out of the budget.

A fourth judgment comes from GRZAN’s project experience: the hardest part of SaMD is not the first approval but iteration management afterwards. Software version updates frequently fall into the three-tier change classification of Article 16 of RDC 751/2022 — changes requiring approval, immediate-implementation changes, and changes requiring no notification. If the design phase does not build in decision rules for classifying changes, every release turns into an ad hoc argument, and the long-term cost far exceeds the first filing.

It also helps to read the two texts as one architecture rather than as rivals. RDC 657/2022 answers what a SaMD is and how software-specific expectations are framed; RDC 751/2022 answers what risk class the product sits in and which route it therefore takes; and RDC 848/2024 answers what the product must demonstrably do to be safe, reliable, and secure. A submission that treats these as interchangeable typically bundles everything into one narrative and loses the reviewers. GRZAN’s practical advice is to keep the software-specific file, the classification record, and the essential-requirements evidence as three separately indexed layers of the same dossier, so that an ANVISA reviewer — or an auditor years later — can find each answer where it is expected to be.

4. Practical recommendations

First, classify before choosing the pathway. The GRZAN regulatory team recommends fixing the classification conclusion in a written record, as the basis for the scope of everything that follows.

Second, build the software documentation package against Articles 50, 51, and 53 of RDC 848/2024. At minimum it should cover requirements-to-verification traceability, accuracy and reliability verification records, and cybersecurity risk assessment with IT requirements documentation; missing any one of the three creates a substantive documentation gap.

Third, put localization into the development plan. Portuguese versions of interface and message text should advance in step with the IFU finalization, so no change procedure is needed after certification.

Fourth, front-load the clinical evaluation threshold. Articles 15 to 19 of RDC 848/2024 set the requirements for clinical evaluation and clinical investigation, with investigation mandatory where data are insufficient; if the SaMD carries diagnostic or treatment-decision functions, the evidence gap should be assessed early.

Fifth, predefine change classes for releases. Map version iterations onto the three classes — requiring approval, immediate implementation, and no notification — in an internal decision table, so no release requires ad hoc justification.

5. Verification checklist

• □ The software product’s risk classification has been confirmed in writing under Article 5 of RDC 751/2022
• □ The pathway is set as notification (Classes I/II) or registration (Classes III/IV)
• □ Accuracy, reliability, and cybersecurity documentation is prepared under Articles 50, 51, and 53 of RDC 848/2024
• □ Development verification records and IT requirements documentation are complete, covering mobile computing platforms
• □ Portuguese localization of the interface, messages, and IFU is complete or scheduled
• □ Version iterations are mapped onto the three-tier change classification of Article 16 of RDC 751/2022

Regulatory information verified as of October 29, 2026

GRZAN Regulatory Affairs Team

GRZAN supports software and connected-device manufacturers entering the Brazilian market with ANVISA registration pathway and classification strategy services, including SaMD classification under RDC 751/2022, software documentation packages aligned with Articles 50, 51, and 53 of RDC 848/2024, and release-oriented change classification that keeps iteration costs predictable. To plan a SaMD submission or a post-approval update regime, contact the GRZAN regulatory team at info@grzanglobal.com.