ANVISA Regulation RDC 657/2022: A Complete Guide to Medical Device Software in Brazil

Introduction: Where Brazilian Medical Software Submissions Stall

In the cybersecurity area of a software dossier, an ANVISA reviewer reviews it and asks one question: How was the verification of these controls performed? In the architecture diagram, the “Cloud API” requires the hospital to have authentication, and the instructions for using it explain that the hospital should change the default password. But no one attempted to get around either of the controls or documented their attempts. So the app only waits for engineers to find evidence, which should have been done long ago.

This guide is about that gap. ANVISA regulations RDC 657/2022 require cybersecurity information to be included in the technical dossier, and the instructions for use and software in Classes III and IV must describe their cybersecurity controls. The resolution doesn’t say how to prove those controls work; it never mentions penetration testing. However, it is voluntary in accordance with ANVISA’s Guide 38/2020. A well-scoped test translates the security claims in the dossier into evidence. This means fewer exigencies and less rework. No test changes how long ANVISA itself takes to review a file.

Below we cover the rules that apply, what Guide 38 says, what to test, where findings belong in the dossier, how Brazil’s data protection law fits, and what goes on after approval.

ANVISA Medical Device Regulations: The Framework Around RDC 657/2022

RDC 657 does not work alone. Other resolutions set your risk class, your route to market, and the safety requirements against which you’ll be judged long before a reviewer opens the software chapter, and any of them can raise a security question.

The Brazilian health regulatory agency is ANVISA (Agência Nacional de Vigilância Sanitária). If the manufacturer is foreign and has no local entity, a Brazilian registration holder must file on behalf of the foreign manufacturer. The four layers of ANVISA medical device regulation are the most relevant for connected products.

Article 53 of RDC 848 is the key point to remember. It requires medical devices to be designed, manufactured, and maintained to provide an adequate level of cybersecurity against unauthorised access attempts. This is one of the clearest cybersecurity requirements in ANVISA’s medical device regulations. To demonstrate that the level of security is adequate, manufacturers can use penetration testing results as supporting evidence.

What RDC 657/2022 Requires on Cybersecurity

RDC 657 discusses cybersecurity in 5 different places, and each one gives a reviewer something to ask for. ANVISA publishes an official English translation.

• A definition (Article 2, III). Cybersecurity is the practice of protecting information and systems from unauthorised access, use, disclosure, disruption, alteration or destruction, so that risks to confidentiality, integrity and availability are maintained at an acceptable level throughout the life cycle. “Acceptable” drags security into the ISO 14971 risk file. “Life cycle” means approval is not the end game.
• The dossier (Articles 11 and 12). Class II software needs a cybersecurity architecture. Class III and IV technical reports need architecture information and cybersecurity controls, alongside verification and validation.
• Unauthorised access is a safety matter (Article 17, V). You must state the minimum hardware, network characteristics, and cybersecurity measures the software needs to work as intended.
• Labelling (Article 7, VI). The instructions for use must contain cybersecurity information, and Article 8 lets you place it inside the software.
• Cloud software (Article 2, VII). The definition names apps, subscription software, and hosted Software as a Service, so cloud platforms that meet the device definition are in scope.

The move from “architecture” to “controls” is where testing earns its place. Hand a reviewer a list of controls, and the obvious follow-up is how you know each one works.

Example:

Two notes about sources. ANVISA’s question-and-answer document on RDC 657, version 1 from September 2022, still mentions RDC 185/2001 and RDC 40/2015, even though both were revoked when RDC 751 went into effect. Therefore, whenever there are differences, refer to the current resolutions. RDC 657 is also under review. ABIMED states that the draft revision published in February 2025 covers AI-based software and pre-defined change control plans. 

The revision will be part of ANVISA’s regulatory agenda for 2026 and 2027. Currently, the applicable rule is RDC 657/2022, so please verify the status prior to filing. 

ANVISA Regulation Guide 38/2020 and Why It Names Penetration Testing

Guide 38/2020 is the ANVISA document that actually uses the term “penetration testing.” It took effect on 24 September 2020 and brings the IMDRF’s Principles and Practices for Medical Device Cybersecurity into Brazilian practice.

