Software and cybersecurity requirements for medical devices in Brazil

1. Key takeaways

Devices containing software and software as a medical device (SaMD) must satisfy 3 parallel requirements in Brazil: software developed under lifecycle principles and confirmed and validated (Art. 50); software for mobile platforms accounting for the platform itself and external use-environment factors (Art. 51); and devices providing an adequate level of cybersecurity against unauthorized access (Art. 53). The resolution applies from 180 days after publication (Art. 88), and ANVISA issued the effective-date notice on September 10, 2024. On top of these ESPR articles sits a dedicated SaMD regulation, RDC 657/2022, so software products in practice face a two-layer rule set: the general principles plus the special regime, and both layers must be evidenced in the same dossier.

2. Legal basis

• Essential Safety and Performance Requirements — RDC No. 848/2024, published in the DOU on March 8, 2024, Arts. 50, 51, 53, 85 and 88
• Classification, Notification and Registration of Medical Devices, and Labeling and Instructions for Use Requirements — RDC No. 751/2022, decided on September 15, 2022, Art. 10 §9, Art. 10 §10, Art. 16
• Software as a Medical Device (SaMD) — RDC No. 657/2022, published on March 30, 2022 (DOU No. 61), effective July 1, 2022 (Art. 25), Arts. 3, 7, 8, 10 through 13, 16
• Brazilian Good Manufacturing Practices — RDC No. 665/2022, published on March 30, 2022, effective May 2, 2022 (Art. 138), Art. 1
• Law on Sanitary Infractions and Penalties — Lei No. 6.437/1977, dated August 20, 1977, published in the DOU on August 24, 1977 (Part 1, page 11145), full text

3. Expert insights

Art. 49 first sets the tone for devices containing programmable electronic systems or constituting SaMD themselves: they must assure accuracy, reliability and safety, and must address single-fault conditions. Art. 50 then binds the development, manufacture and maintenance of software to the state of the art, requiring lifecycle development principles and the inclusion of risk management — including information security — together with confirmation and validation. GRZAN’s judgment is that the bite lies in information security being written into risk management rather than standing as a separate cybersecurity clause: cybersecurity must have hazard entries, control measures and residual risk evaluation inside the risk analysis phase. Art. 52 adds an independent obligation: the manufacturer must specify the minimum hardware requirements, IT network characteristics and IT security measures needed to run the software, including protection against unauthorized access.

The second pitfall is the mobile platform. Art. 51 requires the design to consider the platform’s own dimensions, screen contrast, connectivity and memory, together with external factors such as lighting or noise. Companies building app-based SaMD often test only on flagship phones, but under the Brazilian reading the variable use environment is a mandatory design input, and a test matrix that stops at the newest device is a visible gap.

Third judgment: Art. 53 requires the device to provide an appropriate level of cybersecurity against attempts at unauthorized access, covering design, manufacture and maintenance — and the maintenance leg brings post-market vulnerability response and patch management into the compliance perimeter. Layered on top is ANVISA’s dedicated SaMD resolution RDC No. 657/2022 (published in DOU No. 61 on March 30, 2022, effective July 1, 2022 under Art. 25), so software products in Brazil actually operate under a dual regime of ESPR principles plus a special resolution. Art. 3 first routes embedded software out of the SaMD path: software embedded in a medical device follows the host device and is not filed separately. Art. 5 exempts Class I and II software developed in-house by a health institution, on condition that records are kept for 10 years.

Fourth judgment: SaMD instructions for use and the technical file carry extra weight. Art. 7 requires the instructions for use to state, beyond the usual content, the update procedure, minimum software and hardware requirements, the principle of operation (including a general description of the algorithms, routines and formulas and their validated clinical association), warnings, interoperability and compatibility or incompatibility information, and cybersecurity information. Art. 8 allows this information to be placed inside the software itself, but traceability then uses version identification instead of a batch number, differing from the batch logic of Art. 47 item V of RDC 751/2022. The technical file is tiered by risk: Arts. 10 and 11 require the Class I/II notification file to contain the software architecture document, compatibility and interoperability testing, a residual anomaly list, traceability documentation and change history, with Class II additionally requiring the cybersecurity architecture and a declaration of conformity; Art. 12 adds 10 further items to the Class III/IV technical report, including cybersecurity architecture information and control measures, and the clinical evaluation with its validated clinical association.

Fifth judgment: distinguish hard citation of standards from recognition status. Art. 13 legally and mandatorily cites IEC 62304:2006, IEC 62366-1:2015 and ISO 14971:2007, and its sole paragraph permits updated editions. GRZAN reminds readers that Brazil’s current recognized catalog already lists ABNT NBR ISO 14971:2020, so preparing against the 2007 edition is an outdated practice. One more boundary belongs in the project judgment: ANVISA’s official catalog of recognized standards (v1.0, 2026-09-11) does not list commonly used standards such as the IEC 60601 series, ISO 13485, IEC 62304 and IEC 80601. Recognition is neither approval nor compulsion and is voluntary; standards absent from the catalog do not enjoy recognized status, and adopting them requires separate justification — a need to justify, not a rejection.

Sixth judgment: a software release must clear two change gates. Art. 16 of RDC 657/2022 defines three categories of reportable changes plus simplified maintenance situations exempt from reporting; Art. 16 of RDC 751/2022 splits changes into requiring approval, immediate implementation and non-reportable, with Class I/II changes in principle following immediate implementation. Where a patch or version iteration lands depends on whether it touches safety and performance.

Seventh trade-off: the software interface and instructions for use are bound to Portuguese by Art. 10 §9 of RDC 751/2022. Interface string localization should be scheduled into development, not reworked on the eve of submission.

4. Practical recommendations

• Dedicate a hazard—control measure—residual risk chain to cybersecurity inside the risk management file.
• Turn device models and use scenarios into a test matrix covering low-end models and extreme lighting and noise environments.
• Establish a post-market vulnerability response and patch release process, and map release types against the three-tier change classification.
• Prepare files per the SaMD tiering of RDC 657/2022: embedded software follows the host device, and Class III/IV files add the 10 items of Art. 12; align risk management evidence with ABNT NBR ISO 14971:2020, currently recognized in Brazil.
• Violating the ESPR constitutes a sanitary infraction under Art. 85, subject to the penalty list of Lei 6.437/1977, with fines following the infraction grading (leve / grave / gravíssima) and amounts set by current rules — the original amounts in Art. 5 of Lei 6.437/1977 were priced in 1977 cruzeiros, a currency that ceased to be legal tender after successive monetary reforms, so this series does not list amounts.

5. Verification checklist

• □ Is the software development lifecycle evidence complete (requirements, design, verification, validation, maintenance)?
• □ Is cybersecurity inside the risk management file rather than only a test report?
• □ Do mobile platform factors, minimum hardware requirements and IT security measures all have design and test records?
• □ Are the Portuguese interface, instructions for use and label models fully localized?
• □ Is the change-level determination for software version iterations documented?

Regulatory information verified as of October 29, 2026

GRZAN Regulatory Team

GRZAN builds Brazil-compliant software documentation packages — SaMD technical files under RDC 657/2022, cybersecurity risk chains and lifecycle evidence under RDC 848/2024 — and maintains them through version releases. For software and cybersecurity documentation support in Brazil, contact GRZAN at info@grzanglobal.com.