In Section 5.3, manufacturers are advised to apply multiple types of security testing to verify and validate. Technical security analysis, with penetration testing listed next to dynamic analysis and fuzz testing. A software bill of materials (SBOM) is recommended in Section 5.5.2. Coordinated vulnerability disclosure is good practice, as discussed in Section 6.3. Manufacturers, hospitals, users, and ANVISA share the concept of security, which directly impacts scope (Section 4.3). No one can dictate how a hospital builds its network, but you can find out what happens when it’s poorly constructed and let the hospital know. 

The guide is not prescriptive and is happy to accept alternative methods where appropriate. It’s suggested, not required, to do penetration testing. However, the tasks it can assist you with are a must. RDC 657 wants cybersecurity controls in the technical report; RDC 848 wants an appropriate level of protection. If not, the dossier should provide students with a justification of why the alternative method provides comparable assurance. 

How Penetration Testing Shortens the Path to ANVISA Approval

The purpose of testing a submission is to substitute statements for evidence. A question arises here for a “firmware updates are verified” dossier. If one is displaying tampered, outdated, and wrong-model update packages as rejected (see section 6), then there is not much to ask for.

The reason this is important is that an exigência temporarily stops the application until you respond. If there is no evidence, there is no written response. It’s an engineering exercise: scope a test, execute that test, resolve any problems that the test reveals, retest, update the risk file, and update the instructions for use. Even if the software is not reviewed clean, it will still provide one of the most predictable grounds for a technical query before you file it away.

The evidence can also travel. The FDA’s premarket cybersecurity guidance, which also covers cyber devices in section 524B, calls for security testing that includes penetration testing. MDCG 2019-16 provides clarity on how to comply with the MDR IT security requirements in the EU. All three are based on the principles of IMDRF, so one well-scoped test typically can support multiple filings, as long as: 

1. The build you tested is the build you file in Brazil
2. Brazilian hosting, identity providers and hospital integrations were in scope
3. Findings are mapped to your risk file
4. The test still reflects the current release

Be realistic about the limits. Testing doesn’t move you up ANVISA’s queue, and only ANVISA can publish review times. It doesn’t replace clinical evidence, usability work or GMP certification either. What changes are when you find problems while you still control the timetable, instead of after a reviewer spots the gap?

What to Test in a Medical Device Before an ANVISA Submission

A connected device is a system, a radio link, a phone application, a clinician portal, a cloud system, and a couple of hospital integrations. Test it, as they will use it in hospitals, including at least one test on an untrustworthy network.

Scanners rarely catch such authorisation flaws. If a clinician at one hospital can open another hospital’s patient record by changing an ID in a request, only a tester logged in as two different users will notice.

A tested example: the software update path

The update mechanism is how you’ll fix every future vulnerability. It’s also how an attacker could replace your software with theirs. RDC 657 Article 7 already asks for update procedures in the instructions for use, so it’s worth showing that the path itself can’t be abused.

We wrote two small update handlers in Python and ran five synthetic update packages through each one. Nothing ran on a real device, and production firmware would normally do this in C inside a secure bootloader. The first handler follows a pattern testers still come across:

It appears to be integrity protection but uses a SHA-256 hash. The problem is that the attacker builds the hash in the same package, and they can roll back the old version with the bug. Before touching flash memory, the fixed handler will verify four items:

The attackers really released five packages: an image that they altered and signed with their key, a signed but older image, an image they signed for a different model, and a genuine signed manifest with a swapped image.

What the Test Results Revealed

The handler that was vulnerable installed 4 of the 5 packages. The one built for the for-good-allies’ purpose did not install anything except the true release. It is also revealed that the results would have been different if only a signature had been used to prevent the tampered image from being reproduced, but not the downgrade or the wrong-model package. There are two conditions that lie outside of the code. Keep the anti-rollback floor somewhere where an attacker cannot rewrite it, as in one-time programmable fuses, and protect the signing key well, such as with a hardware security module. Use the same build to generate the SBOM, as Guide 38 suggests, so that any new vulnerabilities can be compared against those that you actually deployed.

Mapping Penetration Test Findings to the ANVISA Technical Dossier

A report written for engineers isn’t a dossier document yet. It has to be placed in ANVISA’s structure, tied to the risk file and closed off with statements a reviewer can accept. RDC 751’s Annex II follows the IMDRF table of contents, and RDC 657 Article 11 uses a similar chapter layout for software.

Each finding belongs in the ISO 14971 file, which RDC 657 Article 13 requires you to declare conformity with. Write the clinical consequence in plain words. “Unauthenticated write access to the alarm threshold characteristic” is accurate. “Someone within Bluetooth range could silence a heart-rate alarm” is what a reviewer remembers.

Understanding ANVISA’s Software Validation Requirements

There is no single document titled ANVISA validation guidelines for software. The phrase usually refers to the three requirements that RDC 657 combines in the Class III and IV technical report: the requirement to establish a life cycle for the IEC, which Article 13 names the IEC 62304 life cycle; and the requirement under Article 50 of RDC 848 to develop software in accordance with the state of the art, with security testing representing one more verification step. For a quick self-check, choose any security control in the dossier, and trace it from requirement to test case to result. As soon as the chain snaps, a reviewer might do the same. 

There will still be some results outstanding at submission. A helpful residual risk statement should describe the issue, why the risk of exploitation is small or not expected, what control measures are reducing it, and what the user needs to do. None of these means the risk is low.

LGPD and Patient Data: The Privacy Layer on Top of ANVISA Rules

ANVISA seeks the safety and effectiveness of a device. Brazil’s data protection legislation raises the question of personal information contained in the data. With the LGPD, health data is considered sensitive personal data (Article 5, II), which means that technical and administrative security measures are required (Article 46) and that controllers are required to notify of security incidents that may cause relevant risk or damage (Article 48). Resolution CD/ANPD 15/2024 provides a period of 3 business days to give notice to the ANPD and the affected people. The fines for Article 52 can be up to 2% of Brazilian revenue, with a cap of R$ 50 million per violation. 

The stakes are highest in healthcare. IBM’s 2026 study put the average Brazilian breach at a record R$ 7.44 million, with healthcare the costliest sector at R$ 12.55 million per breach.

The controls overlap, which helps. Showing that a clinician can’t read another hospital’s patients proves an RDC 848 access control and an LGPD security measure at the same time. Add data flow details such as where patient data is stored in the cloud or whether logs silently copy patient data; see if you can determine which records an attacker had access to. Detection is as important as prevention – with three business days to notify. Test with synthetic data whenever possible, and agree on hospital contracts as either controller or processor, as this determines which party will need to notify.

Cybersecurity Obligations After ANVISA Approval

RDC 657 defines the entire life cycle of cybersecurity, and RDC 848 Article 53 requires that you maintain devices at an adequate level. Once approved, the process involves reviewing components against your SBOM, implementing coordinated vulnerability disclosure as per Guide 38, and assessing whether a vulnerability that might impact a patient is a duty to technovigilance (RDC 67/2009) or field action (RDC 551/2021).

With security patches, the change question arises.The change(s) in functions or clinical indications shall occur on an alteration petition in RDC 657 Article 16; changes that may significantly affect safety, effectiveness, or performance shall occur on an alteration petition in RDC 657 Article 16, and visual changes that make the software unrecognisable shall occur on an alteration petition in RDC 657 Article 1.6. It contains only one paragraph stating that simple maintenance doesn’t require one, and that indications, effectiveness, or patient safety are not impacted by information security changes, which are included in the examples. Typically, developers consider a patch that fixes a vulnerability without altering the clinical behaviour to be a maintenance patch. They may not consider one that puts a log in front of an emergency function to be maintenance. For each change, record the reasons for the change, including the risk assessment. 

ANVISA does not establish a retest interval. Retest whenever you introduce an interface, alter authentication, move hosting, upgrade a core component or discover an important vulnerability in something you ship, and establish a regular cycle that’s appropriate for the riskiness of the device.

ANVISA Readiness Checklist for Connected Devices and Medical Software

Before testing

• Class and route confirmed under RDC 751
• Architecture, data flows and cloud regions documented
• Threat model linked to the ISO 14971 file
• SBOM generated from the tested build, which matches the version you’ll file

During testing

• Tester independent from the developers, with that independence recorded
• At least one untrusted-network scenario
• Authorisation tested across user roles and hospitals
• Update path tested for tampering, downgrade and wrong-model packages

Before submission

• Critical and high findings fixed and retested, or justified in the risk file.
• Security tests traced to requirements, in line with ANVISA validation guidelines.
• Cybersecurity information in the instructions for use matches the results (RDC 657 Article 7)
• LGPD records updated with the same evidence

After approval

• Vulnerability monitoring against the SBOM and a published disclosure policy
• Change records explaining why each security change did or didn’t need a petition
• Retest triggers defined and an incident plan covering the ANPD’s three business days

How Qualysec Supports ANVISA-Aligned Medical Device Testing

Qualysec is a specialised penetration testing firm, and medical device work is where our testing directly goes into regulatory files. We think of it as a single entity: device, app and cloud – no weaknesses will be left between them. Findings are written with two readers in mind. Engineers receive repro steps and fix them, and the regulatory team receives an impact description that can be transferred to the risk file and to the dossier. Each fix is tested again, the findings are closed, and there is dated evidence, not open issues as in the Dossier.

According to its Clutch review, Monitra Healthcare, based in Hyderabad, engaged with us from October 2025 to July 2026 for their cardiac arrhythmia detection vulnerability assessment and penetration testing needs for the FDA 510(k) cybersecurity requirements. This filing is for the FDA, not ANVISA. Despite that, the evidence it requested – tested controls, documented results and confirmed fixes- is the same evidence that RDC 657 (and Guide 38) refer to. 

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

Conclusion and Next Steps

The ANVISA Brazil medical device regulations ask for a cybersecurity architecture, controls, user information and an adequate level of protection, and they leave the proof to you. Build the cybersecurity section from test results, tie it to the risk file and reflect it in the instructions for use, and most of a reviewer’s questions are answered before anyone asks them.

Timing matters as much as the test. Run it while there’s still room to fix and retest, ideally before your FDA or EU filing, and keep going after registration, because RDC 657’s life cycle doesn’t end there.

Primary call. An exigência on cybersecurity can add months to a Brazilian launch. Talk to our team about testing your device, app and cloud back end before you file, so the dossier answers the question first.

Secondary call. Want to see how findings are documented first? Review a sample penetration testing report, with severity, reproduction steps and fixes laid out the way a reviewer reads them.

Frequently Asked Questions

1. Does RDC 657/2022 require penetration testing for software as a medical device?

Not by name. It requires cybersecurity information in the dossier and the instructions for use, plus cybersecurity controls in Class III and IV technical reports. Voluntary Guide 38/2020 recommends penetration testing, which is a good way to demonstrate the effectiveness of the required tests.

2. Which ANVISA rules apply to a connected medical device sold in Brazil?

Typically, RDC 751/2022 is applicable to class and route, RDC 848/2024 to safety and performance, including cybersecurity, RDC 665/2022 and RDC 687/2022 to Class III and IV manufacturing; and RDC 657/2022 to standalone software. Guide 38/2020 introduces recommended practice, and the LGPD applies to personal data.ANVISA is the Brazilian health regulatory agency, not the only regulator involved, so also check items such as ANATEL certification for devices with radio interfaces.

3. Can a penetration test report prepared for the FDA or EU MDR be reused for an ANVISA submission?

Usually, yes, if it covers the version you’re filing in Brazil, the Brazilian hosting and integrations, and links to your risk file. Where it doesn’t, a short top-up test costs far less than an exigência.

4. Does ANVISA Guide 38/2020 apply to Class I and II devices under notificação?

The guide is voluntary and isn’t limited by class, so it applies as good practice to any connected device. Class II software must also include a cybersecurity architecture, and RDC 848’s cybersecurity duty covers every class. The notificação dossier stays with the company, but it has to be ready if ANVISA asks.

5. How does the LGPD affect cybersecurity testing of medical devices in Brazil?

It considers health information sensitive and demands security measures and, according to Resolution CD/ANPD 15/2024, requires the reporting of relevant incidents within three business days. These measures have been proven effective through testing. Data flows and incident detection should be included, and where possible, use synthetic data.

6. How often should a medical device be retested after ANVISA approval?

ANVISA doesn’t set an interval. Retest after significant changes to interfaces, authentication, updates, hosting, or core components; after serious vulnerabilities in shipped components; after any incident; and at regular intervals set by the device’s risk.